I still want humans in the loop, interpreting the LLMs findings and providing a sanity check.

You can’t hold an LLM accountable.

That’s the min responsible bar for LLM authored code, which normally doesn’t really matter much. For something as important as ER diagnostics, having a human in the loop is crucial.

The narrative that these tools are replacing human intelligence rather than augmenting it is, quite frankly, stupid.

We should embrace these tools.

But, “eliminating DRs”… hardly.

How often do they ship new versions?

My understanding is that:

1. Windows drivers are Attested by Microsoft

2. Windows collects driver telemetry

Which means a really good question to ask is:

Why are they canceling driver signing accounts without looking at metrics?

You just need to get a publicly trusted CA to mint a certificate for your new site.

This can be done, for example, with let’s encrypt, using several of the various domain verification challenges they support.

There are some protections against this, such as CAA records in DNS, which restrict which CAs can issue certs and depending on the CA which verification methods are allowed. That may not provide adequate protection.

For example if you are using LE and are using verification mechanisms other than DNS then the attacker could trick LE to issuing it a cert.

That also depends on the security of DNS, which can be tricky.

So, yes, BGP hijacks can be used to impersonate other sites, even though they are using HTTPS.

When you configure your domains, Make sure you setup CAA, locked down to your specific CA, and have DNS sec setup, as a minimum bar. Also avoid using DV mechanisms that only rely on control over an IP address, as that can be subverted via BGP.

Dependency injection is good. It makes it possible to test stuff.

Automagic wiring of dependencies based on annotations is bad and horrible.

If you want to do dependency injection, you should do it the way Go programs do it. Create the types you need in your main method and pass them into the constructors that need them.

When you write tests and you want to inject something else, then create something else and pass that in.

But the idea that you create magic containers and then decorate packages or classes or methods or fields somewhere and then stuff suddenly gets wired into something else via reflection magic is a maintenance nightmare. This is particularly true when some bean is missing, and the one guy who knows which random package out of hundreds has that bean in it is on vacation and the poor schmucks on his team have no clue why their stuff doesn't work.

"I added Spring Boot to our messy Java project."

"Now you have 3 problems."

If you have ever operated GitHub Enterprise Server, it’s a nightmare.

It doesn’t support active-active. It only supports passive standbys. Minor version upgrades can’t be done without downtime, and don’t support rollbacks. If you deploy an update, and it has a bug, the only thing you can do is restore from backup leading to data loss.

This is the software they sell to their highest margin customers, and it fails even basic sniff tests of availability.

Data loss for source code is a really big deal.

Downtime for source control is a really big deal.

Anyone that would release such a product with a straight face, clearly doesn’t care deeply about availability.

So, the fact that their managed product is also having constant outages isn’t surprising.

I think the problem is that they just don’t care.

This is a bit of a franekin-distro, as it's ubuntu + nvdia packgages + system 76 packages, but it works pretty well.

I've been using Flatpack chromium, which is ok for most things. It performs a bit better than Firefox does. Having access to official Chrome will be nice though, as it should come with Widevine support. Chromium doesn't support DRM, so some things like Netflix don't work.

From the paper:

“we find that the LLM adheres to the legally correct outcome significantly more often than human judges”

That presupposes that a “legally correct” outcome exists

The Common Law, which is the foundation of federal law and the law of 49/50 states, is a “bottom up” legal system.

Legal principals flow from the specific to the general. That is, judges decided specific cases based on the merits of that individual case. General principles are derived from lots of specific examples.

This is different from the Civil Law used in most of Europe, which is top-down. Rulings in specific cases are derived from statutory principles.

In the US system, there isn’t really a “correct legal outcome”.

Common Law heavily relies on “Juris Prudence”. That is, we have a system that defers to the opinions of “important people”.

So, there isn’t a “correct” legal outcome.

And it’s not unreasonable to assume it’s going there.

That being said, the models are not there yet. If you care about quality, you still need humans in the loop.

