[wewewedxfgdf]

I seem to recall at the time that flat memory was self evidently a better idea. It's not like people were sitting around going "gee I can't think of any better way to do memory addressing that this" until some genius suggests "how about flat?!?!?" Everyone knew flat was best but were stuck with 8086 crap.

[phkahler]

I was drooling over the MC68000. I had a pre-release reference manual from 1979 and it was the most awesome chip around. Atari and Commodore and Apple used it after their 6502 systems. Arcade games used it after their 6502 and 6809 days. The only reason x86 became popular was because IBM put it in the PC - not for any technical reasons.

[trollbridge]

A 68k was roughly double the cost of an 8086, plus the additional cost for the rest of the supporting chips.

The PC was intended to be cheap and was competing with 8 bit machines. Being 16/20 bit made it already high end.

If you wanted 24 or 32 bit, IBM had many other machines to sell you. Or you could just buy a VAX.

[trollbridge]

Flat is not necessarily a better idea. In 1978, a 32 bit CPU would be stupidly expensive. The use case for > 64k was to simply have code and data split apart, and also have some MMIO, so basically 192k-256k of addressing needed.

Segmentation meant programs could remain essentially 16 bit with all the benefits to that like smaller code size.

[Someone]

Not entirely self-evidently. Position independent code was slower at the time and avoiding having to patching function addresses at load time is a net win.

More importantly, there’s backwards compatibility. By the time the 8086 came out, people had spent serious money on getting binary-only software (WordStar cost hundreds of dollars, for example). “Buy this computer, and you can keep running the software you paid for, but faster” was a good selling point.

[rickas]

I wonder why couldn't Intel simply introduce single 'offset' register for apps ported from 8080, and make all other registers 20-24bit. Why bother with 4 different registers and all that segmentation nightmare?

[trollbridge]

Lots of benefits to a word size a power of 2.

Very few benefits to a clunky 24 or 20 bit word size; now it costs more and is a bizarre boutique architecture in a world where it needs to compete with 8 bit Z80s and 6502s.

[ThrowawayR2]

Flat memory was a better idea but it wasn't a cheaper idea, and cheaper beats good. A casual Googling shows a price of $2,880 for a IBM PC in ~1982 dollars versus $8,900 for a Sun Microsystems Sun-1 with a MC68000.

[amiga386]

That was just Sun's market segment.

Also from a casual Google, an IBM PC launched in 1985 (picking the XT 5160-078 as an example) was around $4,995 at launch. Compare that to two 68000-based computers also launched in 1985: the Amiga 1000 launched at $1,295 and the Atari 520ST launched at $600.

These computer system prices - Sun, IBM, Commodore, Atari - came from the market segments the manufacturers aimed to sell to, rather than a cost saving enabled by cumbersome memory models.

The cumbersome memory model is just a historical accident; the 8086 designers wanted 8080 backwards compatibility so they could sell to former 8080 users, IBM did not require this. IBM would've picked the 68000 had it been "production ready" at the time, they did not reject flat memory on cost grounds!

[PaulHoule]

Personally I enjoyed writing assembly with segments. You can have 64k of code, 64k of data and 64k of stack without trying. So long as no individual data structure is larger than 64k there is no essential difficulty working with 16 bit pointers.

When I think back I think it would be fun to have a hierarchical structure where composite data structures (think an array or hash map) are referred to with a pointer that goes into the segment register and you index inside a data structure with a regular pointer.

[trollbridge]

Lots of 8086 code was written that way. You’d use the segment register on paragraph alignment and basically take advantage of the << 4 + logic.

This code was a nightmare to port to protected mode 80286 so it went away by the Windows 3.1 era.

[KellyCriterion]

-- Everyone knew flat was best but were stuck with 8086 crap.--

This! Thats one of the most interesting things to me: Actually very often in the IT-world, the worst competitor won the race while better solutions were known and available: Microsoft, Intel etc.

Esp. that MS won for decades while making mainly a very bad OS, though they have some good enterprise products.

How would the world look, if Unix/BSD would have won this race?

[JdeBP]

There was a Microsoft operating system for protected mode 80286 in 1983. It was Xenix 286; it was basically 7th Edition Unix without the branding; and it was touted as the multiuser operating system that MS-DOS would be the gateway to. How would the world look if Microsoft had won the race? (-:

[trollbridge]

A PC with DOS was cheaper than a PC with Xenix, let alone a typical Unix machine. Also much easier to learn to use.

Macs also existed but were expensive. The PC with DOS was both powerful and cheap.

[Ekaros]

I really wonder if Unix is best we can do. Or is it also worst? So in the end two of the worst options won. It did make sense back in time. But could it have been replaced with something better later?

[bux93]

Linux is only used as a kernel temporarily until GNU is finished.

[simiones]

You mean GNU Hurd, I guess.

[JdeBP]

The operating system was going to be called GNU.

Don't open this can of worms. (-: There were endless discussions of this in the 1990s. Years's worth.

Scroll down to the 'What Is the Hurd?' section of this announcement post from 1996 and pay particular attention to its first and last sentences. That's the allusion here.

* https://groups.google.com/g/gnu.announce/c/d0N2mLo5dxk/m/bDq...

[amiga386]

There have been some very nice OSes in the past (e.g. AmigaOS, BeOS, QNX, Plan 9) that all failed to the Wintel juggernaut. MacOS only just made it out alive.

I wouldn't say Unix itself is the best. It suffered a war between competing implementations pushing their own proprietary components. POSIX is the compromise.

But, ultimately, what is good about it today is not so much "Unix" (the proprietary OS from Bell Labs and its heritage), but specifically Linux and the BSDs. Why? Because they are actually open. They are freedom incarnate. You can add anything you like to them, today, without asking any permission. Not just their kernels, but their userlands too (Linux obviously varies by distro here). There's even a chance you can get your changes adopted upstream (unless it's GNOME), much more than you'd ever get from a proprietary company's OS.

