kikoreis

It's not completely wrong, but overly simplistic:

In 2006, Amazon launched what is now AWS, exposing the internal compute, storage, and database services its retail group had built. The internal pitch was identical to Marketplace seven years earlier.

These were not internal services, and it wasn't exactly the retail group that built them (Chris and Ben were dedicated to EC2 and the team ran remote from Seattle). Nor was Marketplace run on the 1P Amazon platform, so it would have been a strange analogy to use for a pitch.

In the end, though, the point is the same as I made elsewhere in the thread — once you are big enough you can try and bootstrap pretty much anything adjacent to your business and have a good shot at success.

This read was mildly interesting, but I'm left thinking that the study of any sprawling monopoly will come up with similar mildly interesting and irrelevant rationalizations of success. Once you get as as big as Amazon was in the early 2010s, provided your culture doesn't melt down (by itself no small feat), you are well positioned to expand and flatten adjacent parts of the economy.

So the question is whether you read this to be inspired by it and attempt to create your own monopoly, or to be afraid of it and start thinking about regulation. Or both :-)

Actually there is a long and storied history of mechanisms created to compel American companies to comply with requests for digital intervention. A good starting point is the concept of the NSL: https://en.wikipedia.org/wiki/National_security_letter

Relevant acts include https://en.wikipedia.org/wiki/Electronic_Communications_Priv... https://en.wikipedia.org/wiki/Stored_Communications_Act and the more recent https://en.wikipedia.org/wiki/CLOUD_Act

Oh this almost makes me want to go back and consider NFS for our local lab. I used to run it but everywhere having a centralized SPOF was a constant concern, and there isn't a simple HA story for it sadly.

As a user for over a decade, just here to submit my appreciation. healthchecks.io is fantastic.

https://en.wikipedia.org/wiki/Lenna

Without any context provided, the state-of-the-art model, GPT-5.1 (High), is only able to solve less than 1% of tasks. This starkly demonstrates that the data is contamination-free, as the model is almost entirely incapable of solving the tasks without learning from the context.

[...]

[With context provided,] on average, models solve only 17.2% of tasks. Even the best-performing model, GPT-5.1 (High), achieves just 23.7%.

Swofy makes a little media player that has physical buttons; the crowd here at home really likes them: https://a.co/d/9icRCCs

Your comment made me think of Charli XCX's recent post https://itscharlibb.substack.com/p/the-realities-of-being-a-...

Who was the actress?

Resolver limitations, as opposed to server or protocol issues, are in my view the main reason why "it is always DNS".

Oh it's lwn.net for me!

(Stretching a definition of social network.)

Not strictly but Debian, where member inclusion is done through an in person chain of trust process so you have clusters of people who know each other offline as a basis.

Also, most WhatsApp contacts have been exchanged IRL, I presume.

Through regulation?

Well yes but headscale?

Perhaps even stranger, MinIO have publicly stated they have revoked an Apache 2 license grant to a third party, Weka: https://blog.min.io/weka-violates-minios-open-source-license...

Not sure what their counsel is thinking there..

That's interesting. I was reading their licensing compliance FAQ at https://min.io/compliance and it doesn't allude to that; in fact it suggests that for instance calling a REST API doesn't imply derived work (modulo the specificity piece), referencing the GPL. The omission of the over-the-network AGPL provision is notable. I wonder if it's obscure on purpose?

Nah, the AGPL is pretty clear (and way clearer than the GPL and LGPL due to combined/derived work fuzziness). The issue with it isn't anything to do with the mechanism of the license itself, because it is pretty clear what the criteria are (and offering an API over the network definitively constitutes Remote Network Interaction) and how you can fulfill the source distribution. The real issue is that the AGPLv3 doesn't preclude a third party from commercializing the software (whether modified or not).

I can explicitly cancel a subscription after a certain date—what is the problem with me explicitly cancelling a subscription after a certain amount of spend?

As someone also involved in billing systems for public clouds: in theory there's no difference, but in practice there is a world of difference. This is the sort of situation where the end user is commonly surprised with the consequences of their own decisions. At MGC we have some "soft shut down" processes, and we constantly hear stuff like "I know I said shut down, but this is the one situation where that really didn't make sense"; where examples are "storage which keeps backups became unavailable", "a very simple but critical user auth system disappeared", "I had no idea this was still running on my account", or "OMG not in the middle of the weekend", etc. You can build heuristics and tracking into the system to minimize these situations, but that's a lot of work.

So yeah, it is a valid use case and something many CSPs would like to provide, but implementing something that is actually better than nothing is non-trivial.

Well, the comment from OP isn't necessarily complete. The AGPL is not about preventing someone from using source code (indeed that would be contrary to the spirit of all liberal and copyleft licenses), but rather the condition under which source code modifications need to be made available.

Specifically, if you offer the software for "Remote Network Interaction" (AGPLv3 section 13), well, "if you modify the Program, your modified version must prominently offer all users interacting with it remotely through a computer network (if your version supports such interaction) an opportunity to receive the Corresponding Source of your version".

I think the original challenge with AGPLv3 vs (to grossly generalize) the VC-backed open source corporate ecosystem was not around source code, but around monetization as SaaS by the hyperscalers. The problem there is even if the hyperscalers publish source code modifications (which they probably have no problem with) they have such sales efficiency and gravitational pull that they will end up eating your business.

What could go wrong?

What does the risk classification applied to the dataset actually mean? The licensing page [1] AI2 provides for their datasets is really nice but it doesn't really explain [2] what risk means in the context.

Does it mean "risk that the items contained in this set are licensed in a manner incompatible with its use in a training dataset"?

[1] https://allenai.org/impact-license

[2] "the AI2 ImpACT Licenses are artifact-agnostic and are instead structured according to the risk level we’ve assigned a given artifact"

I think "[automated] disassembly" has a different implication than reverse-engineering; the latter usually involves more depth in the analysis of the binary, usually including more semantic-level considerations (i.e. this block is meant to do this, or this function is used from these different callsites). The best examples of this type of analysis seem to exist in the security community when going into the detail of zero-days, exploits, etc. I think LLMs either already can or will soon enter that space.

"danger abstraction too high, big brain type system code become astral projection of platonic generic turing model of computation into code base"

Given my history I'm definitely not a fan of this madness in the licensing space. But I am also willing to acknowledge that the 1P vs 3P bomb set off by the public cloud incumbents will continue to yield damage to the open source startup ecosystem until something changes.

That's fixable via browser.urlbar.trimURLs: https://support.mozilla.org/en-US/questions/881261

I'm as perplexed as the dog

Well, the reason Linus could confidently choose to license the kernel as GPLv2 is exactly because it inherited no incompatibly-licensed code.

USL v. BSDi (also 1992 — what a year!) is evidence of how non-trivial this actually is: https://en.wikipedia.org/wiki/UNIX_System_Laboratories,_Inc.....

Ah, it seems that Raspbian built for ARMv6 but still used the ABI tag "armhf", how confusing; I guess Alpine has done something similar.

https://wiki.debian.org/RaspberryPi#Raspberry_Pi_OS_.28forme...

FWIW, the Raspberry Pi 1B is an ARM11, which is why you are getting and booting an ARMv6 kernel. v6 is the architecture; the "l" at the end of "v6l" indicates it's little endian.

As for "armhf" it is a description of the the ABI, and the "hf" means what you said, that the hardware supports floating point operations. I'm slightly confused as to how armhf could work on the ARM11 on the Pi 1 and Zero generations, as AFAICR it targeted v7 onwards.

For those curious about what's going on (the post was removed) they merged with TWS: https://your.online/press-release/