MirOS BSD originated as a patch set against OpenBSD-current, a 4.4BSD-derived ultra secure operating system. This release includes bugfixes and enhancements for many system components, including libc, ld.so, ntpd, make, and others. There is support for PowerNow on AMD Athlon / Athlon XP systems. libexpat is in the base system now. gcc support for C++ and other languages is still missing.
MirBSD #8-beta-20041016 Released
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
As a FreeBSD user I had heard about MirOS only occasionally – since it was not one of the “big 4” BSD’s. Now, I’ve just visited their homepage, and as soon as I’ve got time I’m gonna download it and try it out.
One might think that different BSD projects might disperse some developing energies, but on second thoughts, reading that these projects are well integrated with each other (MirOS is constantly kept is sync with OpenBSD, as you can read in their ‘About’ page), I understand that the dispersion is minimal, and having a certain amount of variants (I don’t call them “distros” because they don’t necessarily share the same kernel) is indeed an enrichment for the whole BSD community.
Anyway, I got curious to know if there were other minor BSD flavours around. I stumbled into this list – I don’t know how accurate it is, but it’s somewhat interesting
http://en.wikipedia.org/wiki/Category:BSD
Is BSD becoming like linux? Will soon BSD have hundreds of distributions? Can’t we all just get along and just develop NetBSD, OpendBSD, and FreeBSD. 3 major ones are enough.
Can’t we all just get along and just develop NetBSD, OpendBSD, and FreeBSD. 3 major ones are enough.
—-
people think linux distros are somehow bad inherently and are scared that bsd will “fork”.
let me tell you guys. only a handful of linux distros are relevant to the majority. the rest are just details in distrowatch.com.
bsd can “fork” as much is wants to as long as these bsd flavors actually differentiate between themselves to be meaningful while not feeling bad about sharing code where appropriate.
there are many proprietary forks of bsd. this isnt an advantage but its not big loss considering that bsd license is designed for that.
I am pretty sure we will see more flavors of bsd in the future. not any less
Well… I wouldn’t promote forking, though. A fork always weakens a project, and if it happens, there should be some serious reasons. I’m not particularly eager to see new forks, in absence of these.
If objectively there are new *big* ideas to experiment – and if you can’t do it in one main BSD project – then it makes sense. Otherwise, if it’s mainly a question of the egos of the programmers, then the forking is pointless and destructive.
Hopefully, the DragonFly fork belongs to the first kind. They say they’re experimenting a very different design, about the kernel threading model (LWKT): we’ll see how it turns out.
Anyway I really think the number of BSD variants shouldn’t outnumber the ideas that’s worth experimenting. Otherwise there *will* be a useless dispersion of programming skills. In Linux there *is* this kind of dispersion, it’s unavoidable when you have tons of different distros that have to be released, maintained, etc.. I definitely wouldn’t like to see the same thing in the BSD world.
Personally, I believe that sticking with one of the three major BSD variants is the way to go (I stick with FreeBSD). But one should never stop trying the other ones, for experiment’s sake, in order to recognize new valid ideas. 🙂
Anyway I really think the number of BSD variants shouldn’t outnumber the ideas that’s worth experimenting.
I meant:
Anyway I really think the BSD variants shouldn’t outnumber the ideas that’s worth experimenting.
there are many proprietary forks of bsd. this isnt an advantage but its not big loss considering that bsd license is designed for that.
One minor clarification: not designed for that, but designed *to allow* that.
Plus, in a BSD perspective, a proprietary fork is not a loss at all: the original BSD code is still free. But I can understand how the proprietary enhancements are seen as a loss in a GNU/GPL perspective.
on the website they’ve said things like mirOS or mirports on a linux kernel and what not… they clearly show support for the linux kernel and will move their OS onto the linux kernel as they have a version of MirOS that runs on linux and seem to be only releasing mirBSD to satisfy a few users..
First, thanks for reporting on this.
I’ve got to say a few things:
1) “gcc support for C++ and other languages is still missing”
This looks a bit misleading. I’ve disabled building all
gcc languages except C and Ada a short time ago _again_,
but this time for transitioning to gcc 3.4, whose C and
probably Objective-C compilers will be part of the base
installation, whereas the other compilers (C++, Pascal,
Java(TM), Fortran, Ada) can be installed together with
the unfree, GNU FDL-licenced, documentation as a sepa-
rate ‘convenience package’ during the OS installation;
they are not considered part of MirOS (actually, right
now C suffices to build MirOS, since all C++ code got
ripped out thanks to Calder^WSCO) for licence (documen-
tation is GFDL, libgjc is “said” to infect with GPL)
and practical (GNU make is “required” to build gcc, and
unlike 3.2, I’m not gonna patch Ada to BSD make again)
reasons.
To be exact, I’ve already started with that.
You might want to read the mailing list archives, eg. at
http://news.gmane.org/gmane.os.miros.general, for a more
detailed prognosis.
2) ulib, have fun trying it out. Please don’t link to
Wikipedia in the future because of the unfree licence.
3) the trolls… I’m not going to comment on them.
4) “A fork always weakens a project” – this is only true
if the project being forked is affected from that in
any way, and we’ve recruited our developers among USERS
of OpenBSD, not developers (and taken over three former
ekkoBSD developers since). We all know each other
personally (well, the Europeans don’t know the north-
americans, but that might change too). And since we’ve
given back to OpenBSD, most recent example being the
‘flags 0x0040’ for pcibios0 in the kernel config, both
projects benefit from that.
There’s also Theos statement that he will never accept
me as OpenBSD developer.
5) MirOS Linux and MirOS Interix
This is more like a “fun” project – there are actually
a few hooks in the system already to allow to build
MirOS with a different kernel – first idea was the
Linux kernel; Interix (Microsoft Services for Unix) is
probably much less of an effort (except the PE format),
and there’ll probably appear a “MirOS BSD/SMP” some
time soon, because “MirOS BSD” (the main variant) will
not use the poor MP abilities of OpenBSD.
6) MP
While commenting on that, to prevent the flames: we
(well, mostly I) think SMP is a bad idea – not necessa-
rily by itself, but we’re not going to use biglock and
kludges in the BSD kernel. Proper MP (SMP, AMP, NUMA
and whatnot) requires rewriting FROM SCRATCH about 90%
of the non-driver code in the kernel, and a good 10-15%
of the driver code, which would result in ANYTHING, even
usable, but not BSD any more.
That’s why MirOS BSD won’t offer SMP, but maybe someone
would prepare a MirOS BSD/SMP (except tyler@ nobody’s
interested in that ATM though, and we’re low on funds
as well as spare time).
Finally: if you want to further comment on this, feel free
to either send an eMail to the MirOS discussion mailing
list or use the gmane webinterface (see above) for posting,
it’s possible.
openbsd should not be smp as it is not a security priority. sure, crpyto-hardware-offloading is … and its great that openbsd put early effort into this… but smp is a computational isssue … not the aim on openbsd. and its a shame that openbsd feels it must offer it just to be relevant. the comments in the post by mirabile that mirBSD won’t offer kludged MP are encouraging.
Even beyond licensing issues (though I feel them too, thanks for pointing it out), the wikipedia link in my first post was incomplete – for example, emBSD & microOpenBSD (2 minor, seemingly discontinued versions) were missing.
Just for curiosity’s sake, these links seem way more complete:
http://staff.mybsd.org.my/zam4ever/www/link/bsdlink.htm
http://www.screamingelectron.org/forum/archive/index.php/t-495.html
“openbsd should not be smp as it is not a security priority. sure, crpyto-hardware-offloading is … and its great that openbsd put early effort into this… but smp is a computational isssue …”
What a crock, I have a friend who runs an ISP in New York, wholly on OpenBSD, and his single processor mail server (P4, 2Ghz IIRC) was dying under the load of his small-ISP’s spamassasin requirements. Given the movements towards dual core, and the more common that MP systems become, OpenBSD _should_ be moving forward, saying otherwise is IMHO the equivilent of “640k should be enough for anybody”
There’s no reason a MP-OS can’t be secure
Well, good on you! A bit extra diversity in the ecosystem’s not going to harm anyone, and will only make it more robust.
FWIW, I’ve been collecting a sort of source tree of *BSD, dating back to 3BSD.
The reason is to have a stack of openly available code to hand in case we find ourselves (the F/LOSS community) up against Yet Another SCO Group infestation/infection.
I’ve been downloading MirOS BSD (the old code tarball) – what a whopper for a dial-up connection!
It’ll be an interesting day’s work running compare or some other such utility over the many *BSD source trees.
There comes Tyler, the MP advocate in the MirOS team.
I’m still waiting for his contributions for MirOS SMP *g*
Wesley: have fun doing so, and if you should encounter
“problems” with our codebase, please do not hesitate to
contact us, probably via eMail.
bye