I have to agree with much of this, if you need something that feels like "the cloud" but on-premise then you could have used OpenStack for the last 10 years.
The only reasons to use Oxide racks are that you get an all-in-one solution and they don't charge you a subscription fee, you only pay upfront for the hardware once. But if this company goes public one day shareholders will surely push for a subscription based licensing model.
I have yet to see the benefit of "custom software" for "custom hardware". To me it looks like a liability, if Oxide stops to exist tomorrow you'll be left with a hunk of metal which is a dead end. The software being open source doesn't change that, if you have enough manpower to support such software on your own then you can surely support any other more flexible solution.
> we really work with customers to restructure their contracts
Does anyone have such an experience with Datadog? A few million wasn't enough to get them to talk about anything, always paid list price and there was no negotiating either when they restructured their pricing.
>No feeding of solar power to the grid so no permits.
If it becomes popular the slimy solar farm developers and the utility will join hands to hire a lobbyist who will ensure the rules get changed to close the loophole.
You are skipping over the part where you need to bring normal people, specially young normal people, back to google.com for them to see anything at all on google.com. Hundreds of millions of them don't go there anymore.
And when is that going to be? Google clearly has the ability to convert google.com into a ChatGPT clone today if they wanted to. They already have a state of the art model. They have a dozen different AI assistants that no one uses. They have a pointless AI summary on top of search results that returns garbage data 99% of the time. It's been 3+ years and it is clear now that the company is simply too scared to rock the boat and disrupt its search revenue. There is zero appetite for risk, and soon it'll be too late to act.
One of the most interesting Postgres projects I have seen in many years.
The benchmarks presented only seem to address standard pooling, I'd like to see what it looks like once query parsing and cross-shard join come into play.
Thank you! Good feedback. The query parser is cached, so if you're using prepared statements or just the extended protocol with placeholders, it's almost free: cost of a mutex + hash lookup.
Cross-shard joins will be interesting. I suspect the biggest cost there will be executing suboptimal queries without a good join filter: that's what it takes to compute a correct result sometimes. Also, the result set could get quite large, so we may need to page to disk.
I'm focusing on OLTP use cases first with joins pushed down as much as possible. I suspect cross-shard joins will be requested soon afterwards.
Ultimately the CEO is responsible. To me it doesn't even matter if the CEO knows about it or not, if not the company has poor governance which is the CEOs full responsibility.
Wirecard CEO has been arrested since 2020, will probably sit for another 10 years.
The question is should the CEO have know. A CEO that trys to set a culture of doing the right thing, with training on what the right thing is, and other such things can still be deceived by someone low level who cheats. It is possible for one person to cover their tracks for a long time if they are trying to cheat. It can be years to track down who is doing the immoral thing even after you catch something is wrong.
The question this is this one person (or small group) operating against their instructions, or is it the CEO encouraging people to cheat? That can be a hard question, but we want CEOs to think if I do "enough" (whatever that is) to ensure we obey the law I'm okay and thus I want to ensure enough is done. There are always crooks in the world, we want to ensure they are not encourged. If the CEO is always at fault their thought is likely to go to how can I ensure that tracks are covered so they nobody can be convicted.
Those golden parachutes and lavish lifestyle comes with a cost. That cost is responsibility and risks it brings.
Whether he knew or nit is a matter for courst, but in any case he is responsible too. Punish crooks harsh and visibly, reward honesty and good engineering massively and also visibly and company as a whole will act accordingly. We dont talk about a single guy hacking some firmware build, but a well known company culture.
Which CEO? Of the 4 big German manufacturers, which conspired do implement these special cheats, or Bosch which implemented this cheat, and supported it as such?
Or the politicians who wrote into law to able to use such a cheating device?
That would be 5 CEO's plus at least 2 german politicians, plus 20 more politicians in all other countries which selected this cheating EU standard.
> But negligence is fundamentally different from mens rea
It differs in that mens rea is the legal concept of a culpable state of mind, and negligence is one example. More fully, a crime is generally defined by a prohibited act (actua reus) and a wrongful state of mind (mens rea), though there are strict liability crimes with no mens rea required.
For, say, murder (in common law, specific statutory schemes may diverge from this somewhat), the actus reus is homicide, and the mens rea is “malice aforethought”.
While “malice aforethought” is sui generis and seen only in murder, the common kinds of mens rea used in defining crimes, in descending order of the severity with which they are usually treated, are intent, recklessness, and negligence. (The same mental states are relevant in tort liability, though strict liability in tort is more common, and the civil and criminal definitions of negligence, particularly, are somewhat different.)
Right but the Victoria line puts a lot of effort into keeping station stop time to a minimum for the sake of capacity (it's the most intensive metro line in London, at 36-37tph, and one of the most intensive in the world). One way or another you have to space the trains out more to do skip-stopping.
What are multi instance upstream Postgres clusters for you? PostgreSQL has no official support for failover of a master instance, the only mechanism is Postgres replication which you can make synchronous. Then you can build your own tooling around this to build a Postgres cluster (Patroni is one such tool).
AWS patched Postgres to replicate to two instances and to call it good if one of the two acknowledges the change. When this ack happens is not public information.
My personal opinion is that filesystem level replication (think drbd) is the better approach for PostgreSQL. I believe that this is what the old school AWS Multi-AZ instances do.
But you get lower throughput and you can't read from the secondary instance.
>My personal opinion is that filesystem level replication (think drbd) is the better approach for PostgreSQL
That's basically what their Aurora variant does. It uses clustered/shared storage then uses traditional replication only for cache invalidation (so replicas know when data loaded into memory/cache has changed on the shared storage)
reply