Even when given high quality specs, and existing code to use as an example, and lots of parallelism and orchestration, the models still make a lot of mistakes.

There’s lots of room for Software Factories, and Orchestrators, and multi agent swarms.

But today you still need humans reviewing code before you merge to main.

Models are getting better, quickly, but I think it’s going to be a while before “don’t have humans look at the code” is true.

If you have a large dependency graph, you are going to have a lot of vulnerable stuff.

Letting one computer send you patches and the other computer merge it for you when all your tests pass is a good thing.

https://github.com/marqeta/pr-bot

The answer to dependabot, or snyk prs is to automatically merge them once all the status checks pass.

This free your devs from having to worry about patching.

PR-BOT will let you define policy on when it’s ok to automerge prs.

It also has the following quotes:

1. "The results were striking: 127 cancers, 30.7% of all cases, were missed by the AI system"

2. "However, the researchers also tested a potential solution. Two radiologists reviewed only the diffusion-weighted imaging"

3. "Their findings offered reassurance: DWI alone identified the majority of cancers the AI had overlooked, detecting 83.5% of missed lesions for one radiologist and 79.5% for the other. The readers showed substantial agreement in their interpretations, suggesting the method is both reliable and reproducible."

So, if you are saying that the article is "not about AI performance vs human performance", that's not correct.

The article very clearly makes claims about the performance of AI vs the performance of doctors.

The study doesn't have the ability to state anything about the performance of doctors vs the performance of AI, because of the issues I mentioned. That was my point.

But the study can't state anything about the sensitivity of AI either because it doesn't compare the sensitivity of AI based mammography (XRay) analysis with that of human reviewed mammography. Instead it compares AI based mammography vs human based DWI when the humans knew the results were all true positives. It's both a different task ("diagnose" vs "find a pattern to verify an existing diagnosis") and different data (XRay vs MRI).

So, I don't think the claims from the article are valid in any way. And the study seems very flawed.

Also, attempting to measure sensitivity without also measuring specificity seems doubly flawed, because there are very big tradeoffs between the two.

Increasing sensitivity while also decreasing specificity can lead to unnecessary amputations. That's a very high cost. Also, apparently studies have show that high false positive rates for breast cancer can lead to increased cancer risks because they deter future screening.

Given that I don't have access to the actual study, I have to assume I am missing something. But I don't think it's what you think I'm missing.

Can you clarify?

I also hinted at the fact that I only had access to the posted summary and the original linked article, and not the study. So if there is data I am missing… please enlighten me.

1. They only tested 2 Radiologists. And they compared it to one model. Thus the results don’t say anything about how Radiologists in general perform against AI in general. The most generous thing the study can say is that 2 Radiologists outperformed a particular model.

2. The Radiologists were only given one type of image, and then only for those patients that were missed by the AI. The summaries don’t say if the test was blind. The study has 3 authors, all of which appear to be Radiologists, and it mentions 2 Radiologists looked at the ai-missed scans. This raises questions about whether the test was blind or not.

Giving humans data they know are true positives and saying “find the evidence the AI missed” is very different from giving an AI model also trained to reduce false positives a classification task.

Humans are very capable at finding patterns (even if they don’t exist) when they want to find a pattern.

Even if the study was blind initially, trained humans doctors would likely quickly notice that the data they are analyzing is skewed.

Even if they didn’t notice, humans are highly susceptible to anchoring bias.

Anchoring bias is a cognitive bias where individuals rely too heavily on the first piece of information they receive (the "anchor") when making subsequent judgments or decisions.

They skewed nature or the data has a high potential to amplify any anchoring bias.

If the experiment had controls, any measurement error resulting from human estimation errors could potentially cancel out (a large random sample of either images or doctors should be expected to have the same estimation errors in each group). But there were no controls at all in the experiment, and the sample size was very small. So the influence of estimation biases on the result could be huge.

From what I can read in the summary, these results don’t seem reliable.

