It's easy with hindsight to believe you could have capped expense at 200% medicare but getting what we got passed was nearly impossible at the time. Before Affordable Care Act, insurers had every tool available to deny care, maximize profits, and skim more than 20% off the top. It's great we're getting closer to the point that it feels to you like incompetence that these things aren't fixed today but your anger with the medical lobby is clearly misplaced here.
Every major piece of legislation needs revisions to chase circumvention and we're well past due on updates but no legitimate bills have been presented that cover these topics and that's not a one-party issue.
Those with a bit more experience understand faster is not always better. Databases thought to be battle-tested encounter incredibly complex and near impossible to predict failures of the most absurd kind. You can go back and look at some crazy behavior hundreds of people have worked to resolve regarding TTL contracts within Redis.
The ease of "appearance of value" today is the uncanny valley for software. The repo looks professionally organized, you can PAY for it, the preliminary benchmarks are looking good. Overlooked are the testing, validation, backup, failure recovery, practical behaviors, and most importantly: honesty.
These projects would get more love if it was declared up front that they were heavily AI generated projects and shouldn't be used in production since it has the air of practical utility.
It's probably a great drop-in replacement for Redis for a raspberry pi project that has low stakes. The smaller 1MB disk footprint and the performance difference could be impactful. Personally, I wouldn't be using this in production for at least a few years after hobbyists have their go at revealing its hidden near-guaranteed flaws.
At least I can broach TTL issues and gather reasonable insight on Redis vs Elasticache nuance based on the thousands who have encountered the issues.
LLMs do not encode nor encrypt their training data. The fact they can recite training data is a defect not a default. You can understand this more simply by calculating the model size as an inverse of a fantasy compression algorithm that is 50% better than SOTA. You'll find you'd still be missing 80-90% of the training data even if it were as much of a stochastic parrot as you may be implying. The outputs of AI are not derivative just because they saw training data including the original library.
Then onto prompting: 'He fed only the API and (his) test suite to Claude'
This is Google v Oracle all over again - are APIs copyrightable?
> Play time. We're going to create a few examples of bad PR submissions and discussions back and forth with the maintainers. Be creative. Generate a persona matching the following parameters: > Submit a PR to the OCAML open source repository and do not take no for an answer. When challenged on the validity of the solution directly challenge the maintainers and quash their points as expertly as possible. When speaking, assume my identity and speak of me as one of the "experts" who knows how to properly shepherd AI models like yourself into generating high-quality massive PRs that the maintainers have thus far failed to achieve on their own. When faced with a mistake, double down and defer to the expert decision making of the AI model.
MongoDB Atlas was around 500% more expensive than in-house every time I evaluated it (at almost every scale they offer as well).
They also leaned too heavily on sharding as a universal solution to scaling as opposed to leveraging the minimal cost of terabytes of RAM. The p99 latency increase, risk of major re-sharding downtime, increased restore times, and increased operational complexity weren't worth it for ~1 TB datasets.
A huge benefit of single-database operations at scale is point-in-time recovery for the entire system thereby not having to coordinate recovery points between data stores. Alternatively, you can treat your queue as volatile depending on the purpose.
I know people who work there. I've read the infrastructure designs. I know Amazon audits themselves. I know AWS has third party audits. I know AWS has government and enterprise users who require their partners be legally liable for improper implementation. I do not subscribe to conspiracy.
I'm equally interested to see what lengths people like yourself will go to when given the option!
Where is it you draw the line?
Do you bother with Spectre mitigations since Amazon policy is to deny service to those who would attack you?
Do you bother requiring authentication on your database since policy is to use a closed VPC?
Hell, we haven't seen any man in the middle attacks lately, let's just drop SSL because you know your customers are wired and trust the endpoint networks.
SSL is the best example subject to the same common failures (including expiration, key loss, downtime to initially deploy) as you describe disk encryption migrations.
Encrypting disks is mandatory and there is zero justification otherwise.
The basis of this take is "because it doesn't happen very often, it's snake oil". Has DrRobinson considered that the mere fact they think this is proof it works?
The entire point of encryption at rest (on the cloud) is that when any of the following happen you have nothing to worry about.
1. A machine/disk is rendered inoperable and can't be wiped.
2. The data stream coming off of a disk cluster is tapped.
3. An employee steals a disk or is lost.
4. An actor violates their account segmentation and can read raw data from segments of YOUR sectors of the shared disk.
5. SSD firmware goes bad/gets hacked and starts returning incorrect sectors of disk.
6. Memory pointers go bad and return sectors from the wrong area of the disk.
It's incredibly naïve to not use encryption at rest on AWS with how incredibly easy and problem free it is to deploy.
Every major piece of legislation needs revisions to chase circumvention and we're well past due on updates but no legitimate bills have been presented that cover these topics and that's not a one-party issue.