(Short version: IPv6-only networks can provide a gateway for IPv4-only clients and advertise it via reverse DNS.)

SixGate has an interesting contrast with this RFC. RFC8950 removes IPv4 from the network core while preserving IPv4 reachability, whereas SixGate removes IPv4 from the service side while preserving reachability for IPv4-only clients.

In both cases, IPv4 survives as a compatibility layer rather than a fundamental requirement. The difference is that RFC8950 is aimed at network operators, while SixGate is aimed at the last remaining IPv4-only users.

In both cases, the goal is the same. Turn IPv4 from a requirement into an optional compatibility feature.

Comments URL: https://news.ycombinator.com/item?id=50117283

Points: 2

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=49991704

Points: 2

# Comments: 0

  Location: Daventry, UK
  Remote: Preferred.
  Willing to relocate: Yes
  Technologies: C#, ,NET 10, Python, SQL, Distributed Systems
  CV: See https://cv.billpg.com/ and contact form.

You may know from my popular HN submissions...

  8086 Segmented Memory was a good idea. https://news.ycombinator.com/item?id=48619125
  The Road Not Taken: A World Where IPv4 Evolved. https://news.ycombinator.com/item?id=47352236
  Data-Mining Wikipedia for Fun and Profit. https://news.ycombinator.com/item?id=28234122

Comments URL: https://news.ycombinator.com/item?id=49895010

Points: 2

# Comments: 0

I set my domain up to use "www" as a CNAME to a static-file web service and the apex domain as a redirector to that "www" site. Done it before, works great!

But then it didn't work so well. The "www" site was working fine exactly as I wanted, but that apex domain redirect wasn't working. I kept getting a connection-refused error. Huh?

Worked through the possibilities, I finally found the problem. Namecheap's redirector service was only running on port 80. For my dot-com, that was no problem, but my dot-dev domain, like all dot-dev, are flagged as TLS only. My browser was refusing to connect to port 80!

I'm now looking at possibilities for an alternate redirect-to-www service that works over TLS.

Any suggestions for my next move please?

Comments URL: https://news.ycombinator.com/item?id=49068668

Points: 1

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=48968786

Points: 1

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=48956304

Points: 2

# Comments: 0

I've reviewed what I originally wrote and I prefer the text I published. Sure, I could review it all myself (indeed I used to) but that takes time and it was becoming a barrier to actually publishing stuff. Maybe I'd have got around to finishing it in a few months.

I don't use AI to write for me. I hate people who do that.

I get why hey didn't. Someone might want to run two processes each with its own segment, but the whole machine might only have 64k in total.

I did use an AI for spell-checking, punctuation, generally making it flow, but its all my text.

You think a machine is going to come up with "near pointers, far pointers, wherever-you-are pointers"?

(And I completely agree.)

But what should Intel have done? They needed a CPU that can run 8080 code but with more memory. Also it's the year ~1980 and we're limited to the technology of the age.

A system with 64k sized windows seems unavoidable.

If you extend the size of the address registers, 8080 code will only run in the first 64k, or require some kind of current window register.

An 8080 mode might have worked but that would have been expensive.

Comments URL: https://news.ycombinator.com/item?id=48619125

Points: 71

# Comments: 148

Comments URL: https://news.ycombinator.com/item?id=48334522

Points: 5

# Comments: 0

The key point is that POSIX does not actually define a real, physical epoch, and it explicitly avoids doing so. POSIX says every day is exactly 86400 seconds, leap seconds are ignored, the relationship between POSIX time and UTC is unspecified. In other words, POSIX defines how the "time()" API behaves, not what the underlying timeline is. It’s an OS level contract, not a timekeeping standard.

The problem I’m addressing is that POSIX retroactively assumes a form of UTC that didn’t exist in 1970–1971 and it provides no authoritative mapping between POSIX time and actual UTC. That’s why you can’t use POSIX as a normative reference for "seconds since 1970". It’s not a definition of time, it’s a behavioural model for system clocks.

This document is trying to define the actual timeline that people implicitly assume when they say "Unix timestamp", in a way that’s historically honest and citable. When I was looking at a number of RFCs that use these timestamps they didn't cite this reference, but went with the wooly "Number of seconds since 1970".

Comments URL: https://news.ycombinator.com/item?id=48325409

Points: 2

# Comments: 2