Hacker Newsnew | past | comments | ask | show | jobs | submit | easton's commentslogin

Side note: why are shallow clones evil? I always thought they were cheaper, but I guess that’s really just for my disk space. (since the server has to compute what blobs to give you instead of just “everything”?)

Normal clones can reuse delta-compressed data the server stored on disk. Shallow clones impose a negative constraint: do not transfer data outside the requested commit depth. Pre-computed delta chains than contain unrequested data become unusable and the server must do delta compression on the fly to satsify the shallow clone.

What I find remarkable is that for at least a decade, i.e., long before LLM scrapers were a thing, GitHub engineers have been reaching out to popular package manager projects, asking them to do away with shallow clones [0] [1]. They basically used the same reasoning as your comment did.

[0]: https://github.com/Homebrew/brew/pull/9383

[1]: https://github.com/CocoaPods/CocoaPods/issues/4989#issuecomm...


So why not introduce a semi-shallow clone option?

If I'm doing a shallow clone it isn't because I only want to receive a specific commit, it's because I don't want to burn a giant amount of disk space and network traffic on a full history.

In most use cases it would be perfectly acceptable for the server to send additional data. The client doesn't care about it because it is meaningless to them, but if it results in a significant load reduction on the server's side they don't really mind receiving it either. A 100MB shallow checkout coming with 400MB of garbage still beats cloning an entire 5GB history!


It's the point that surprised me the most! We always used shallow clones, to speed the CI, I didn't knew that it got that much impact server side!

Me too! And I'm wondering now.. if it's so awful, is there no way to just block that capability server-side?

Requiring that you believe those companies that they won’t hand the keys over to the US at the first ask.

Like, the critical problem with the AWS sovereign pitch is that you must believe that they won’t give the keys to the US, and they also won’t give the source code that’s hosted in the US to the government either for them to find vulnerabilities in. I don’t know if that’s good enough unless you just need the data to stay in the EU and you don’t care if another country sees it.

I know they probably did some work on it (what if primary AWS goes rogue and the EU entity must work without it) but I don’t know if they explained how they’re safe to the public.


The harder problem here is that any real EU sovereign platform would have to come with ironclad guarantees that it isn't going to be directly or indirectly sold to a US party. And when enough customers move that marketshare is affected the bags with money tempting shareholders will get larger and larger.


Isn’t that counterbalanced by the fact that the reason they exist in the first place is to be a sovereign platform?

I am assuming the reason companies switch to them is not price or tech. US cloud providers have the advantage on both.

Selling EU companies data would mean destroying trust over their main selling point, not to mention incur on EU wrath.

Feels like living one whistleblower away from doom.

I refer to fully EU clouds, parent list includes US clouds that do not need bags of money, Clouds Act in enough.


The most fun one is the Metro stations near the Pentagon, where often the ads will be for fighter jet engine upgrades.

They must work, because they're buying the ad space for about three relevant people.


The company line has been that they expect you to have your own backups in a region outside of the Middle East or you’re hosed until they can turn the (now destroyed) buildings back on.

I wonder if AWS even has the capacity to keep an entire region’s data elsewhere if they wanted to (I mean they could with their margins, but I doubt they do.)


Yeah, they have backups of their shit, not your shit. If you don’t use their cross-region backups, I don’t know what to tell you. Even us-east-1 isn’t entirely immune to disasters manmade or otherwise…


> One recounted a tragicomic anecdote from a T.G.I.F. meeting on International Women’s Day, when a Googler had asked Larry and Sergey to name some of their personal female heroes.

..and they couldn’t just say “Grace Hopper”? These people have used computers before, right?


Grace Hopper is the goat but I'm not sure she would have immediately come to mind for me. Actually, if someone asked me to name any hero of mine, irrespective of sex, I don't know if I could quickly name someone. Is it really a huge indictment?


Go find the drunkest pledge in a Stanford frat house, give him media training a stylist and a personal trainer, and ten years to craft a corporate ideolect through twitter threads and founders' retreats. That's how you get the archetypal tech CEO.

As a class they are overwhelmingly incurious people, and would barely notice if you swapped their industry out for Big Tobacco or bombs. They care exactly as much about tech as Jeffrey Epstein did about finance.


Counterpoint: https://justingarrison.com/blog/2024-02-08-fargate-is-not-fi...

And also, you’ll notice that Fargate takes minutes to launch while Lambda takes a second or less. You’re waiting on AWS to launch a EC2 with your config and pull your containers into it.

(that article matches things I heard from Amazon when I asked why my stuff is slow)


Confirming, I worked directly on fargate.

Fargate does not use firecracker. It was used for some internal workloads but was being migrated off at the end of 2025.


I can't tell you why Fargate is so slow, but the reason Lambda containers are so fast is because it doesn't actually load the image. It loads a manifest of the layers and the files in each, and then each file is loaded on-demand from a multi-tier cache. 90% of the image is never loaded, and 90% of the remainder is served from local cache. It's a pretty cool architecture.


Container pulls are slow. Lambda starts fast as it's not unpacking your container to a local disk on every start.


Guessing it’s reading the system color scheme, because on my phone it’s white text on black.

(on iOS with dark mode enabled system wide)


Oh god, I just disabled dark mode and yeah, it looks awful. Looks great in dark mode though.


Feels like AWS could just tell them they’re not launching Fable then. Anthropic needs them more than the opposite, no?

Nobody who is a big Bedrock customer will ditch for another cloud provider for the privilege of having anthropic hold on to their inputs.


Amazon’s AWS and core delivery business are fairly mature, and with consumer sentiment poor and non-AI tech contracting, having a growth vertical like Bedrock is good for shareholders. Without their own core tech, Amazon will be paying rent on AVs in a couple of years - or worse, they will lose all of the benefits or their logistics monopoly because an AV semi can afford to be inefficient


What is AV, autonomous vehicle or?


Autonomous vehicle, yes


Particularly not with OpenAI finally getting on Bedrock.


A company with different taste would redo that apple ad from the Power Mac era: “this model has been classified a munition”.

https://youtu.be/l2ThMmgQdpE


Different taste? The main advertising line for mythos was that it was too dangerous to let people use it?


I think that’s by AWS though. For Fable you need to flip an account wide flag that says “I want to share my prompts with the model vendor.”


The Fable announcement page on the Anthropic site says this data sharing will be applied regardless of the sharing setting of the company account.

https://www.anthropic.com/news/claude-fable-5-mythos-5#a-new...

---

  ## A new data retention policy

  Finally, we’re making a change to the way we handle business
  customer data for Fable 5, Mythos 5, and future models with
  similar or higher capability levels. We will require 30-day
  retention for all traffic on Mythos-class models, on both
  first- and third-party surfaces. [...]


No it says sharing is required. If you don't change the setting on your account then you simply can't access Fable, its not like the setting is ignored. I just tried this on my account and it blocks API requests to Fable.


Interesting. When I tried switching to it yesterday from Opus 4.8 ("/model" command) it didn't complain, but I didn't actually send anything to it when I saw the cost was like 2x Opus 4.8. ie switched back

I'll try to remember to actually try it tomorrow and see what happens.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: