Slashdot videos: Now with more Slashdot!

View

Discuss

Share

We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).

An anonymous reader writes "MINIX 3.2.0 was released today (alternative announcement). Lots of code has been pulled in from NetBSD, replacing libc, much of the userspace and the bootloader. This should allow much more software to be ported easily (using the pkgsrc infrastructure which was previously adopted) while retaining the microkernel architecture. Also Clang is now used as a default compiler and ELF as the default binary format, which should allow MINIX to be ported to other architectures in the near future (in fact, they are currently looking to hire someone with embedded systems experience to port MINIX to ARM). A live CD is available."
The big highlight is the new NetBSD based userland — it replaces the incredibly old fashioned and limited Minix userland. There's even experimental SMP support. Topping it all off, the project switched over to git which would make getting involved in development a bit easier for the casual hacker.

Git? Seriously? So the system developed by the primary "enemy" (or so it's portrayed) of the designer of MINIX (and most vocal opponent of the way MINIX operates) is used to develop MINIX itself now, presumably because "it works" even if it's not architecturally perfect?

I can't decide if that's incredibly ironic, or a wonderfully beautiful illustration of Open Source.

I see an interesting convergence of some technologies happening. clang is on the roadmap for several BSDs and now is default on Minix. NetBSD tools were pulled in which are also used in part on several other systems. The Minix folks will probably upstream fixes to NetBSD as well as make improvements to llvm.

It's great to see alternatives to GNU tools gaining ground. It's the only logical choice for embedded systems due to licensing. We're going to need to step up our game and make our own tools with threats like Wayland coming.

>It's great to see alternatives to GNU tools gaining ground. It's the only logical choice for embedded systems due to licensing. We're going to need to step up our game and make our own tools with threats like Wayland coming.

Remember it for what it was originally made for... an operating system to learn from while coding.You might not remember those days, but when you have a working operating system that is minimal in code size, it's easier to grasp.

I'm just a little disoriented by the need to advance it, unless it's a minimal codebase of the NetBSD variety. Then again, they did say it was "pulled" from NetBSD, so that'd mean in my mind it's not minimal... which nullifies that.... and we're back to square one.

It will be nice if people start to realize that their code needs to compile on things other than GCC. These days you can't even compile a lot of software if you have a different version of GCC than the author did.

For those of us that don't know what Wayland could be, might you freshen our feeble minds with it's definition?

It's a massive FUD attack designed to replace Xorg with a less featureful but shinier replacement which also makes a number of the same mistakes that were made by OSX and Windows, rather than keeping the better design of parts of Xorg. On the other hand, it's something new which will keep the developers who have got bored with Xorg happy.

Wayland won't feature remote windowing. The best we can hope for is a pixel-scraper which dumps compressed bitmaps over the network.

Wayland seems to feature client side decorations. This has the advantage that every toolkit will give subtly different window decorations, hung applications will have immovable windows and it will be difficult to imlement global policies such as snap-to-window or snap to edge etc.

Wayland also solves a host of completely unrelated problems (apparently). See, one problem with Xorg is tearing in video. I don't have this problem on any of the intel chipsets I have, so it's clearly not an Xorg problm but a problem with drivers for other chipsets. Wayland people claim that wayland will solve this, apparently by magically dealing with the undocumented chips and proprietary blobs from other vendors.

Wayland does reduce the latency for compositing windowmanagers by removing a number of program->xorg->WM->xorg messages. Given that these are coming at a rate of positively 10s per second from your mouse, this is terribly important since Linux can't deal with high data rate, low latency messages.

About the only use-case for wayland is so that you can have a nice graphical transition butween multiple X servers running on a single monitor on a computer. I think that's definitely giving up network transparency for!

Wayland also seems to incite blatantly disengenuous claims from people who should know better like "oh you will be able to run Xorg on top of wayland". This completely ignores the fact that new wayland only programs won't have remote networking and secondly on every other system which does this, X11 is very much a second class citizen and the programs don't integrate properly with the native system.

Oh, apparently the BEST thing about Wayland is that it no longer has the 1980's style graphic primitives. This means that X is old and unfashionable. It also means that the Wayland developers have apparently never heard of software modularity where a bunch of rarely used function calls can sit somewhere on the side in a different source file and not clutter up the main body of code.

Its an educational tool not a training tool. Education is learning how stuff works, training is votech. Almost no one in the world will ever be hired because of minix on a resume. It is helpful for learning how OS work. Another way to put it is education gives you something interesting to think about, makes life worth living. Training gives you a way to make money to afford the contemplative life of an educated person. Its an educational tool.

Of the various microkernels that ever existed @ different times, Mach 3 was less than satisfactory, Chorus ended up digested by Sun, and Amoeba itself today stands discontinued. L4 is a 2nd generation microkernel that has been tried out in some projects, including a Linux project called L4Linux as well as an OS/2 successor called OSfree. There are some other microkernels, such as Coyotos & Viengoos that have in the past been tried by the Hurd project.

I'd think that something like Minix 3.0 (not 3.2) would be a good microkernel to base Hurd on. Given the licensing differences, the Hurd guys may need to fork Minix anyway in order to get a microkernel that has everything that Hurd needs. If they get that, they can then continue on the rest of the project, and finally have the GNU's own kernel (which ain't Linux).

On another note, I wonder why the Minix guys chose the NetBSD userland, since NetBSD is the least used BSD among the big 3. They could have simply gone w/ FreeBSD, which would have given them a range of targeting options, allowing them to borrow from PC-BSD for netbooks, pFSense for routers/firewalls, FreeNAS for storage, and so on.

And finally, I do hope they get an arm version sometime. Another suggestion - they might want to get a Raspberry Pi and port the ARM Minix to that platform, making it the target platform for this initially.