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

... and they were right.

v6 adoption is often an all or nothing, because if you run both stacks, you have to ensure they are consistent. While you can reasonably do it on your home LAN, doing it across an entire infrastructure is the worst.

Now you have to make sure all your subnets, routing, VLANs, firewall rules, etc work exactly the same in two protocols that have very little in common.

It is the equivalent of shipping two programs in different languages and maintaining exact feature parity between both at all times.


I genuinely don’t understand this. The concepts are nearly identical between the two.

Hum no, to me they are orthogonal.

v4 was built around the idea of multiple free standing networks linked by gateways. v6 was built around the idea of a universal network.

I dont care about what your LAN adress space look like when I'm in my LAN, because we are not in the same v4 network. I am sovereign in my network.

With v6, everyone is effectively in the same network. I have to ask my ISP for a prefix that he will rent me for money even for my LAN. If I want some freedom from said ISP prefix, I am mercifully granted the honor of managing ULA/NAT66 (granted I paid for a fancy router).

Also if I want any kind of privacy, I will have to manage privacy extensions and the great invention of having to use automatically generated, dynamically routed, essentially multiple random IPs per interface. How lucky am I to use such a great new technology.

Seriously v6 was created by nerds in a lab with no practical experience of what people wanted.


> v4 was built around the idea of multiple free standing networks linked by gateways

It was absolutely not. This is why early companies like Apple and Ford got massive IP allocations - each computer was expected to have a unique IP address.

NAT didn't exist until 14 years after IPv4 was created, in response to the shortage of IPv4 addresses, and in the RFC it is described as a "short-term solution", very clearly stated that his not how the internet is designed to work and it should only be used as a stopgap until we get longer addresses.


> v4 was built around the idea of multiple free standing networks linked by gateways.

I don't think this is what v4 was built around, but rather what v4 turned into.

CIDR wasn't introduced until 1993. NAT in 1994. Both to handle depleting IP addresses.


If you want static addresses in LAN, you can use link local addresses for that.

v4 and v6 were build around the exact same use cases.

> With v6, everyone is effectively in the same network.

Just like IPv4.

> I have to ask my ISP for a prefix that he will rent me for money even for my LAN.

Just like IPv4, if you need a static address.

> If I want some freedom from said ISP prefix, I am mercifully granted the honor of managing ULA/NAT66 (granted I paid for a fancy router).

