Linked by Thom Holwerda on Tue 18th Mar 2008 21:37 UTC
BSD and Darwin derivatives 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.
Order by: Score:
Wrong link
by mirabilos on Tue 18th Mar 2008 22:46 UTC
mirabilos
Member since:
2008-03-18

The About link must be http://www.mirbsd.org/?about for now.

And I really hate you, OSnews, as I have to actually
use Opera to post this comment. Why does it not work
in Lynx?

Reply Score: 1

MirBSD -> MirOS
by irbis on Tue 18th Mar 2008 22:50 UTC
irbis
Member since:
2005-07-08

From Wikipedia:

One of the projects goals is to port the MirOS to run on the Linux kernel, hence the deprecation of MirBSD in favor of MirOS.

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.

Reply Score: 2

RE: MirBSD -> MirOS
by swishy on Wed 19th Mar 2008 01:47 UTC in reply to "MirBSD -> MirOS"
swishy Member since:
2008-03-19

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.

Reply Score: 1

RE[2]: MirBSD -> MirOS
by irbis on Wed 19th Mar 2008 11:15 UTC in reply to "RE: MirBSD -> MirOS"
irbis Member since:
2005-07-08

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.

Reply Score: 2

MidnightBSD???
by fithisux on Wed 19th Mar 2008 09:43 UTC
fithisux
Member since:
2006-01-22

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

Reply Score: 2

RE: MidnightBSD???
by Oliver on Wed 19th Mar 2008 11:03 UTC in reply to "MidnightBSD???"
Oliver Member since:
2006-07-15

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.

Reply Score: 3

âDotfilesâ in .etc
by Konjofsky on Wed 19th Mar 2008 10:33 UTC
Konjofsky
Member since:
2008-03-19

.

Edited 2008-03-19 10:41 UTC

Reply Score: 1

Dotfiles in .etc
by Konjofsky on Wed 19th Mar 2008 10:42 UTC
Konjofsky
Member since:
2008-03-19

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

Reply Score: 1

RE: Dotfiles in .etc
by irbis on Wed 19th Mar 2008 11:20 UTC in reply to "Dotfiles in .etc"
irbis Member since:
2005-07-08

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.

Reply Score: 2

RE[2]: Dotfiles in .etc
by sorpigal on Wed 19th Mar 2008 17:13 UTC in reply to "RE: Dotfiles in .etc"
sorpigal Member since:
2005-11-02

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

Reply Score: 2

Reply to all of you
by mirabilos on Wed 19th Mar 2008 14:34 UTC
mirabilos
Member since:
2008-03-18

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 – it doesn’t 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’s not a project
goal. Actually, we just don’t have the manpower to
maintain it. (And I don’t want to go to the pain to
do the initial porting effort rigt now – 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öperate. 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’s IRC channels and help each other).
But there won’t be too much code sharing, since mnbsd
used fbsd as their base, which is so totally unlike
any traditional BSD.

@Konjofsky: thanks.
It’s 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
… helps, and we patched some of the software via
MirPorts. Not all, though, mind you. Diffs welcome.

@Oliver: „the“ 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’d
like to get more of the embedded market, we remain a
general-purpose multi-platform operating system.

@irbis: the BSD kernel isn’t going to be dropped. The
Linux kernel would only be supported since a friend of
mine wanted to play 3D FPS games…

There _is_ a kernel I’d like to actually support as an
alternative to the BSD kernel. The problem is that it’s
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 – 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 – the IRC channel or mailing
list.

Thanks!

Reply Score: 3

RE: Reply to all of you
by smeglister on Wed 19th Mar 2008 18:54 UTC in reply to "Reply to all of you"
smeglister Member since:
2005-07-07

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.


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

Reply Score: 1

Distro
by Treza on Wed 19th Mar 2008 15:42 UTC
Treza
Member since:
2006-01-11

Am I the only one which feels that a distro hell is creeping in the BSD camp ?

Reply Score: 1

RE: Distro
by Oliver on Wed 19th Mar 2008 20:11 UTC in reply to "Distro"
Oliver Member since:
2006-07-15

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.

Reply Score: 3

RE: Distro
by Natorp on Wed 19th Mar 2008 20:38 UTC in reply to "Distro"
Natorp Member since:
2007-06-14

Am I the only one which feels that a distro hell is creeping in the BSD camp ?


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

Reply Score: 1