Minix development has been abandoned? | Hacker News Reader

Minix development has been abandoned?

git.minix3.org

139 pointsBondi_Blue109 comments

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.

> 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.

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)

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.

> 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.

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.

The primary author and evangelist of Minix is 79 years old, so maybe slowing down a bit?

https://en.m.wikipedia.org/wiki/Andrew_S._Tanenbaum

He is one of the folks behind https://www.electoral-vote.com/ which I think must take up a lot of time.

The reason is probably that enthusiasm died out when Intel used it for their covert management engine in every x86 cpu they sell. Essentially bavkdooring all computers in the world...

Should've used GPL...

Then no one would be using it at all and Intel would pick the next OS project to use.

That is what enterprises said about Linux.

But the network effects are too strong and the GPL requiring the source code for drivers to be released increases the network effects. Unlike permissive licenses.

Busybox is still overwhelmed suing companies repeatably ignoring the GPL.

That's a different usecase. Linux is good for general computing. Intel specifically wanted something they could close down as much as possible.

So if Minix was under GPL, Intel would probably have gone with NetBSD or FreeBSD. Or possibly something different altogether.

L4 is popular among similar corporate trojan malware deployed in secret against customers. Most of its use is by qualcom. Apparently apple are doing something similar.

This large scale deployment is apparently billed by some as the payoff for the promise of microkernels w.r.t. "security" so I guess they just don't mean yours?

I presume the point of the OP comment is that Intel ME is bad malware, and that its creation could have been prevented by making Minix GPL. Intel could have quite easily used just about any project, and there are plenty that are permissively licensed, or they could have just created one from scratch if needed.

The Software Freedom Conservancy is filing the lawsuits, IIRC.

Android's toybox emerged when Rob Landley, the main busybox developer, left the busybox project because of the lawsuits.

Toybox uses a BSD license.

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

Um wat

Probably refers to [1]

1 - https://www.tomshardware.com/news/google-removing-minix-mana...

Yup. If I'm not mistaken it also made a big push for libreboot and other projects to circumvent or disable as much of it as possible.

Purism laptops being a commercial venture to have modern hardware.

Then there's vendors repurposing older Thinkpads packaged with libreboot or coreboot.

The Intel CPU/microOS inside of a CPU while cool and even cooler that Minix was used for it, was unfortunately not very transparent for security/paranoid conscious persons.

This site breaks the back button on mobile. It inserts a page to the stack, and it seems under certain conditions that page breaks the link back to this thread. It happened to me after reading the entire article, but not when I tried without reading the article.

Oof. It moves to a "more stories to see before you go" panel. Lose a lot of respect for Tom's Hardware for that.

Hard to believe.

Not hard to believe for me: https://itsfoss.com/fact-intel-minix-case/

Hard for me to believe that that's what killed the enthusiasm.

Note added later: Some people have pointed out online that if MINIX had a GPL license, Intel might not have used it since then it would have had to publish the modifications to the code. Maybe yes, maybe no, but the modifications were no doubt technical issues involving which mode processes run in, etc. My understanding, however, is that the small size and modular microkernel structure were the primary attractions. Many people (including me) don't like the idea of an all-powerful management engine in there at all (since it is a possible security hole and a dangerous idea in the first place), but that is Intel's business decision and a separate issue from the code it runs. A company as big as Intel could obviously write its own OS if it had to. My point is that big companies with lots of resources and expertise sometimes use microkernels, especially in embedded systems. The L4 microkernel has been running inside smartphone chips for years. I certainly hope Intel did thorough security hardening and testing before deploying the chip, since apparently an older version of MINIX was used. Older versions were primarily for education and newer ones were for high availability. Military-grade security was never a goal.

Second note added later: The online discussion got completely sidetracked from my original points as noted above. For the record, I would like to state that when Intel contacted me, they didn't say what they were working on. Companies rarely talk about future products without NDAs. I figured it was a new Ethernet chip or graphics chip or something like that. If I had suspected they might be building a spy engine, I certainly wouldn't have cooperated, even though all they wanted was reducing the memory footprint (= chip area for them). I think creating George Orwell's 1984 is an extremely bad idea, even if Orwell was off by about 30 years. People should have complete control over their own computers, not Intel and not the government. In the U.S. the Fourth Amendment makes it very clear that the government is forbidden from searching anyone's property without a search warrant. Many other countries have privacy laws that are in the same spirit. Putting a possible spy in every computer is a terrible development.

Source: https://www.cs.vu.nl/~ast/intel/