So, while there's always room for improvement on the technical aspects of the OS, the social and political aspects of Linux and the BSDs make them the best we can achieve as a society.

[wewewedxfgdf]

>> two of the worst options won

What do you mean, which are the two? Sure, Windows is crappy by Linus and MacOS? They are both awesome.

[simiones]

There are many crappy design decisions in Unix, Posix, Linux, MacOS, that have been known and worked around for decades (see the Unix Hater's Handbook). One example would be async IO, which has been famously bad in Unix, and Linux alone has tried 2 different generations of solutions - with the newer one, io_uring, being suspiciously similar to Windows' decades old IOCP. Fork/exec is infamous as a needlessly complex process creation API, requiring huge effort in the kernel just to handle the most common case of simply launching a new process. The traditional Unix security paradigm of simple user based file permissions is extremely weak and has required numerous solutions on top to handle realistic security scenarios - e.g. to protect a user's files from being tampered in unexpected ways by a process launched by that user (SELinux, jails, namespaces, etc).

I agree that Windows is crappy, but that doesn't mean that Linux and MacOS aren't also crappy in their own ways (not to mention iOS, Android).

[KellyCriterion]

Especially the enshittification over the decades: All the bloat (XBog Game Icon on Win Server - really?), their update politics tangled with higher hardware specs for running the same stuff slower than before.

I do not understand how can one crash their own product/baby that way - and no, this must be Hanlors Razors: They are doing it with (sophisticated) intend, not by accident (or coincidence)

[PunchyHamster]

"Better" is not one dimensional scale

Adding more features to OS is for some use cases a benefit, for other it's a barrier. For one it might be less work to get what you want ,for other it might be more code between you and hardware that just slows it down

Unix-like simplicity is exactly that, for some use cases directness is a benefit, for others it means extra work to do on top to get what you want.

If you just want a house, getting a raw foundation to work with is a lot to build on top, you have to bring the rest of the walls up yourself.

But if you want exactly the house you want, getting entirely different house to start with and changing it is far more work than starting from simple foundation and building up.

Overall unix "here is relatively simple operating system that doesn't force you but needs some things to be built on top to hit your use case" probably IS the best abstraction, despise not being "best" at really anything. There is reason we build houses from concrete and wood, and not carbon fiber and titanium alloys

[wewewedxfgdf]

Being technically best has long been known to not be correlated to market success in the way that makes logical sense to technical people who feel confused about this.

[alerighi]

Except than later we returned to a sort-of segmented memory. That is of course paging, our programs allocates pages of memory that are a fixed size (4096 bytes) and are arranged in memory or in swap space how the OS decides.

We just have the illusion of a "flat" memory model, but it's not really flat, the CPU and the operating system does an important job in translating our flat memory model in something that is not flat at all. All that address translation work could have been avoided if we accepted to not have a flat memory model and be aware that our memory is divided in pages.

Basically we are doing in hardware the job of managing a non flat memory space that the programmer, or well, the compiler (or these days you would say the AI agent) could probably to better because it knows how to allocate things to avoid being them on page boundaries, and all of this to give the illusion to the programmer that it's working with a flat memory (except when it does something wrong and gets a segmentation fault, that, as the name suggests, is an hint that at the end the memory is not really flat).

[bluGill]

In turn though, the thinking needed to handle non-flat memory is a complexity that most programmers cannot handle - and even those who could probably should spend their brain power on the complex parts of their program not managing memory. Best to leave that hard part to a few experts instead of make everyone understand it.

The above is very similar to the argument that you should use a garbage collected langauge.

[trollbridge]

Anyone writing an algorithm that needs to be high speed has to start thinking about caches and so forth. So it’s not exactly obsolete.

Back in 1980 most programs were being written in interpreted languages that did all the hard work of memory for you - just like today.

[wang_li]

Paging is not part of the CPU architecture. On CPUs of the time the MMU that brought paging to the party often was a completely separate peripheral that the CPU interacted with to gate access to RAM. By contrast segments are an integral part of the CPU instruction set and your code either has to limit itself to 64KB or your application had to be aware of and include logic to manage segments.

As an aside, the memory model is flat, it's just not physically linear when implementing virtual memory addressing.