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.
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.
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.
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.
> 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.
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.”
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.
> And the other hand I often hear people complain about out of touch politicians regulating fields where they completely lack any understanding.
Thoughtfully engaging with policy isn't a waste of time, but that not what the website in question was doing. It looked like it was all poll numbers and horse-race analysis, that's the stuff we should leave for the hacks.
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...
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.
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.
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.
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.
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.
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.
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.
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?
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)
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.
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.
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.
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)
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.
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
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.
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.
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.
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.
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.
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.
115 comments
[ 3.0 ms ] story [ 182 ms ] threadYou'd hope the version they use has been worked on in the last 5 years.
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?
And yet, so many hopes are dashed.
Things like Docker demonstrate all that matters is encapsulation by those interested in keeping these projects live.
So it surely doesn't apply here.
* 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.
tambourine_man posed a valid hypothetical, but that's all it is: hypothetical.
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.
Modern construction requires a significant amount of maintenance. The Romans on the other hand, they knew how to build a building!
When I refer to problems that go unaddressed I'm thinking of problems like "this bathroom is too small", not "the roof needs replacing".
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.
Modern buildings, on the other hand, feel cheap and their unlimited flexibility leaves them with no inherent character.
https://www.cs.vu.nl/~ast/Publications/Papers/computer-2006a...
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.
> 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.”
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.
If remodeling buildings had the ROI that continued development of software does, that would happen all the time too.
https://en.m.wikipedia.org/wiki/Andrew_S._Tanenbaum
Thoughtfully engaging with policy isn't a waste of time, but that not what the website in question was doing. It looked like it was all poll numbers and horse-race analysis, that's the stuff we should leave for the hacks.
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.
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?
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
1 - https://www.tomshardware.com/news/google-removing-minix-mana...
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.
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/
https://groups.google.com/g/minix3?pli=1
https://github.com/Stichting-MINIX-Research-Foundation/minix
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...
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.
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.
i thought this was a kernel/OS level concept, could you expand more?
https://retrocomputing.stackexchange.com/questions/26516/wha...
https://en.wikipedia.org/wiki/Task_state_segment
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.
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.
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
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.
https://en.m.wikipedia.org/wiki/Xenix
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.
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
Then what Intel is keeping alive is a private fork, not the thing that's available online.
https://www.bleepingcomputer.com/news/hardware/intels-secret...
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.
Like others have mentioned, Intel is the only (large) organisation actively developing it, but their work is not shared back.