I always saw Minix3 was as a companion to the "Operating Systems: Design and Implementation 3/e by Andrew S" book which was in 2006. Probably you were only ever going to run it in a virtual machine. More of an "educational" kernel.

Not gonna go hunt for the link right now, but I think Minix 3 was intended to be more industrially applicable than it's predecessors: there's a talk somewhere where Tanenbaum talked about the need for a more fault tolerant kernel in all sorts of applications, and I think he got a grant from some European institution for that purpose.

> More of an "educational" kernel.

If you are writing this on an intel CPU, you are likely running minix3 right now.

It's not not educational, but it's not the primary goal compared to earlier versions.

Not necessarily. You can turn off vPro and don't use Intel based network chips, so the management engine is disabled on the hardware level.

Hence, "Likely". Especially so if you are of the opinion that it's only educational.

Can’t software be done? No known bugs, all features in a proposed scope written. Done and done.

No, software can't be done, because the hardware platform it runs on continues to change.

Perpetual growth is a myth, even in software.

Things like Docker demonstrate all that matters is encapsulation by those interested in keeping these projects live.

sure, but minix is running directly in the cpu of every intel processor for the last decade+.

So it surely doesn't apply here.

Perpetual growth, nothing. CPUs and graphics hardware changes, so the OS has to change.

One exciting thing about Moore’s law being finished would be that the hardware stops changing :)

I think you misunderstand Moore's law.

Either one of those would be a notable accomplishment on its own for a medium size codebase. I don’t feel that there would be reason to believe that both of those would be true here.

https://github.com/Stichting-MINIX-Research-Foundation/minix...

Which one of those is going against OP comment?

All of them

That's pretty poor analysis. The existence of an issues list on GitHub doesn't automatically mean that the issues are valid, and the 2nd random one that I picked was someone complaining that fetching a package with FTP didn't work when the network was down. In 2021.

* https://github.com/Stichting-MINIX-Research-Foundation/minix...

Then this one turned out to be a chat request.

* https://github.com/Stichting-MINIX-Research-Foundation/minix...

And this one the author actually asked to be closed, because the problem is fixed. It's still open.

* https://github.com/Stichting-MINIX-Research-Foundation/minix...

If those are any indication, this is an issues list where no-one gets rid of the rubbish, and it thus its existence alone tells one nothing at all, as one probably is going to have to weed a whole bunch of very clearly non-bugs out to determine if there's anything left.

That's all well and good, but Minix is not "done", no one involved with Minix is billing it that way, and no one who knows anything about the current state of things would let anyone who tried to say that get away with it.

tambourine_man posed a valid hypothetical, but that's all it is: hypothetical.

"yes" might be one example.

true

Software is "done" when it is retried.

> No known bugs

This is the part that I doubt will ever be achieved by any system or structure of moderate complexity or above. Everything that exists in the real world has problems with it. If it's a building or a machine, then it's done once it's built unless there are major safety issues. The cost of fixing non-critical issues in a physical product is too high to justify.

The problem with software is that the marginal cost of "one more fix" is close to zero, which means that declaring something "done" means drawing a somewhat arbitrary line in the sand. Why is this new complaint less important than the similarly-scoped one that you fixed last week? There's not really a good answer to this question, so there's never a good day to say that you're not fixing anything more.

> If it's a building or a machine, then it's done once it's built…

Modern construction requires a significant amount of maintenance. The Romans on the other hand, they knew how to build a building!

That's fair, but we'd still consider the building to be "done" in the sense that OP means—the construction crew can go home.

When I refer to problems that go unaddressed I'm thinking of problems like "this bathroom is too small", not "the roof needs replacing".

> Modern construction requires a significant amount of maintenance.

I was raised with the rule of thumb that you should budget 1% of the purchase price of a house for maintenance; while that's roughly true for my century-old villa that I purchased at the turn of the century, I suspect that the hockey-stick of residential housing has made it a bit inaccurate.

And something that I didn't really understand until an architect cousin explained to me is that modern commercial buildings mostly have a designed lifespan, typically 50-100 years.

Yeah, modern commercial buildings suck compared to many of the old skyscrapers and government buildings built >100 years ago. The Empire State Building, the capitol building, grand central station, etc. Just walking through them you can tell by the materials and craftsmanship that they were built to last.

Modern buildings, on the other hand, feel cheap and their unlimited flexibility leaves them with no inherent character.

There's a bit of irony with this thread I think but this was Minix's creator's viewpoint as well:

https://www.cs.vu.nl/~ast/Publications/Papers/computer-2006a...