Am I missing something?

> From a Hacker News perspective, I wonder what this means for engineers working on HBO Max. Netflix says they’re keeping the company separate but surely you’d be looking to move them to Netflix backend infrastructure at the very least.

The HBO Max service has something like 128M subscribers. This is < half of the 301M subscribers Netflix has, but is still a large number.

Certainly there's going to be some duplication, but it would be unwise to suddenly disrupt the delivery vehicles that you have 128M paying customers using in favor of a different delivery vehicle.

So, you should expect all the various HBO Max clients in existence to continue working for at least 5 years after the acquisition closes, if not longer.

Suddenly turning that off and saying "go use the Netflix app" wouldn't be good.

In any case, moving all the WB content onto the Netflix CDN and making it available on all the Netflix clients is "product integration", not "infrastructure integration". You are likely to see that very quickly. Weeks to months after the acquisition closes.

But, getting rid of all the HBO Max client software that talks to the HBO Max Servers running in whatever data center or cloud WB is using, and downloading video from whatever CDN WB has, and all the associated infra stuff, that's infra integration and it won't happen for a while. I think that will take 5-10 years.

They don’t have a pop os iso for arm64, but they do have arm64 Debian repo. So I just took DGX os (what Nvidia ships on the device), added the pos os “releases” repo, and installed cosmic-session.

It works like a charm and provides a super useful tiling experience out of the box.

This is replacing my M3 Pro as my daily driver and I’ve been pretty happy with it.

I recently upgraded to an ultrawide monitor and find the Cosmic UX to be hands down better than what I get in the Mac with it.

If you want a Linux desktop with the productivity boost of a tiling window manager with a low learning curve, it’s pretty good.

Look at GitHub as an example, they were acquired in 2018, and are just migrating to Azure now after 7 years.

Microsoft shipping integrations with GitHub in 20108.

This is definitely the case with several Salesforce acquisitions (early product integration, little, no, or much later infrastructure integration).

So… I predict some level of content integration within a few months.

But infra integration is likely years away.

The technique could be implemented without conditionals, but not in python, and not using iterators.

You could do it in C, and use & and ~ to make the cyclic counters work.

But, like I mentioned, the code in the article is very far from being free of conditionals.

Saying the code doesn’t have conditions or booleans is only true if you completely ignore how the functions being called are being implemented.

Cycle involves conditionals, zip involves conditionals, range involves conditionals, array access involves conditionals, the string concatenation involves conditionals, the iterator expansion in the for loop involves conditionals.

This has orders of magnitude more conditionals than normal fizz buzz would.

Even the function calls involve conditionals (python uses dynamic dispatch). Even if call site caching is used to avoid repeated name lookups, that involves conditionals.

There is not a line of code in that file (even the import statement) that does not use at least one conditional.

So… interesting implementation, but it’s not “fizzbuzz without booleans or conditionals”.

For example, there’s a very high chance a single random instruction would page fault.

If you want to generate random instructions and have them execute, you have to write a tiny debugger, intercept the page faults, fix up the program’s virtual memory map, then re-run the instruction to make it work.

This means that even though high entropy data has a good chance of producing valid instructions, it doesn’t have a high chance of producing valid instruction sequences.

Code that actually does something will have much much lower entropy.

That is interesting…even though random data is syntactically valid as instructions, it’s almost certainly invalid semantically.

If you want your library to operate on bytes, then rather than taking in an io.Reader and trying to figure out how to get bytes out of it the most efficient way, why not just have the library taken in []byte rather than io.Reader?

If someone has a complex reader and needs to extract to a temporary buffer, they can do that. But if like in the author's case you already have []byte, then just pass that it rather than trying to wrap it.

I think the issue here is that the author is adding more complexity to the interface than needed.

If you need a []byte, take in a []byte. Your callers should be able to figure out how to get you that when they need to.

With go, the answer is usually "just do the simple thing and you will have a good time".