Hacker News Reader

Comment by wkat4242 | Hacker News Reader

Technically intel is keeping it alive. Just not feeding back code.

It's sad though. Minix was the first ever Unix I played with! Because Linux only worked on the 386 (it required 386 specific features like task switching) and I still had a 286 at the time. Minix worked fine on that.

But it was mainly good for academic purposes (as it's intended to). I never really ran it as an OS. It was hard to find software and it didn't come with a lot of programs, unlike linux distros which came with a huge collection as they still do today.

On a 286 it was really cool to have an actual multitasking OS though because DOS was still the main thing back then.

View on HN

Intel uses a specialized version of Minix 3 for its Intel Management Engine in every CPU it released since 2008, so technically, it is the most installed OS.

https://www.bleepingcomputer.com/news/hardware/intels-secret...

Not even close.

Even if Minix had been installed on every single management card on every computer Intel made from then to now, that number is utterly dwarfed by the number of systems with an installed Linux kernel. That's because in addition to its use as a server and desktop OS, the Linux kernel is the core of the Android distributions that almost every non apple smart phone uses today. Also set top boxes, tablets, watches, and even many smart TVs and Blu Ray players have a copy of Android.

The Linux kernel is a kernel, not an OS. Even if my set-top-box is running some flavor of Android, it looks nothing like my phone or anything else, thus I would classify it as a different OS -- even if the underlying code is based on Android.

And Minix 3 is an OS?

Yes, full OS with its own microkernel and NetBSD-forked userland.

What's the point of nitpicking userland if we're concerned with processor build-in management engines?

Minix3 was born as a full OS, not a management engine. What Intel really did with the code, nobody really knows.

Does Intel bundle all the userland tools?

Does it need to?

Is it an OS if there is no userland?

As long as there's init, or something to boot into, sure.

I'd be really curious why there are downvotes, mostly for the discussion.

Microsoft Xenix also supported the 286.

The Korn shell's source code was an ugly mess in an effort to fit the text segment in the 64k address space on this platform.

The POSIX shell removed many Korn shell features to reach clear and maintainable code with the same size limits.

I'm able to compile Debian dash to a bit over 80k on 32-bit Linux without much effort. I've heard that it's 4x faster and 10x smaller than bash.

I definitely notice a speed improvement with Dash. Most shell scripts are too small to notice a difference, but it made a big difference back before the switch to systemd, back when init was a bunch of clunky shell scripts.

Check your locale before benchmarking; setting it to "C" negates a lot of the dash performance advantage.

Dunno, the linked article looks like a conclusive performance advantage to me.

Bash's own manual page concludes that "it's too big and too slow" in the BUGS section.

https://www.baeldung.com/linux/dash-vs-bash-performance

Feel free to go and convince https://news.ycombinator.com/item?id=35987961, who isn't convinced by the actual measurements that people did. (-:

FWIW on My Machine(tm) bash goes from ~4 times slower to ~70% slower on the simple startup test just by changing the locale:

    $ time for i in $(seq 1 1000); do bash -c ":" ; done

    real 0m4.475s
    user 0m3.234s
    sys 0m1.287s

    $ time for i in $(seq 1 1000); do dash -c ":" ; done

    real 0m1.067s
    user 0m0.408s
    sys 0m0.704s

    $ (export LC_ALL=C; time for i in $(seq 1 1000); do dash -c ":" ; done)

    real 0m1.043s
    user 0m0.409s
    sys 0m0.679s

    $ (export LC_ALL=C; time for i in $(seq 1 1000); do bash -c ":" ; done)

    real 0m1.721s
    user 0m0.783s
    sys 0m0.986s

Why would I want to set my locale to “C”? My actual preferences are en_US, and it sounds to me like you’re asking me to misconfigure my shell.

Bash does more work for non C locales. Dash does not. You can configure bash without locale support when compiling it, or just set the locale to C to get a more apples-to-apples comparison.

Isn’t C the wrong locale, though? Why would I want to use something which is incorrect as the basis for comparison?

If you want the behavior that bash gives you with your locale, then dash scores "zero" on any benchmark, since dash does not implement that. If you don't want the behavior that bash gives you with your locale, then it's a correct comparison.

I learned C under Xenix. One machine and a pile of dumb terminals. I wrote a program to solve the travelling salesman problem via GA. Good times.

It was the introduction of paged memory management and a flat address space that allowed Unix like OSs to run on the 386.

Xenix was an officially licensed Unix for the 16-bit 8086.

https://en.m.wikipedia.org/wiki/Xenix

Unix didn't require paged address space, and several were running using 286 segmentation only (some even without that, but that was pretty much without any protections, while 286 gave equivalent memory management to late PDP-11)

> Technically intel is keeping it alive. Just not feeding back code.

Then what Intel is keeping alive is a private fork, not the thing that's available online.

> it required 386 specific features like task switching

i thought this was a kernel/OS level concept, could you expand more?

I'm not qualified to explain but the first answer to this question captures it well I think:

https://retrocomputing.stackexchange.com/questions/26516/wha...

x86 has hardware support for context switching, which is basically saving all the registers and jumping to a new address.

https://en.wikipedia.org/wiki/Task_state_segment

does x86_64 use this?

x86-64 still requires Task State Segments (TSS), but it doesn't support using them for their original primary purpose of task switching; rather, they are needed for changing stacks when switching between user and kernel mode.

In the original 386 design, the OS kernel would create a separate TSS for each OS process. In x86-64's vestigial use of the concept, there is a single TSS for each CPU, and every process running on that CPU shares the same TSS.

It is a kernel/OS level concept (though it was also used in games.)

Historically, task-switching had hardware support to some degree even in 8-bit microprocessors such as the Z80, M6809, and 6502 and in 16-bit microprocessors prior to the 386, using interrupts to push all the registers onto a stack, and setting the program counter to start executing instructions at a new address.

The vital innovation introduced with the 386 was to add memory protection, so that the different tasks could not corrupt each other's allocated memory. Hitherto, multitasking was too unstable for serious commercial use.

i agree about task switching; there's nothing 386-specific about longjmp, call/cc, or interrupts, and linux doesn't use the 386 tss (though it did at first: https://retrocomputing.stackexchange.com/questions/26516/wha...)

however, hardware memory protection was an innovation of the early 01960s; it featured prominently in designs like the burroughs 5000 (01961), the ferranti atlas (01962), the cdc 6600 (01964), and the ibm 360 model 67 (01965)

but the 80386 didn't ship until 01985, at which point hardware memory protection had been in off-the-shelf commercial computers for 24 years, very much in serious commercial use; in particular, most of the internet ran on pdp-10s, pdp-11s, vax-11s, and sun workstations, which all had memory protection. it had become universal in mainframes and almost so in minis during the 01970s, and even some micros like the lsi-11 and suns had it

the 286 also had memory protection. what it lacked (like the pdp-11, including the lsi-11) was 32-bit registers. the 386's 32-bit register set meant you didn't have to use segmentation, which was a huge problem for 286 protected mode, and linux mostly doesn't

The original Linux kernel used the task switching primitives included in the 80386 machine language. The tasks in the OS were directly mapped to 80386 tasks and task table entries, so the kernel was heavily tied to the 386 architecture.

Linus himself once posted to USENet that it was unlikely Linux would ever run on anything but the 386 and its successors. Happily, he did the work to make himself wrong.

Reply on news.ycombinator.com