Very OT, but can I say i’ve seen this happen at every company i’ve been? When the founder(s) get out of the picture they kinda bring the soul of the company with them.
Yeah there’s a fading halo still in the air for a while, but it’s just that: a fading halo.
> Rather than issuing individual certificates for every internal host, a wildcard for something like *.int.example.com covers everything under that subdomain.
Congrats now one host is compromised and the certificate for the entirety of your private infrastructure is leaked.
What you fail to grasp is that there are multiple sizes of IT organizations on this planet. The vast majority of them have less than 10 total admins. For them, they could not build and maintain an internal PKI thats as secure or as reliable as Public PKI.
Expecting them to do so is giving up. They will just use self-signed certs and blindly click through warnings.
Having a real certificate that warns when something is wrong is always better than perfect security. When you've worked at more than 1 kind of organization, you get a broader perspective.
> What you fail to grasp is that there are multiple sizes of IT organizations on this planet. The vast majority of them have less than 10 total admins.
Nah, i grasp that very well because i was part of a three-people team that did manage, across other things, a private CA.
After evaluating a few options we decided to Vault from hashicorp to manage our own CA. We scripted the shit out of it and it worked beautifully for years with little to no maintenance. It was an unicorn company (1+ billion euros valuation) and there were multiple kubernetes clusters, around 120 people in the tech team and a multitude of microservices.
Frankly i think it's you that fail to grasp the reality of operating a private CA in a company that does other things rather than managing private CAs.
If you grasped that, you'd know that for example you cannot use (for example) letsencrypt certificate for client authentication anymore, or mutual tls, and you couldn't do that at all with a wildcard certificate.
With a private CA you can do whatever you need and whatever you want.
If you had worked in a real company doing that you would understand.
> When you've worked at more than 1 kind of organization, you get a broader perspective.
That's just a skeaky and mean way to attack me on a personal level, rather than attacking my point.
frankly your post shows a lot of insecurity and your complete ignorance on the reality of operating a private CA, if I were you I'd stop posting out of pure shame.
Yes, I wholehartly agree. Coming from a week of agent-coding - out of pure curiosity - most code was generated by agents, which I had then to delete and rewrite to use like a quarter of statements to achieve the same, in an understandable, maintainable way.
If the industry is using agents and shipping a certain amount X of code/features in a certain amount if time, you either start using agents as well or you fall behind.
I suspect it's much worse with agents. They tend to generate a lot more code and also more likely to make large refactors.
From the parent, making edits to different functions in the same file usually doesn't cause a merge conflict unless they're close together. Usually it's when you have the same lines being replaced with 2 different options.
I think humans naturally tend to try to avoid working on the same area of the codebase at the same time and have other mitigations like daily meetings to coordinate and organize.
That said, yeah, I think they're complaining about "slap AI on everything" as well
What about Multigres[0]? It builds on top of Postgres and adds HA (based on Flexible Paxos[1]), sharding, etc. They're still not production-ready, but I'm highly optimistic they will solve a lot of the problems Postgres have.
For example, with Multigres, you should be able to achieve true zero downtime major version upgrade by simply resharding [2]. With vanilla Postgres + pgBouncer, you can only achieve near-zero downtime (few seconds at most), though it's probably good enough for most use cases.
Do other RDBMSs have this? I genuinely have no clue. I've been fortunate enough to be able to get away with one primary and multiple secondaries at my largest usage of Postgres. Multi-master is the kind of thing I am fully out of my depth on, so I'm curious if there's a well defined path for implementation here or what.
Commercial RDBMS (oracle/mssql) have had it in some form for awhile, with pluses and minuses. Open source DBs have had bolt-ons, including BDR for pgsql.
Multi-master is hard. The main issue is what to do with commit/replication lag. It's far "easier" if support for eventual consistency is ok with your use case. In some cases it's not. Also, the problems related to read-only lag can happen on multi-master instances. If somebody does a giant long running query on one of the masters, the target instance needs to hold the data state for the query, even if the underlying DB is getting updates. It also needs to still keep up with other masters. This means the whole cluster can slow down if the multi-master replication is synchronous. Depending on a variety of factors, that can chew up disk space, memory, etc.
There are ways of dealing with these issues (and others), but it comes with tradeoffs with performance, etc.
It has been tried many times. Good luck to pgdog, but there’s a reason these projects don’t stick.
Multi master, from even a conceptual perspective, is incredibly complicated. Databases, transactions, consistency, parallelism are all very complicated.
It’s something that always seems promising at the start but as soon as maintenance and long term improvements enter the picture(ie integrating new Postgres versions), the complexity becomes too much.
I know what i'm about to write is purely aneddotical, n=1 and all the usual things, however: i started noticing clear and evident mood improvements change between when eggs are part of my diet and when they aren't.
7 million dollars is peanuts for amazon btw
reply