That confused me as well. The whole point of CLAUDE.md is that it is automatically injected into the rolling context of any Claude interaction/thread.
That CLAUDE.md file that they've posted is also HUGE - Anthropic themselves recommend keeping it on the more concise side. If you need more, consider just creating dedicated subagents for "UI/UX reviewer", "search", etc.
Exactly correct. A lot of business in Germany is like this, passive-aggressive money taking.
DT is saying they had an agreement of interconnection for payment, Facebook stopped paying, a court said it has to keep paying, and Facebook decided to end the interconnection instead of continuing to pay. DT, in typical German fashion, insists on continuing to receive payment. Because it's Germany, they'll probably go back to court and be able to win another case and forcibly extract payment even though the service is no longer provided.
> DT is saying they had an agreement of interconnection for payment, Facebook stopped paying, a court said it has to keep paying, and Facebook decided to end the interconnection instead of continuing to pay.
This (and the DT article) seems to imply Meta stopped paying without ending the interconnect. That seems like a reasonable reason to want to be paid?
> This (and the DT article) seems to imply Meta stopped paying without ending the interconnect. That seems like a reasonable reason to want to be paid?
It takes two to keep a BGP peering session up: if DT didn't want the traffic without being paid they could have shut things down on their end too:
> the company feeds a gigantic 3.5 terabytes into Deutsche Telekom's network [...] Deutsche Telekom has done everything in its power to ensure smooth data traffic. [...] The start of the rerouting of data traffic in the night from Tuesday to Wednesday went smoothly.
It sounds to me like DT was not prepared to handle the volume of this traffic along the alternate paths it would have taken if Meta's paid transit sessions were removed, so in the interest of avoiding disruption of their network, kept them running temporarily, settlement-free, until mitigation was completed. Great deal for Meta while it lasted!
The word "deal" implies some kind of (commercial) transaction that has a price tag associated with it (deal = good price).
But DT keeping this peering connection up should be (IMHO) DT just doing the job they're paid for.
DT's customers pay for "Internet access", and since Meta is on the Internet, the customers should be able to connect to it. Customer's send requests to Meta, DT passes those requests along, and it is DT's job to pass along Meta's responses.
Why should Meta pay DT anything? DT is claiming to offer a service, and part of that service is transporting the responses to DT's customer's requests. If those responses are high bandwidth it is part of DT's job to deal with it. If 'dealing with it' entails special connections to particular corners of the Internet to better serve their customer's then it is DT's job to do that.
> The word "deal" implies some kind of (commercial) transaction that has a price tag associated with it (deal = good price).
The value that Meta received is equivalent to what Meta is now paying their third-party transit provider to transit this same volume of traffic to DT. My napkin math suggests that this is tens to hundreds of thousands of dollars per month, at 3.5Tbps and pennies per megabit.
> DT's customers pay for "Internet access", and since Meta is on the Internet, the customers should be able to connect to it.
What do you mean by "on the Internet"? Meta is "on the Internet" by virtue of paying transit providers to propagate their IP prefixes within the DFZ.
You can't just show up at an IXP or other peering location, announce your routes, and expect them to propagate globally. You need to convince at least one transit-free network to carry them before you're truly "on the Internet". Meta used to pay DT for transit, and now they don't. Meta is now "on the Internet" via third-party transit, rather than directly via DT.
> Why should Meta pay DT anything?
Meta doesn't need to pay DT anything, but if they're not paying, they shouldn't expect free connectivity services from DT. This traffic can now flow between DT and Meta via transit, instead of directly between DT and Meta.
> If 'dealing with it' entails special connections to particular corners of the Internet to better serve their customer's then it is DT's job to do that.
Which is exactly what DT did by providing settlement-free peering, temporarily, while their links with other ISPs, who they do have a business relationship with, could be beefed up. Now those links can handle the traffic, and now the traffic is flowing over them rather than over direct peering with Meta. No traffic was dropped in the process; neither DT's customers nor Meta were or are being harmed.
> It seems to be a project and a commercial vision with tremendous potential, one that investors see as a pivotal piece of the cloud puzzle and are willing to pour in significant capital to help build.
Monetising open source is something that I've struggled with. Can you speak to the business model, Matthias?
Hey Alexis. The business model is a pretty standard Open Source business model: We ensure the Crossplane community is striving, and it has all the building blocks needed. In Upbound we position ourselves as a trusted partner for Crossplane and build products on top of Crossplane. Our current ones you can find at https://www.upbound.io/. It’s important that there is a mutual benefit between the community and our products: The more successful Crossplane is, the more successful Upbound is and vice versa.
Instana is building application performance management for the microservice & cloud-native area. Founded by APM veterans, Instana provides automation and artificial intelligence to deliver the visibility needed to effectively manage the performance of today’s dynamic applications.
We are a young and fast-growing startup with a solid funding and already great revenue. We are looking for various positions in the engineering organization, and I would like to get you especially excited about our very technical product management positions: https://instana.breezy.hr/?&department=Product%20Management
As a PM you would be working with all programming environments on the latest cloud technologies and make them observable in an automated way to developers worldwide. For a nice dose of buzzwords have a look at our supported technologies: https://www.instana.com/supported-technologies/. You will develop and own the product vision, strategy and roadmap for a particular product area.
If you have any questions to a potential PM colleague feel free to drop me an email at matthias dot luebken @ instana . com and apply via instana.breezy.hr
> A new company emerged from stealth today, aimed at helping developers better automate the work they’re doing. Called Atomist, it’s designed to help developers automatically create source code repositories and then automate the deployment of their code in a way that helps ensure quality while maintaining the velocity of rapid changes.
Someone elsewhere in this thread complained about the NFS experience with k8s. I know OpenShift contributed some or all of that code so does it improve the NFS experience as a layer on top of k8s?
All of the code Red Hat contributed around Kubernetes storage plugins went into Kubernetes upstream. If you have any questions or problems, feel free to raise an issue or reach out to us in the community. Red Hat has a large number of contributors on the Kubernetes project and we are big fans of the community and the technology!
Red Hat OpenShift provides a an enterprise-ready Kubernetes distribution that also builds on top of Docker, RHEL/Fedora/CentOS and includes integrated networking (OVS), routing (HAProxy), logging (ELK stack), metrics, image registry, automated image builds & deployments, integrated CI/CD (Jenkins), and self-service UX (Web, CLI, IDE). You can check out the free Origin community distro here - https://github.com/openshift/origin or sign up for our free hosted developer preview here: https://www.openshift.com/devpreview/. We also offer commercially supported solutions - https://www.openshift.com/container-platform/.
But yes. Other agent platforms will adopt this pattern.