Linus Torvalds (torvalds.delete@this.linux-foundation.org) on September 25, 2021 12:05 pm wrote:

> You sweet summer child.
>
> There's a reason people hated them. Different pointers for "far" accesses, and having to annotate
> and carry this all around. It wasn't just a portability nightmare (it's not like most PC programmers
> cared about portability anyway), it was just really inconvenient and bad in general.
>
> And it pollutes everything. Even if you write code that only ran on a 32-bit CPU, and you never
> needed to use segments just to escape the 64kB limits, the fact that you then had some code that
> wanted to interact across segments means that you have to have all kinds of wrapper functions.
>
> You can hide it from a lot of applications - and people did (only by having the applications
> not use segments!), but you ended up having it show up in system interfaces that had to deal
> with legacy cases or with the crazy apps that wanted to use segments after all.
>
> Trust me. You don't want segments. It really sounds like you've read the technical descriptions, not had
> to deal with the reality. It's just no fun dealing with multiple different pointer formats, and avoiding
> it entirely by dealing in all "fat pointers" is horrendously bad for your sanity and for performance.
>
> Linus


Ok maybe I'm wrong again. You got near far and huge pointers in 16 bit x86 because limits of 16 bit addressing. But with 32 bit x86 you got 32 bit pointers. You could calculate them with 16 bit segment 16 or 32 bit offsets but pointer is still only 32 bit and simply accessible with single 32 bit pointer.

If it ain't so Intel engineers didn't do their homework properly....