Compared with IPv4, where if you want some freedom from said ISP subnet, you are mercifully granted the honor of managing RFC-1918 addresses/NAT (granted you paid for a router that doesn't screw it up).

> Also if I want any kind of privacy, I will have to manage privacy extensions

...which are enabled by default nearly universally

> and the great invention of having to use automatically generated, dynamically routed, essentially multiple random IPs per interface.

Make up your mind. Are rotating, privacy-preserving addresses good or bad? The way it works in real life, not in the strawman version, is that you (automatically!) use the random addresses for outgoing connections and the fixed addresses for incoming.


This is exactly why I decided not to enable IPv6 on my colo. When money is involved, the benefits of IPv6 simply do not outweigh the risk, in my estimation. If my side gig eventually pays enough to pay a contractor to handle networking then sure, that'll be one of the first tasks. But when it's just me managing the entire stack, my number one priority is security, and for now that means keeping things simple as possible.

I agree with you. While I can see some benefits to v6 on the internet, I find v4 to be miles easier and cleaner to work with in a LAN setup. Unfortunately though v6 oversteps on LAN features and makes bridging v4 and v6 way uglier than it should.

> v6 oversteps on LAN features and makes bridging v4 and v6 way uglier than it should

How so?


Every year I just wish someone will come up with IPv4-with-more-bytes and we can switch to it before IPv6 gets another percent usage share.

IPv4-with-more-bytes is not backwards compatible with IPv4. So you'd have to replace/upgrade every existing network stack, both hardware and software. To get, basically, the same effect as moving to IPv6.

> IPv4-with-more-bytes is not backwards compatible with IPv4

Neither is IPv6

> To get, basically, the same effect as moving to IPv6

The only thing that IPv6 solves which is of interest to 99.99% of the users is having more adressable space. The rest of IPv6 features are either things that nobody asked for, or things which are genuinely worst compared to IPv4.

I consider the mere fact of enabling IPv6 an unacceptable security risk, as I would now have to make sure my IPv4 and IPv6 firewall stack are perfectly mirroring each other. That would be trivial with IPv4-with-more-bytes, it's a nightmare with IPv6.


Do NAT64 and just worry about IPv6 if not wanting dual stack.

All of IPv6 features are just direct effects of having more space and not. Basically IPv6 "features" is just getting rid of IPv4 workarounds.


> I would now have to make sure my IPv4 and IPv6 firewall stack are perfectly mirroring each other.

You'd still have that in your IPv4-with-more-bytes, as you'll still probably end up running dual-stack to address those old-v4-only sites. Or you'd do the same with v6 and run a tunnel to translate those v4-only addresses to your v4-with-more-bytes. So you're in the same situation either way.


There were backwards-compatible protocols proposed, such as EIP, but the committee chose a backwards-incompatible protocol for v6. Their assumption was that v4 would run out of space in a single-digit number of years and everyone would be forced to migrate. The past 30 years have shown that not to be the case.

https://datatracker.ietf.org/doc/html/rfc1385


They went with SIPP, which was one of the backwards-compatible options. It should be kind of obvious from the vast number of backwards compatibility methods available in v6 that v6 is actually backwards compatible... but for some reason a lot of people either refuse to believe this or have double standards around what counts as compatibility.

That's what IPv6 is. People get so fixated on being annoyed at IPv6 they forget to actually think. Whatever you invent won't be any better than IPv6. Many people have tried.

If you change the address format even the tiniest amount, if you add one single additional bit, your new protocol is already completely incompatible with all existing IPv4 software and equipment.


IPv6 is IPv4 with 12 more bytes, right?

> You can be catholic and not like the pope

You can be christian and not like the pope.

But to catholics, the pope is the terrestrial embodiment of the holy spirit, and as such considered infaillible. Not recognizing the pope as such is incompatible with catholicism.

Papacy is a core part of catholicism, it's not a "pick and choose buffet".


> and as such considered infaillible

This is a common misconception. The pope is only considered as speaking infallibly by the Catholic Church when speaking ex cathedra on matter of faith and morals. This is very rare and is considered to only have happened twice in history.


I didn't know that, thanks for pointing it out, very interesting!

> id est provide guarantees to the customer that the firmware of the device they receive has not been tampered with

The firmware of the device being a binary blob for the most part... Not like I trust it to begin with.

Whereas my open source Linux distribution requires me to disables SecureBoot.

What a world.


You can set up custom SecureBoot keys on your firmware and configure Linux to boot using it.

There's also plenty of folks combining this with TPM and boot measurements.

The ugly part of SecureBoot is that all hardware comes with MS's keys, and lots of software assume that you'll want MS in charge of your hardware security, but SecureBoot _can_ be used to serve the user.

Obviously there's hardware that's the exception to this, and I totally share your dislike of it.


> You can set up custom SecureBoot keys on your firmware and configure Linux to boot using it.

Right, but as engineers, we should resist the temptation to equate _possible_ with _practical_.

The mere fact that even the most business oriented Linux distributions have issues playing along SecureBoot is worrying. Essentially, SB has become a Windows only technology.

The promise of what SB could be useful for is even muddier. I would argue that the chances of being victim of firmware tampering are pretty thin compared to other attack vectors, yet somehow we end up all having SB and its most significant achievement is training people that disabling it is totally fine.


+1

An unsigned hash is plenty guard to against tampering. The supply chain and any secret sauce that went into that firmware is just trust. Trust that the blob is well intentioned, trust that you downloaded from the right URL, checked the right SHA, trust that the organization running the URL is sanctioned to do so by Microsoft...

Once all of that trust for every piece of software is concentrated in one organization, Microsoft, Apple or Google, is has become totally meaningless.


Sorry but I just dont buy this argument.

All Americans I have met had the same discourse: "I am ashamed, it's a pity Trump is in power, it's hard for us too, we don't support him", etc. I am rather sick of it.

A democracy is not an "us versus them" system, it's a closed loop. One cannot hide behind "these imbeciles votted for him and I am held hostage by their ignorance". Pros and antis Trump are equally responsible for his election.

Maybe if the US was not such an individualistic country, with growing educational and wealth inequality, half the population wouldn't have voted for exploding the status quo.

Politicians are no more corrupt than the population not impeaching them.

The US is basically in a streak of blatantly stealing resources of other countries, mafia style, and we are long past the point where the population can argue "we didnt know, we thought they had weapons of mass destruction, I am so against it".


> This is not gain at all. At least in theory: You own some tons of gold at the start of the process, you have the same tons of gold at the end of the process.

I see a lot of comments like this but I just can't get my head around what you are trying to prove (or disprove).

Every definition of gain (or loss for that matter) implies that the same amount of _something_ is now worth more (or less) than when you bought it.

Following you logic, if I buy a share of MSFT at $10, sell it for $100, there is no gain because I still have 1 share of MSFT?


but you sold it...

(I know share rehypothication exists, but it shouldn't)


Even if you rebuy it at $100 it's the same, your profit didn't change, you just exchanged cash for an asset.

Before you sold it you had unrealized gains, after you sold it you had realized gains, after you bought it again you have the same gains but materialized as shares.


I don't get your point. Gold price increased, the gains were unrealized, now they realized when they rolled to a new position. The only nitpick would be that they did not mention the benchmark rate, so it's hard to guess the absolute gain.

What is poorly written or misleading here...?

That just looks like a normal capital gain to me.


The article even says exactly that:

"Due to rising gold prices, the move helped the bank to generate a capital gain of 13 billion euros ($15 billion), bringing it to a net profit of 8.1 billion euros for the 2025 financial year after a net loss of 7.7 billion euros in 2024."

I would have thought the audience here would understand something as straight forward as a capital gain.



Capital gain and losses are when you need to pay taxes. If you sold 100K of SPY that you bought for 10K actually, and bought it back (It is a gain so there is no wash sale) immediately, you need to pay taxes for $90K. This is just an exchange based on the comments I am reading.

No, capital gains are simply the amount you earn when selling capital for profit. They may be taxed, or may not be taxed, depending on the country or location they occurred in.

What is the benefit of realizing the gains for France? They had gold, they still have gold. They don't pay tax on their gold or gains.

I don't think they cared about realizing the gains. They just wanted to roll to a new position on higher standard ingots. It just so happen that it meant selling/buying, which realizes the gains.

I think the GP was saying that there was no gain. France has the same amount of gold they did last week. The whole article is like saying "holy shit, france has the exact same amount of wealth they did last week!"

Did you read the article at all? Or just the title? The article is about bringing gold back to France by selling US bars and buying new bars in Europe. The alternative would be melting the bars down and recasting them to the new standard.

The capital gain is just a by-product, standard financial stuff, but apparently broke HN readers brains.


I did read the article, thanks for asking.

Sounds like you agree with me, France has the same amount of wealth in gold that they had last week.


I don't care about that. That's not what the article is about.

>> The article is about bringing gold back to France by selling US bars and buying new bars in Europe. The alternative would be melting the bars down and recasting them to the new standard.

> Sounds like you agree with me, France has the same amount of wealth in gold that they had last week.

What did I miss?


I don't think there is any moat here, most European countries have these kind of "deprecated" laws, that are not enforced and just stay there because it's too much of a hassle to remove. In France, I think there are still laws forbidding women to wear jeans, and requiring permission of the husband to work. Still in the text of law, but obviously non enforceable.

Such laws are unenforceable until someone comes along who decides that enforcement would be useful to them.

This is not a deprecated law but rather was changed towards its current form on January 1st of this year

The law exists since the 1950s. It was just suspended from 2011 to 2026. The new law just reactivated the old law.

> forbidding women to wear jeans

This police ordinance from 1800 was abolished in 2013

> requiring permission of the husband to work

Repealed in 1965


US has just as many if not even more. Every state has their own collection of weird laws, like donkeys are not allowed to sleep in bathtubs or dandelions are illegal to grow over a certain height.

I am not familiar with the tech stack they use, but from an outsider point of view, I was sort of expecting some kind of fuse solution. Could someone explain why they went through a fake shell? There has to be a reason.


100% agree a FUSE mount would be the way to go given more time and resources.

Putting Chroma behind a FUSE adapter was my initial thought when I was implementing this but it was way too slow.

I think we would also need to optimize grep even if we had a FUSE mount.

This was easier in our case, because we didn’t need a 100% POSIX compatibility for our read only docs use case because the agent used only a subset of bash commands anyway to traverse the docs. This also avoids any extra infra overhead or maintenance of EC2 nodes/sandboxes that the agent would have to use.


Yah my Claude Code agents run a ton of Python and bash scripts. You're probably missing out on a lot of tool use cases without full tool use through POSIX compatibility.


agreed. hopefully we can get there soon

Did you guys look at Firecracker-based options such as E2B and Fly.io? We’ve had positive early results on latency, but yeah … too early to tell where we end up on cost.

Yea we did and actually use Daytona for another product, but it would have been too slow here.

Makes sense, thanks for clarifying!


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

Search: