eqvinox

Right, but a comparison is always one more implicit derivative. If you look at revenue itself, it's growing or shrinking, that's first derivative. So there's one more derivative here than usual?

I guess the interesting thing would be to look at actual company assets/value rather than revenue; revenue already in itself is a derivative. I.e., contrast their revenue against expenses. Last I heard those numbers are deep red, aren't they?

> The SFP+s use the same SC connector used in PON networks, but otherwise use Active Ethernet. I’m not sure if they’re using IEEE standards or are proprietary on the glass, but I’ll assume the latter.

It's actually standards compliant (unless they screwed something up). IEEE 802.3 clause 158: 10GBase-BRx, where x = 20 in this case, at least the ones on the Amazon link say 20km. The 1G/2G support is "bonus" beyond the spec.

You can get them with LC connectors too, which I'd in fact recommend because those are smaller, a bit more precise, and waaaaaay more common these days. https://www.fs.com/eu-en/products/36351.html (note you need a pair of "23" and "32")

Growth being the first derivative… so… not particularly desperate?

A lot of things can be done wrong enough to make them outright silly… doesn't really mean anything about the thing itself.

In fansub times we used to supply that cultural context as onscreen notes when it was important enough. (In most cases you'd have needed to pause to read them.) Seems to have fallen out of fashion though.

Err… it's not particularly good methodology to just consider words for Japanese. While it's true that a lot of kanji share pronunciations (and you thus can't identify them from hearing them on their own) you can still get at some compounds from context and "knowing 2 halves". (Kanji are quite frequently used in groups of 2 to form words, and a lot have only one reading when used in this manner. Personally speaking, I really need some context to get anywhere though.)

> Strings sometimes turned into eight-bit integers (#37)

FINALLY we know what happened with eMudhra's keys!

(Sorry. Really couldn't resist.)

> vendor who feels it their duty to provide color commentary

Honestly? At some point there's a fiduciary-like obligation for it. What ParticleDB delivered is so far past good or bad, it's just straight ugly and then some. It's so poor that, if Jepsen couched it in any way, they'd be implicitly misleading their readers.

They probably asked an AI to run the tests against their DB. And the AI said "yeah I ran it, all green!" (except with a lot more words and perfect grammar, and maybe a few section headings and emoji.)

Even the PR description reads like it has been generated by an LLM.

What a waste of CO₂.

Agree with the 2 siblings: the problem is HN readers at large unable to read it, hence no useful discussion.

I'd also add: from paid online news, I also expect a moderated forum/comment section, with a human to escalate to if automatic/AI moderation fails.

Right; I was thinking about upgrades, sorry.

Connectors are expensive, high-speed ones particularly. $30 is fine, though it makes a giant difference at what quantity that is. Did you look at a single one or 1k?

If you live in Shenzhen, it's a subway trip away. Good repair services elsewhere can do it too. Either way any warranty you have is probably getting called into question after that, even if that's supposed to be illegal in some places (e.g. the US - they're supposed to prove that your modification/repair is what caused the warranty fault, but in practice…).

It's an interactive prompt. The model could ask, "how much cooking experience do you have?", provide a short answer using context from that, and then go "do you want more detail?"

I don't think I have ever seen an LLM try to determine what a human's frame of inquiry or related experience / skill level is, though. Might be my new favorite LLM shortcoming.

If it's [or remains] allowed in. The judicial branch is well able to just outlaw it on grounds of safety, trust and reliability. Same for financial auditing, public notaries, ombudspeople, and the likes (i.e. some degree of responsibility to the public, or dual responsibility to the public and a customer/client.)

> I am talking about hands off diagnosis and treatments.

There's no such thing. How a medical professional interacts with a patient is a major part of the profession. Some people are shy, some anxious, dismissive, neurotic, ashamed, obstinate, miseducated, … etc.

You need a ton of interpersonal skills in this, particularly at diagnosis time. I might even go as far as saying it matters more than medical book knowledge. If the patient is too shy to tell you about, say, black stuff in their stool, you may never get to apply that knowledge about colon cancer.

Coincidentally, a family member of mine died of basically that. When somebody asks, we half-jokingly say he died of stubbornness. It's actually the truth, kinda.

Doctors doing diagnosis are detectives putting together clues. Ideally, they have the patient's full cooperation and zero misunderstandings. Worst case, they're being unintentionally sabotaged, bridging world views, and hampered by their own prejudices.

Sounds like we're in agreement that you'll generally need (an AI to produce) a good shot at a diagnosis before ordering these tests then. Your original post sounded like they just get thrown into the mix at initial consultation.

(I do think the radiation concerns are a bit excessive, but there's also the problem of false positives. A lot of people have some weird "deviations" that have no impact at all, but result in goose chases if something else goes wrong and they show up.)

Do you live in the USA? Living in Europe, my experiences as well as what I'm hearing have mostly been pretty good. Not sure I even know anyone with a major misdiagnosis.

(Everything is way over capacity though. Can't recall a specific one but I do think there's a few "took too long, worse off due to that". But that's a scale & system-wide finance issue, not quality.)

> Xrays and MRI

You already blew way past budget, and worse, availability, than most patients can afford. And you want to minimise unnecessary radiation exposure. Those things are ordered when you have indications they will help (with diagnosis or care), not as scattershot to get diagnostic data.

"Up and to the right": https://news.ycombinator.com/item?id=50220850

It sounds like both of you are looking at this with the US healthcare system in mind, and that non-reviewed "study" probably does too.

…which actually makes sense. "The AI said so" might be a magic trick in that absolute hellscape of bad care and financial racketeering.

Medicine is uncommon because there are no practice pieces for a lot of things. This isn't about learning stitches, this is about learning how to interact with a human, figure out what is going on, what tests and checks and options to even order.

Which, coincidentally, won't be solved by AI anytime soon. You'd need a full anthropomorphic robot (it needs to look human for a lot of people to interact with it on a sufficient level), and the ability to distinguish bias from experience from prejudice. (A lot of humans suck at that as well, to be fair.)

Any medical AI at this level will only be as good as the human medical professional using it, and it will make preexistent human-caused bias/prejudice problems much worse.

(Largest one I'm aware of: not being male is an appallingly large handicap to getting properly and correctly diagnosed, even in Western countries.)

What on earth are you talking about? There is no concept of "issuing" anything in DNSsec/DANE. And why are you assuming DNS is frozen in its current state while the Web PKI can be ratcheted down? (And also, I'm not arguing for a "DANE-first" world. I'm arguing for a "DANE-and" world.)

What Verisign can do in all of this is change the NS and DS for a given domain, and Mallory can run different DNS servers for that domain then, giving out different data, including TLSA records. If they do this, they can also get ACME certs, except that will result in a permanent CT entry. Great feature! We should build a clone for DNSsec.

Will the owner of the domain notice either of these things? Hard to say. In both cases, you need to query something (CT logs or DNS caches) for your own domain, and check if things pop up you didn't put there. You can't query specific ISP's caches, that sucks. And it's only visible in DNS while under attack. Still, my gut feeling is more people will actually notice their NS getting messed with, because it happens by accident when they screw up their DNS. "credit card expired" and stuff like that. DS records are automatically monitored by any self-respecting DNSsec implementation for propagation & state triggering, but only for a given list of servers & caches. The attack could probably stay under the radar by keeping 1.1.1.1 and 8.8.8.8 intact, or at least some instances of it.

And then there's that tiny problem that only browsers really care about CT. Anything else is, at best, protected only if it can't be distinguished by fingerprint on TLS connect. DNS can only be subverted on a per-resolver/cache basis. Not really better, not worse, but different.

I have two takeaways from this. First, I should poke some people at IETF about inventing "DT", DNSsec Transparency. I expect it could probably be implemented in the DNS caches [in addition to end resolvers]. That'd be an interesting way of rolling things out: you can cover shitty client devices without changing them at all. If they use a DNS cache doing "DT", they'd be covered, even if not perfectly. The best time to do any of this would've been 2013, when CT came along. The second best time is now.

The other takeaway is, I should probably prod ENISA people to see if the EU bureaucracy can force some things. We've recently started working with them (mostly because the US apparatus is underfunded to hell and can't answer an e-mail with less than 6 months of delay), though we're only a tiny cog. And if the thought of the EU requiring some level of DNSsec or "DANE-and" gives somebody a heart attack: good!

And let's at least not lie about one thing: if "DANE-and" is being validated for a given target, that does prevent exploiting the eMudhra compromise.

P.S.: before we get in another pile of miscommunication: DNSsec/DANE validation goes on the end application or end host DNS component and the cache. The AD bit is a misdesign and scourge on DNSsec, should be ignored on any network packet, and is not what you build trust on. (AFAIK this is consensus in the DNS world, and one of the things getting ratcheted on their side.)

Nah, they're both nonfactors probably. Hard to tell without real research.

(I meant I agree that counting by installations is odd.)

I agree, which is why I found it weird that you argued by way of "email providers generally don't do DANE."¹ - the wording as 'providers' makes an installation numbers based argument, or maybe legal entity numbers based. Definitely not mail volume. So I replied about installations, and then you switched to volume.

(¹ https://news.ycombinator.com/item?id=50173218)

The CVE record wasn't published yet when this particular embargo got broken. AFAIK it got published when the embargo ended, as it should. (I wasn't following anymore at that point, don't know for sure.)

What did happen is that a whole bunch of people had no clue and called the fact that "these 2 CVE IDs will be used for a PHP vulnerability" a CVE leak. Posts were going around yelling "CVE leak!" with a CVE database link that said "no information yet". Part of this is the mushed usage of "CVE" to just mean "vulnerability" rather than "CVE record". But still, quite ridiculous, and annoying. Information that CVE ID XYZ will be used for project ABC is *not* a leak. Like you say, CVE publishing matters. Getting the CVE record contents would be a leak.

> I don't understand what any of this has to do with the point I made.

That's because I don't understand what point you're trying to make. Something here is probably blatantly obvious to you and entirely opaque to me.

> Nothing like that will ever happen in the DNSSEC PKI.

This is a nonsensical statement to me. What is "like that" in DNSSEC? A TLD operator fucking up badly? That's not even the same class of event since the blast radius is at least limited to their TLD(s). For most TLDs (though not gTLDs), the layer 9 "owner" isn't the operator, it'd result in that contract getting cancelled and someone else running the TLD instead. Do you mean, the root keys getting screwed up? That's akin to (and less likely than) a browser shipping a compromised CA store. https://www.iana.org/dnssec/tcrs these people can screw up the DNS PKI for the entire planet, I guess.

The roles between Web PKI and DNSSEC plainly do not line up for simple analogy statements to work. Again: what role in the DNSSEC PKI is getting compromised in your argument?

Yet another warning sign that Anthropic and OpenAI IPOs are doomed.

I assume you meant DNSsec key, not "DANE key"? (No such thing, anyway.) For this discussion to make sense, it has to be the TLD's DNSsec ZSK or KSK.

The fix in either case is key rollover; if it's the KSK it needs to go to the root which will be annoying but doable. The TLD needs to do this, and it'll be complete, for everyone, regardless of updates or shitty devices, after the relevant TTL has passed. The TTL on the root zone's DS records seems to be 1 day.

If the TLD fails to do the key rollover for whatever reason (incompetence, maliciousness, …) - DNSsec is now broken on the entire TLD. So, security of DNS fails down to classic DNS with all spoofing problems and randomization/uniqueness countermeasures we've accumulated over 35 years. Their DNSsec signatures are still valid, DANE is still green. It really depends on your stance on this; personally speaking I'd consider the TLD unusable now and end the post here, but I assume you don't share that view.

Can you spoof/break DANE now? Yes, if you can break DNS. But in that case, you're in a whole lot of trouble already; if you can really break DNS (poison arbitrary resolvers) you can now get a 'classic' (non-DANE) TLS certificate from your favorite ACME provider. If you can't fully break DNS, that essentially leaves MITM situations, i.e. specific individual situations. Part of that is getting improved with DoT, DoH and DoQ (which, yes, have their own issues.) Realistically, browsers would be marking the entire TLD DANE-untrustworthy now.

On Earth-666, you could presumably roll out DLV [DNSsec Lookaside Validation] now — that's the "side root" mechanism that was used before DNSsec became ubiquitous at the TLD level. Most DNS people absolutely hate it. Ignoring that, the one TLD is now screwed and it's a layer 9 fix. Is that better or worse than a compromised CA resulting in every single TLS service being screwed? Neither, just different, I'd argue.

(As batshit crazy as it is, maybe DLV is the answer to the kind of compromise you have in mind. You seem to be happy with browser vendors having a lot of authority and control over trust. A browser could unilaterally decide to roll out DLV on a given TLD, or any level of domain really. Somebody has to run that as a service, though. Unless they ship the records with the browser… but that's getting really extreme now.)

For the sake of useful discussion, another case to consider is a malicious TLD that specifically hates you. (Or was given reason to hate you by legal means.) They can publish completely bogus data for your domain, including DANE records. But they can also get ACME certs… so I'd call that a wash. (Sure, they wouldn't be able to get OV certs. But a situation with OV certs is IMHO also a situation where you wouldn't use DANE exclusively, rather you'd require both DANE & classic PKI.)