turtles3

But you still need an external->internal lookup, so doesn't that mean you still need an index on the fully random id?

IIRC projects only group resources under the same account. API keys are still account-wide, so projects provide no isolation there.

There is a other mechanism DO has to allow multiple accounts under one billing context (I think it might be called 'teams'?) but sadly this is still extremely coarse grained, and doesn't allow you to lock a key down to a particular resource, or even a class of resources.

The lack of ACLs or comparable permissions is by far the biggest thing that prevents me from recommending DO for production workloads. This kind of thing is absolutely essential. You can't even separate dev resources from prod resources, every API key has godmode on your whole account. This is a security disaster.

For a simple example, I'm running externaldns on a kubernetes cluster. For production use, I'd want to at least have an API key that can only access the DNS domains and nothing else. As is, the key can create compute resources or delete anything (including object storage buckets!). Again with no dev/prod isolation, so a leaked dev key that looks innocuous means your prod resources are now compromised.

Some second tier providers do better at this, OVH and scaleway both have some concept of ACLs, but DO just don't even try.

Apologies for the slight rant but it's frustrating to see something so basic overlooked by a company the size of DO.

I thought they had the same deal as DO - control plane is free and you pay for nodes at the standard rate. Have I missed something?

I am considering moving our DO to ovh mainly because DO lacks fine grained IAM

Unironically this? It might violate gdpr to get consent for the purposes of maps but then use it in more contexts. I guess they might include all purposes when the user is asked, and at that point it boils down to whether the user is being asked consent for overly broad purposes or whether it is legitimate to bundle all the Google apps together.

It's internet explorer all over again.

I think it is also important to acknowledge that there are things innodb does better than Postgres, eg. For most workloads an undo log is a far better data structure than implementing MVCC by duplicating rows. Autovacuum and vacuum can be an absolute nightmare, plus the extra disk traffic the duplication generates. Maybe one day OrioleDb will bring this to postgres too.

This sounds very much in the spirit of Grzegorz Brzęczyszczykiewicz[0]

[0] https://m.youtube.com/watch?v=AfKZclMWS1U

Arguably they weren't 'business minded' if that was the outcome. I know what you mean, but at the same time understanding what the technical members of the team do and how they get that work done is an essential part of succeeding as a manager.

The only way that your manager could be classed as a success is if you and the others who left were not necessary to the business. As mercenary as that sounds, we are talking pure business outcomes here.

Some men just want to watch the world burn.

That is a very specific use case, and might only be a small subset of your actual data. If you don't have these specific requirements (eg. CRUD apps), you can save yourself a lot of unnecessary headaches by defaulting to MySQL.

My main point is attempting to counter the narrative popular on HN that postgres should be an automatic default. For sure there are many aspects in which postgres is superior, I absolutely do not debate that, especially when it comes to developer experience. But there is much more to it than that when it comes to delivering business value. That's where ops and DBA concerns start to matter, and IMO MySQL is so far ahead in this regard that it outweighs all the other hideous warts of working with it, when you consider the bigger picture of the business as a whole.

Unpopular opinion: if you're skimping on ops/DBA resources (as you may need to do in a startup), then MySQL is a better default. By all means use postgres if your use case demands it, but personally I find the ops story for MySQL takes less engineering overhead.

I find the opposite wrt. refactoring - that is to say integration tests are _more_ robust to refactoring than unit tests, and that's one of the reasons I strongly prefer them.

Unit tests are deeply coupled to the internal structure of your system - refactoring often implies changing unit tests, which opens the door to bugs where the code and test both change to match each other.

As you say, integration tests validate your public API, which from a 'correctness' point of view is really the only thing you care about, not the internal structure of the system. That's why I love integration tests, you can make sweeping refractors without needing to change the tests, because the test will still tell you whether the behaviour of the whole system is correct.

Does AI really speed up projects by 10x? In my experience, tools like copilot help with the smaller things, but it's bigger things that really matter in a project.

For example, the right database schema or the right architecture I could easily see saving you 10x the development effort, but these are the things copilot is least able to help you with.

Am I misunderstanding something here? Or could it be that what you are finding is that your experience is helping you build faster, and this is being misattributed to AI?

If you take unlimited in its most literal meaning then no, you can't provide unlimited anything. However, I think there's a difference between saying you provide unlimited storage, and a SaaS tier supporting 'unlimited' users.

Yea it's true that if someone tried to truly exercise the latter, for example by allocating several trillions of bot accounts, then for sure you're going to get a call from the provider politely instructing you to desist. And I think that would be reasonable of them, and the marketing should not be considered deceptive.

The question is, does the same logic apply to TBs of storage? Is there anything that distinguishes these two use cases?

I guess the marketing offer of 'unlimited' could perhaps be read as 'all that 99.9% of customers ever need, but if you're one of the remaining 0.1%, you have to pay extra'.

That is to say, perhaps 'unlimited' could be read as a class of user that encompasses the vast majority of cases, as opposed to a literal resource quota. Is this reasonable or deceptive?

I'll add that C# also has using statements that dispose the object when the current scope exits (including if it exits due to an exception) this significantly cuts down on ugliness .