> No known bugs

That's too high a standard. If nothing else, differences of opinion over the design are sometimes classified as bugs. No known bugs worth the effort to fix and deploy is acheivable.

Most NES software is done, none of the bugs are worth recalling to update roms.

TeX and METAFONT are designed to be "done" when Knuth dies:

> At the time of my death, it is my intention that the then-current versions of TEX and METAFONT be forever left unchanged, except that the final version numbers to be reported in the “banner” lines of the programs should become TeX, Version $\pi$ and METAFONT, Version $e$ respectively. From that moment on, all “bugs” will be permanent “features.”

Hah, that's a pretty reasonable way to define done.

Considering the last list of bugs: https://tug.org/texmfbug/tuneup21bugs.html

I think he's getting pretty close to perfection - his report on it https://tug.org/TUGboat/tb42-1/tb130knuth-tuneup21.pdf and hopefully he'll live to do the next one in 2029.

His dedication to the unchanging format is important, I can compile ancient TeX documents that are almost older than I am with no changes, and I can compile LaTeX documents almost as easily.

Nothing is ever done. Even things as established as the bicycle and cooking are under constant evolution, research, and improvement. Software is hardly getting started in comparison.

The problem is not fulfilling the requirements -- that can happen. The problem is that requirements change when the rest of the world does.

If remodeling buildings had the ROI that continued development of software does, that would happen all the time too.

There's still chatter in the Google Group and GH Issues, and some GH PRs.

https://groups.google.com/g/minix3?pli=1

https://github.com/Stichting-MINIX-Research-Foundation/minix

The pull requests list is better than the issues list.

This non-bug asks for a video on how to use OpenSSH:

* https://github.com/Stichting-MINIX-Research-Foundation/minix...

This one was fixed in 2017:

* https://github.com/Stichting-MINIX-Research-Foundation/minix...

This non-bug asks for where to start when learning:

* https://github.com/Stichting-MINIX-Research-Foundation/minix...

I've gone through quite a few of these at random, for this and another comment on this page, and this one is the first one that is even close to an outstanding bug, and it's only open because the pull request that fixed the problem back in 2020 hasn't been merged yet.

* https://github.com/Stichting-MINIX-Research-Foundation/minix...

"No new bugs have been introduced into Minix in five years, and it hasn't gotten any more bloated!"

I think people got everything they wanted in Minix: https://lore.kernel.org/all/30th.anniversary.repost@klaava.H...

Yeah, it's gone. Worked with a guy pre-Intel. The current tree has loads of bugs from a couple students tinkering for their projects (it even working is in question).

Like others have mentioned, Intel is the only (large) organisation actively developing it, but their work is not shared back.

I'm glad people are talking about this. Minix has so much potential, and it needs a community. It also has a very specific area of need, it's not like you would install it on a desktop and I doubt you can get it running with a purpose in AWS.

https://www.zdnet.com/article/minix-intels-hidden-in-chip-op...

"These processors are running a closed-source variation of the open-source MINIX 3. We don't know exactly what version or how it's been modified"

You'd hope the version they use has been worked on in the last 5 years.

Or maybe you'd hope it hasn't - if there are holes in it then you've got a better chance of being able to regain control of your own hardware.

So does everyone else.

Hoping that intel drops the ball on your processors security in what is likely a high dollar research area for most nation states is not a great play.

In theory you can just turn it off in your bios but, who knows?

> You'd hope the version they use has been worked on in the last 5 years.

And yet, so many hopes are dashed.

I'm glad this is getting brought up. Minix has so much potential and it is due for an open source community to care with a mission. Its hard to find where an org would use it since Linux is so popular and so few orgs really need a hyper reliable operating system with limited libraries and dependencies. Military or space problems?

For both military and space applications, I believe that real-time operating systems are employed. Minix is not in the sphere of RTOS.

Yes, and also if it has to be certified for functional safety (as a lot of systems that use those kind of RTOSes have to be) then that really has to be designed into the system from the start. So Minix would probably be a non-starter in that regard too (as is something like Linux)

Wish I had more knowledge of OS so I can build some tools or parts on top of it. Looks like a great project to have a bit of ownership.

Guessing Fucshia/Zircon probably took some attention away from Minix as well.

Intel is keeping MINIX alive. If you have an Intel chip there is a remote access to your disk even when the machine is "off'. Foreign governments leverage this to spy on USA, all vulnerabilities in the Intel ME are totally accidents and not intentional.

Reply on news.ycombinator.com