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.
Private insurance companies still do not cover pre-existing conditions. How? By not writing insurance to individuals except during ACA open enrollment. I know this because I tried to get private insurance before going to Mayo Clinic, because my ACA insurance with Ambetter was out of network. When I got through to an insurance company sales person for individual coverage, they told me they don't cover pre-existing conditions for 6 months. When I challenged them and said that's illegal, they hung up on me. Most companies I called had a phone menu that, when I pushed the buttons for individual coverage, would lead me into a loop, hang up on me, put me on hold forever, etc. They simply won't write individual coverage outside a couple of months at the end of the year. This effectively allows them to not cover pre-existing conditions, at least for individuals. For company employees, yes, the coverage of pre-existing conditions is a win.
I ended up paying $12K to Mayo for a week of appointments. Private insurance, if I could have gotten it, would have been at least $1000/mo for premiums (in 2020) plus $10K deductible, so I actually saved money just paying Mayo instead of getting private insurance.
IMO the only reason insurance companies allowed the ACA to pass was the stipulation that everyone in the US was required to get insurance coverage or face a penalty. When the Supreme Court ruled that provision illegal, I'm sure the insurance companies were furious that they were duped.
That's how it was supposed to work though? There's an open enrollment period where anyone can sign up, pre-existing conditions or not. To prevent the adverse selection problem, which is where you don't sign up for insurance until you have a condition and then cost the insurance company a lot of money, you can only sign up at that time.
The thing you're trying to do - sign up for insurance to cover a specific procedure - is quite literally what the system is designed to prevent. You're supposed to have insurance all the time or none of the time. Did you try asking the clinic how much it would cost if you are uninsured and paid cash?
Your story is missing some pieces. Why didn't you sign up during ACA open enrollment? Those policies absolutely do cover pre-existing conditions. But not every provider organization will be in network for every health plan.
>Private insurance companies still do not cover pre-existing conditions. How? By not writing insurance to individuals except during ACA open enrollment.
Sorry I'm struggling to follow here. You think the open enrollment period effectively means that there's no prohibition on pre-existing conditions? Think you're kind of bending words outside of their normal usage because quite literally pre-existing condition policies are banned. The compensating counterbalance is a neutral open enrollment period so people don't just jump when they learn they have a health problem, it's a compromise to ensure financial sustainability.
You do understand that before this, it was worse right? One comment after another here is comparing the ACA to a magical fantasy, rather than the status quo that it improved upon.
It’s probably the single worst decision of the entire bill and one of the largest wealth transfers in history.
If you tell me you’re going to light your house on fire and then ask me for fire insurance, I should be able to say no.
Instead what we have is not insurance, but the world’s worst socialized health plan. Insurance is for managing tail risk, not for distributing the cost of healthcare. If we’re willing to pay a tax to subsidize the elderly, we should cut out the middleman and let the government fill that function.
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?
I find the "compression" argument not very strong, both because copyright still applies to (very) lossy codecs (e.g. your 16kbps Opus file of Thriller infringes, even if the original 192khz/32bit wav file was 12,000kbps), and because copyright still applies to transformed derivative works (a tiny midi file of Thriller might still be enough for the Jackson's label to get you)
> This is Google v Oracle all over again - are APIs copyrightable?
Yes this is the best way to ask the question. If I take a public facing API and reimplement everything, whether it's by human or machine, it should be sufficient. After all, that's what Google did, and it's not like their engineers never read a single line of the Java source code. Even in "clean room" implementations, a human might still have remembered or recalled a previous implementation of some function they had encountered before.
> LLMs do not encode nor encrypt their training data. The fact they can recite training data is a defect not a default.
About this specific point, it is unclear how much of a defect memorization actually is - there are also reasons to see it as necessary for effective learning. This link explains it well:
"The clean-room reimplementation test" isn't a legal standard, it's a particular strategy used by would-be defendants to clearly meet the standard of "is the new work free of copyrightable expression from the original work".
> 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 think the other important step is to reject code your engineers submit that they can't explain for a large enterprise saas with millions of lines of code. I myself reject I'd say 30% of the code the LLMs generate but the power is in being able to stay focused on larger problems while rapidly implementing smaller accessory functions that enable that continued work without stopping to add another engineer to the task.
I've definitely 2-4X'd depending on the task. For small tasks I've definitely 20X'd myself for some features or bugfixes.
This was a good read and great work. Can't wait to see the performance tests.
Your write up connected some early knowledge from when I was 11 where I was trying to set up a database/backend and was finding lots of cgi-bin online. I realize now those were spinning up new processes with each request https://en.wikipedia.org/wiki/Common_Gateway_Interface
I remember when sendfile became available for my large gaming forum with dozens of TB of demo downloads. That alone was huge for concurrency.
I thought I had swore off this type of engineering but between this, the Netflix case of extra 40ms and the GTA 5 70% load time reduction maybe there is a lot more impactful work to be done.
It wasn't just CGI, every HTTP session was commonly a forked copy of the entire server in the CERN and Apache lineage! Apache gradually had better answers, but their API with common addons made it a bit difficult to transition so webservers like nginx took off which are built closer to the architecture in the article with event driven I/O from the beginning.
every HTTP session was commonly a forked
copy of the entire server in the CERN
and Apache lineage!
And there's nothing wrong with that for application workers. On *nix systems fork() is very fast, you can fork "the entire server" and the kernel will only COW your memory. As nginx etc. showed you can get better raw file serving performance with other models, but it's still a legitimate technique for application logic where business logic will drown out any process overhead.
Forking for anything other than calling exec is still a horrible idea (with special exceptions like shells). Forking is a very unsafe operation (you can easily share locks and files with the child process unless both your code and every library you use is very careful - for example, it's easy to get into malloc deadlocks with forked processes), and its performance depends a lot on how you actually use it.
I think it's not quite that bad (and I know that this has been litigated to death all over the programmer internet).
If you are forking from a language/ecosystem that is extremely thread-friendly, (e.g. Go, Java, Erlang) fork is more risky. This is because such runtimes mean a high likelihood of there being threads doing fork-unsafe things at the moment of fork().
If you are forking from a language/ecosystem that is thread-unfriendly, fork is less risky. That isn't to say "it's always safe/low risk to run fork() in e.g. Python, Ruby, Perl", but in those contexts it's easier to prove/test invariants like "there are no threads running/so-and-so lock is not held at the point in my program when I fork", at which point the risks of fork(2) are much reduced.
To be clear, "reduced" is not the same as "gone"! You still have to reason about explicitly taken locks in the forking thread, file descriptors, signal handlers, and unexpected memory growth due to CoW/GC interactions. But that's a lot more tractable than the Java situation of "it's tricky to predict how many Java threads are active when I want to fork, and even trickier to know if there are any JNI/FFI-library-created raw pthreads running, the GC might be threaded, and checking for each of those things is still racy with my call to fork(2)".
You still have to make sure that that fork-safety invariants are true. But the effort to do that is extremely different depending on language platform.
Rust/C/C++ don't cleanly fit into either of those two (already mushy/subjective) categorizations, though. Whether forking is feasible in a given Rust/C/C++ codebase depends on what the code does and requires a tricky set of judgement calls and at-a-distance knowledge going forward to make sure that the codebase doesn't become fork-unsafe in harmful ways.
So long as you have something like nginx in front of your server. Otherwise your whole site can be taken down by a slowloris attack over a 33.6k modem.
That's because Unix API used to assume fork() is extremely cheap. Threads were ugly performance hack second-class citizens - still are in some ways. This was indeed true on PDP-11 (just copy a <64KB disk file!), but as address spaces grew, it became prohibitively expensive to copy page tables, so programmers turned to multithreading. At then multicore CPUs became the norm, and multithreading on multicore CPUs meant any kind of copy-on-write required TLB shootdown, making fork() even more expensive. VMS (and its clone known as Windows NT) did it right from the start - processes are just resource containers, units execution are threads and all IO is async. But being technically superior doesn't outweighs the disadvantage of being proprietary.
It's also a pretty bold scheduler benchmark to be handling tens of thousands of processes or 1:1 thread wakeups, especially the further back in time you go considering fairness issues. And then that's running at the wrong latency granularity for fast I/O completion events across that many nodes so it's going to run like a screen door on a submarine without a lot of rethinking things.
Evented I/O works out pretty well in practice for the I and D cache, especially if you can affine and allocate things as the article states, and do similar natural alignments inside the kernel (i.e. RSS/consistent hashing).
To nitpick at least as of Apache HTTPD 1.3 ages ago it wasn't forking for every request, but had a pool of already forked worker processes with each handling one connection at a time but could handle an unlimited number of connections sequentially, and it could spawn or kill worker processes depending on load.
The same model is possible in Apache httpd 2.x with the "prefork" mpm.
No user space copies, kernel wires those pages straight to the socket
2. Kernel -> NIC (DMA)
So basically, it eliminates 1-2 memory copies along with the associated cache pollution and memory bandwidth overhead. If you are running high QPS web services where syscall and copy overheads dominate, for example CDNs/static file serving the gains can be really big. Based on my observations this can mean double digit reductions in CPU usage and up to ~2x higher throughput.
I understand the optimisation, I'm just saying I'm sceptical the optimisation is even that useful, like it seems it'd only kick in with pathological cases where kernel round trip time is really dominating; my gut reckons most applications just don't benefit. Caddy in the last few years got sendfile support and with it on and off and it usually you wouldn't see a discernible difference [1].
Which makes me sceptical for the argument for kTLS which is stated in the article; what benefit does offloading your crypto to the kernel provider (possibly making it more brittle). I've seen the author of haproxy say that performance he's seen has been only marginal, but did point out it was useful in that you can strace your process and see plaintext instead of ciphertext which is nice.
Then you don't understand the memory and protection model of a modern system very well.
sendfile effectively turns your user space file server into a control plane, and moves the data plane to where the data is eliminating copies between address spaces. This can be made congruent with I/O completions (i.e. Ethernet+IP and block) and made asynchronous so the entire thing is pumping data between completion events. Watch the Netflix video the author links in the post.
There is an inverted approach where you move all this into a single user address space, i.e. DPDK, but it's the same overall concept just a different who.
So there's this thing called "Setup Scripts" but they don't explicitly say these are equivalent to AWS Metadata and configured inside of Codex web interface - not a setup.sh or a package.json preinstall declaration. I wasted several hours (and lots of compute where Codex was as confused as I was) trying to figure out how to convince codex to pnpm install.
I didn't realize the setup script had to be done in the UI over in the environment tab. I assumed it would be reading something like setup.sh from the codebase.
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.