The MirOS BSD project has released MirOS BSD xi. “The MirOS Project proudly presents release 10 of MirOS BSD: MirOS xi. A mini-ISO for the installation can be downloaded from mirbsd.org. This image can be burned to a CD and used for installing over the network. The full CD image can be downloaded via BitTorrent. MirOS BSD is a secure operating system, originally based on OpenBSD, for i386 and sparc machines. Read more about it at the ‘About MirOS‘ page.
The About link must be http://www.mirbsd.org/?about for now.
And I really hate you, OSAlert, as I have to actually
use Opera to post this comment. Why does it not work
in Lynx?
From Wikipedia:
Interesting. And a rather heretic sounding idea in the BSD world… I wonder what is the motivation? Better drivers and support for some advanced features available only in Linux?
A Linux based OS with many MirOS/OpenBSD features would sound quite nice to me.
I think you’ll find this is out of context and should be taken in the vein the name has move to MirOS from MirBSD as default due to MirOS ports etc running on a variety of platforms, not that MirBSD is going to be dropped in favour of a linux kernel’d implementation.
Yep, and that is not even suggested. But they seem to play with the idea of using their tools and ideas both on Linux and BSD kernels.
MidnightBSD and MirOS teams could cooperate. Both include talented people who could combine their forces instead of splitting resources. They both try to create a BSD OS using different ideas. Their vies are complementary and so instead of wasting time they could both focus on the same thing as allies.
Edited 2008-03-19 09:43 UTC
The goal of MidnightBSD is the Desktop. So it _is_ something different. And guess what? It’s open source, so in the end they are already working together.
.
Edited 2008-03-19 10:41 UTC
I think this feature is good and would be nice to have it in other BSDs and Linuxes. What do you think?
–“Dotfiles” in .etc–
Both MirOS and MirPorts should put most of
the “dotfiles” in users’ home directories in a
single directory named “.etc”. For example, ssh
uses “.etc/ssh” for its configuration files.
This greatly reduces the clutter of hundreds of
hidden files in the home directory. All of the base
system uses this convention, but at the moment,
only a few ports do.
(From the MirOS information flyers
http://www.allbsd.de/src/Flyer/MirOS/ )
Edited 2008-03-19 10:43 UTC
Agreed. It would be a very good idea in order to clean the home folder from dozens of configuration files. If only Linux and Unix software had implemented that already years ago. Now it takes some time before the current system can be changed.
I’ve made this ~/.etc/ (or similar) suggestion many times, and have always received the same negative or luke-warm responses, most of which amount to: Dot files are already hidden, this does not reduce clutter.
The only real advantage, when you think about it, is rm -rf ~/.etc works better than rm -rf ~/.* (don’t run this command! It is more destructive than you probably expect.) If you’re thinking “But I never delete my configuration,” then replace rm with cp/scp and think settings synchronization.
The only other advantage is psychological.
I’m still in favor of it, because psychology matters. It would be nice to be able to simply say “The directory name makes no sense, but /etc/ is global configuration and ~/.etc/ is user configuration.” Of course, this is not entirely true, especially on e.g. freebsd, some Linux distros that like /boot/grub/, etc., etc..
Since I have started Opera anyway, I think I can
reply to you all now. But please do not expect any
further reply from me here, as this forum is inap-
propriate ^aEUR“ it doesn^aEURTMt let me respond with Lynx,
and I do not want to be forced to use a GUI browser.
> From Wikipedia:
I did not write the Wikipedia entry, nor did I ever
see it, as the licence of Wikipedia is unfree enough
to forbid me looking at it (the anti-DRM clause hits,
as the browser stores a local copy, and I have encryp-
ted filesystems).
> One of the projects goals is to port the MirOS to
> run on the Linux kernel
We could do that, in theory, but it^aEURTMs not a project
goal. Actually, we just don^aEURTMt have the manpower to
maintain it. (And I don^aEURTMt want to go to the pain to
do the initial porting effort rigt now ^aEUR“ there are
a lot more important things to do.)
I suggest you use official documents instead of un-
reliable non-freely-licenced third party documenta-
tion.
@swishy: the MirPorts Framework being portable has
not much to do with the MirOS base system running
on several platforms (although it could be seen as
a first step). We do whatever we deem interesting
and/or useful and can do with our limited time, as
we (developers) have a real life to live.
@fithisux: MirOS and MidnightBSD do co~APperate. We
do not waste time, and we have different project
goals and a different code base, but some things
we do together (e.g. we do PR for the other project
where we can, and MidnightBSD has replaced pdksh/oksh
by mksh, and MirPorts work on MidnightBSD, and we sit
in each other^aEURTMs IRC channels and help each other).
But there won^aEURTMt be too much code sharing, since mnbsd
used fbsd as their base, which is so totally unlike
any traditional BSD.
@Konjofsky: thanks.
It^aEURTMs quite an effort to ensure this for all the
applications, but this from /etc/profile:
export XDG_CACHE_HOME=$HOME/.etc/xdg/cache
export XDG_CONFIG_HOME=$HOME/.etc/xdg/config
export XDG_DATA_HOME=$HOME/.etc/xdg/data
^aEUR| helps, and we patched some of the software via
MirPorts. Not all, though, mind you. Diffs welcome.
@Oliver: ^aEURzthe^aEURoe desktop does not exist. MirBSD, for
example, has a much more up-to-date GNOME than OpenBSD,
even if end-user desktops are not one of our primary
target groups. Things are not exclusive. While I^aEURTMd
like to get more of the embedded market, we remain a
general-purpose multi-platform operating system.
@irbis: the BSD kernel isn^aEURTMt going to be dropped. The
Linux kernel would only be supported since a friend of
mine wanted to play 3D FPS games^aEUR|
There _is_ a kernel I^aEURTMd like to actually support as an
alternative to the BSD kernel. The problem is that it^aEURTMs
not yet written.
The BSD kernel was not designed with multiprocessing in
mind, so I refuse to do hacks like OpenBSD to add SMP
to it in a biglock style (which even slows things down).
For proper MP (asymmetric, too) support, almost all of
the non-driver-code in the kernel (and some driver
parts) would have to be rewritten ^aEUR“ while keeping the
BSD spirit and the APIs (BSD, but also compat_*(8)).
Since it does not exist, and no MirOS developer has
enough spare time, will and capabilities to support
that, this will be left to academics.
—-
If you have any further questions, please use the
appropriate places to ask ^aEUR“ the IRC channel or mailing
list.
Thanks!
Are you sure? OpenBSD 4.2 has GNOME 2.18 and OpenBSD 4.3 has GNOME 2.20.3.
http://www.openbsd.org/42.html
http://www.openbsd.org/43.html
http://www.solgel.com/sgforum/forum_posts.asp?TID=1561&PID=3709
http://www.solgel.com/sgforum/forum_posts.asp?TID=1558&PID=3706
http://www.solgel.com/sgforum/forum_posts.asp?TID=1559&PID=3707
http://www.solgel.com/sgforum/forum_posts.asp?TID=1560&PID=3708
http://www.solgel.com/sgforum/forum_posts.asp?TID=1562&PID=3710
http://www.bebo.com/Blog.jsp
Am I the only one which feels that a distro hell is creeping in the BSD camp ?
Yes because a fork != distro.
FreeBSD
OpenBSD
NetBSD
DragonFlyBSD
Some smaller ones:
MirOS
MidnightBSD
PC-BSD and DesktopBSD are neither forks nor distros (in terms of a Linux distro). They are preconfigured FreeBSDs.
BSD first was a patchset to original UNIX in the 70s. Later it was a fork. SunOS was a fork of BSD and so on. So there is nothing wrong about it. If _you_ don’t like a fork, _you_ will not use it – so in the end the community decides about the outcome of a fork.
In what sense (other than there being more than the three you were previously aware of)?
In any case, there’s no such thing as a BSD “distro”, at least in the sense that term’s applied to Linux. Linux distros are conglomerations of externally- and independently-maintained components. BSD variants separately maintain their own kernel and userland components in a highly integrated fashion, using code lineally descended from William Jolitz’s 386BSD).