> Additionally, there are folks using SpiceDB today by replicating denormalized checks back into their database (e.g. Postgres) or search index (e.g. Elastic) so that you can filter them natively. This is the combination of the aforementioned Lookup APIs with our Watch API. While this strategy requires moving parts, it is necessary beyond a particular scale which is well beyond the point at which policy engines typically fall over.

Would you say that because of this, Zanzibar engines like spicedb only become useful on systems of a certain size / complexity? Fundamentally you run into data synchronization issues whether you are syncing denormalized data back to your db via Watch or whether you write the relationships to both data stores in the first place. This article[0] on the latter topic touches on this, but brushes over some tricker parts of implementing such a thing correctly (eg. 2 writes section only covers insert not update or delete which is generally less harmful to have a ghost update that persists in spicedb, streaming updates brushes over some major footguns).

Granted there's nothing unique to spicedb in this sort of complexity, but by nature of being a db, using spicedb mandates that users must take on the complexity.

Is it then fair to say that it is appropriate to use spicedb once a project reaches a certain size / complexity, or would you expect a startup to adopt it from the beginning?

[0] https://authzed.com/blog/writing-relationships-to-spicedb

This, especially when you combine it with pagination, filtering and ordering requirements.

Zanzibar implementations (eg. Spicedb, keto etc) offer functionality for listing resources accessible to a given principal, but as far as I can see none have a coherent solution for filtering and ordering.

The only solution I can see to this is as you suggest maintaining a shadow copy of the relationships in your db so you can answer the question with a regular SQL query. This obviously comes with a lot of headaches, and is the sole factor preventing us from adopting one of these systems, so I really hope I'm wrong about this.

This is a 'guns don't kill people' argument, which historically has been a bit more complicated than that. Humans are not context-free actors independent of their environment - our environment shapes us. And the argument here is that this technology would create an environment that would have a tendency to bend us into a shape we may not like.

Completely agree with this approach - recently I find that most of the tests I write are so-called 'integration' tests. I find these tests not only get more code coverage for fewer tests, but they more closely represent the real or implied external specification. In other words, they do a better job of verifying 'is the code correct' rather than 'is the code we wrote the code we wrote'.

I think the specification from elsewhere is all about the business value that the code delivers. At the end of the day, the business doesn't care about how exactly your code is decomposed into classes/functions/etc, the business cares about 'can I register a customer' and 'are customers prevented from writing to resources they only have read access to'. Of course there is some requirement for the code not to be a complete mess, as this has impacts delivering features and reducing bugs down the line, but with tests that sit closer to the value the code delivers than the structure of the code, you're free to refactor and the tests will tell you what you've inevitably broken. I find this considerably more valuable than unit tests.

> Merge squash works every time.

Unless you've already started a follow-up branch before the first gets merged (eg. Waiting for QA, PO review etc.)

Then you at minimum will need to rebase your second branch after the first is merged. Not a disaster but it adds overhead.

Are there any payment processors you can recommend, especially re. fraud protection? We have started out with stripe (because the API is so damn convenient), but HN has so many stories like this were seriously reconsidering that choice. It's a shame that in every one of these threads someone from stripe steps in and promises to sort everything out for one customer, but the underlying issues never get resolved.

I'm not saying that fraud is an easy problem to solve, but I think you're absolutely right that this is a case of misaligned incentives. If it were Stripe's liability, it would get solved for _everyone_, rather than being in this middle ground where if you're lucky you might get help if you post on HN

However, the same thing could be achieved with closed source models. There's nothing to stop an LLM being made available to run on prem under a restrictive license. It would really be no different to ye olde desktop software - keeping ownership over bits shipped to a customer is solved with the law rather than technical means.

That said, I really hope open source models can succeed, it would be far better for the industry if we had a Linux of LLMs.

This may be irrational but it's something that worries me about using postgres in production. Sure as a developer I love all the features, but the fact that the query planner can suddenly decide on a radically different (and incredibly inefficient) query plan makes it hard to trust. In some ways, a dumber query planner that needs coercing into the right query plan is more reassuring, in that you know it'll keep using that query plan unless explicitly told otherwise.

>It will quack like self consciousness but is not actually self conscious.

But isn't this the point of the Turing test? Since we cannot determine otherwise, if something exhibits all of the outward observable behaviour of consciousness, we must conclude that it is conscious.

Otherwise we may be in the farcical position of needing to declare some humans not conscious under the same justification.

Presumably the article is meaning two CPU sockets, rather than two cores?

I don't think it's as simple as that - we have higher level languages that protect us from trivial security issues like buffer overruns, but that's a net good. There is no advantage we would gain in security from rolling that back.

Instead, it gives us exposure to a new set of higher level security problems, that over time we will need to develop higher level primitives to navigate. We would still have these problems with lower level languages, we'd just be too overwhelmed with smaller issues to properly address them

I think the root of the issue is not that we need imperative languages for configuring cluster workloads - declarative state as an API contract between clients of the cluster and the cluster itself is a good thing. The reconciliation model is what makes kubernetes work, and that should be preserved.

But I do think we need better tools to generate said declarative state, regardless of its serialization format (yaml, JSON or other). Hand editing the raw declarative state is clearly untenable, hence the development of the various templating solutions. But I don't see an issue with using an imperative program to generate the declarative state either, as long as the declarative state is what forms the substance of the API to the cluster.