growse

We could live in a world where they don't exist and the vast majority of major financial institutions still wouldn't implement DNSSEC.

https://dnsinstitute.com/research/2020/banks-dnssec-202010.h...

You don't have to like, or agree with anyone. The data tells its own story.

Isn't the vast majority of TLS connections using SNI today?

Slack's house literally did burn down for 24 hours because of DNSSEC back into 2021.

When you frame the risk as "marginal benefit against one specific threat" Vs "removes us from the internet for 24 hours", the big players pass and move on. This is the sort of event the phrase "sev 1" gets applied to.

Some fun companies have a reg requirement to provide service on a minimum SLA, otherwise their license to operate is withdrawn. Those guys run the other way screaming when they hear things like "DNSSEC" (ask me how I know).

What percentage of the fortune 500 is served over DNSSEC?

I'm interested in your idea that "merit" is some sort of objective measure.

If it works for me but not for you, does it have more merit?

> Replying to some sibling comments asking why anyone wouldn't want to use systemd.

I get why some people don't want to use systemd. That's fine.

I really don't understand why this group of people are so passionate about broadcasting this opinion to anyone within earshot. They don't like a piece of software, great! They've got different values! Use something else!

So with the plethora of people who care about progress and its success, and the army of people willing to work on it for a competitive wage, we should be seeing lots of activity on the project, right?

> Give me an option to donate directly to X11 development and I am gonna support it.

> I would jump at it instantly if someone paid me a competitive wage to do it

You guys should meet up.

What stuff?

> Since /64 is smallest network in IPv6

A /64 is not the smallest network in IPv6. Nothing stops you having a /112 or a /126 or whatever you like.

It is the only network size on which SLAAC works however, so it's a good choice for lan sizes.

> DoH seems to exist mainly to circumvent that control.

Hate to break it to you, but if I control the client, then I'm not in any way obligated to use DNS or any other IETF-endorsed protocol to turn names into numbers when I'm running on your network.

The idea of "controlling what's going in and out of the network" died in the 90s.

> It seems disingenuous to suggest that the open sourcing was in bad faith given it happened years and paradigms apart from the closed sourcing, even though I don't agree with the decision either.

The problem here is that their actions are indistinguishable from an entity that is acting in bad faith. "Get loads of free labour, then claim ownership of it and try to monetize" is a business strategy.

API keys are just Basic Auth wearing a silly hat.

There's so many better options than just dumping the secret on the wire.

> So you don't see how having an automated blackbox that takes copyrighted material as an input and provides a competing alternative that can't be proven to come from the input goes against the idea of copyright protections?

Semantically, this is the same as a human reading all of Tom Clancy and then writing a fast-paced action/war/tension novel.

Is that in breach of copyright?

Copyright protects the expression of an idea. Not the idea.

That doesn't mean that all of the output from an LLM trained on GPL code is a derivative work (and therefore GPL'd too).

> Can we start at "humans are not computers", maybe?

Sure. So it stands to reason that "computers" are not bound by human laws. So an LLM that finds a piece of copyright data out there on the internet, downloads it, and republishes it has not broken any law? It certainly can't be prosecuted.

My original point was that copyright protections are about (amongst other things) protecting distribution and derivative works rights. I'm not seeing a coherent argument that feeding a copyrighted work (that you obtained legally) into a machine is breaching anyone's copyright.

Personally, as an un-paid OSS maintainer, I chose to go get a job. Other's might choose different paths.

Ah I see what you mean. Yes, agree. But that's orthogonal to OSS and like you say is a reg issue.

How is training a model on GPL code and then having it write code any different to having a human read GPL code and then write code?

Unless there's a specific copyright claim over a specific piece of code that was copied and published, it's hard to see how the GPL has any relevance.

If you solely fund the development of the software, you own the feature backlog. If you can't use that as a competitive advantage, I don't really know what to tell you.

I disagree with you on a lot, but you're bang on the money here.

If you want a business, build a business. One key aspect of building a business is understanding what your IP and trade secrets are, how they affect your bottom line, and then controlling them appropriately.

They can't "copy anything".

They can only copy what they're explicitly legally allowed to.

Elastic explicitly allowed AWS to copy and use their source code, then whined about it.

Large companies using their scales to compete is a feature of capitalism, not a bug.

AWS only gets to compete using their source code because they opened it in the first place. The competition was explicitly invited.

The solution to the old problem of "what if someone uses my code to compete with me" is "don't open source your code".

This isn't complicated. It's trade secrets 101.

I'm being disingenuous though. Of course the bait-and-switch merchants know this, they're just banking on getting enough product momentum off the free labour of others before they cash in. That's the plan all along.

This is not a suddenly emerging "gotcha".

This risk has always existed. It existed when they chose to open source it in the first place.

Time and time again we see the lesson being learned the hard way that "if your business value is your codebase, it's hard to build a business whilst literally giving it away".

> Someone that has seized control of your core network such that they were capable of modifying traffic, is not going to waste precious time or access modifying the flags of ls on your man page server. They will focus on more valuable things.

Ah, the "both me and my attackers agree on what's important" fallacy.

What if they modify the man page response to include drive-by malware?

Who do you think signs the DNSSEC root?

Someone asked them why they dropped SMS a few years back and got a detailed reply: https://news.ycombinator.com/item?id=33258684

The most compelling bit here for me is RCS. Lots of devices will auto upgrade an SMS chat to RCS if they think that both ends support it.

Signal cannot support RCS (there's no API) so you'd end up with a situation where someone uses signal to send an SMS, the recipient device then replies over RCS and signal never gets the reply. Not great for usability.

I've just remembered the firewall alignment chart, which asserts a view of the world that an excavator is a firewall.

https://sh.itjust.works/pictrs/image/421c9549-83ee-487a-9fa0...

Sure you can, the tradeoff is that you can't reliably do SLAAC (which I agree needs to get deprecated yesterday).

But this feels tautological. It's been reduced to "If you want to use NAT with features that only a firewall gives you, then that forces you to use a firewall".

I suspect when people talk about "NAT" in the context of a residential connection, what they actually mean is a "default-deny firewall with connection tracking".

Not by allocated IP address count.