freebsd should be rewritten based on microkernel architecture

[Polytropon]

On Fri, 17 Apr 2020 15:15:20 +0800, kindu smith wrote:
> First of all, freebsd's architecture is very good, no need to invent
> the wheel, but freebsd's installation interface and startup interface
> are too old. It is time to make some changes.

Well, I don't think so. Per definition, FreeBSD is a
multi-purpose operating system. So if you'd intend to
slap a GUI installer on it, it would be immediately
unusable for servers or embedded platforms. Keep in
mind that for all platforms, _one_ FreeBSD OS exists,
and it's basically the same on all platforms (leaving
the architecture aspect aside). In my opinion, the
installer, currently in text mode, does exactly what
it is supposed to do: Install the OS. Nothing else.
Sure, you can use it to change system settings or
install packages, but there are usually better tools
to do this. There are GUI tools for such tasks, even
web-based ones, if you prefer. And still, under the
hood, everything is text files and CLI utilities, so
no need to sacrifice anything.



> I think the freebsd with
> microkernel will be more stable.

There is no actual relationship between "microkernel"
and "more stable"; however, a microkernel offers a lot
of security benefits. No need to render malformed font
files in kernel space. ;-)

FreeBSD has, compared to other UNIX and Linux operating
systems, a quite small kernel. Extended functionality
can be obtained via loadable kernel modules which are
optional. You can even compile your own minimalistic
kernel, as the OS offers all needed infrastructure (!)
to do this - no 3rd party tools needed.



> The / boot / kernel directory is very
> suitable for writing a small kernel, such as named core, and then
> design some modules around and package it in this directory. Then,
> under / boot, create some new directories such as EFI, API, ABI, model,
> etc. to do EFI boot and application program interface, and user space
> modules.

More or less, this is what FreeBSD already does. And
as I said, the _default_ kernel doesn't include evething
that can be included, just a well-intended set to match
most settings where it will be used in. The source directory
/usr/src maps that structure and purpose.



> I think this will be a perfect design. As for the design
> pattern of the microkernel, you can refer to haiku (a clone of beos).

Yes, I fully agree.



> In addition, you need to redesign the installation interface and a
> complete desktop environment, because this is very important for
> novices.

Erm... no.

FreeBSD is an operating system. Most desktop environments
are ported over from Linux. There is (was?) an approach
to create a desktop called Lumina which would be native
to FreeBSD and not suffer from all the Linuxisms that
modern DEs requred, leading to inconventient things as
running software like HAL and DBus which have been abandoned
in Linux many years ago.

And as I said, FreeBSD isn't just for desktops. It's alos
for servers, for appliances, for "combined forms" - _one_
OS for all those purposes. When you install FreeBSD on a
server, or on a headless machine where you just access it
via serial console, you don't want or need a graphical
installer, let alone a full-blown desktop system forced
upon you. What's the benefit of adding complexity (!) to
the OS for no real benefit? Imagine a server which doesn't
even have a graphics card - how useful would it be if
FreeBSD installed automatically (!) a desktop system and
GUI application software?

FreeBSD draws a convenient line between "the OS" (that's
what the FreeBSD developers create and maintain), and
"everything else" / "3rd party software" which is managed
using the ports collection and the appropriate port
maintainers. Putting _that_ complexity into the realm of
the OS is, in my personal opinion, the exact _wrong_ thing
to do.



> I don't think Gnome / kde / xfce or the like is used anymore.

They are actually used on FreeBSD, but sometimes require
you do do strange things to get them working as intended. ;-)



> It is designed for Linux, and the systemd it uses is not supported by
> Freebsd.

Correct - and _that_ is the idea behind a native solution.
However, what good is a desktop with no application software?
And that kind of software, no matter of you consider boring
office stuff, multimedia applications, or games - are still
developed with Linux as their primary target. So you can
easily conclude that if you don't need HAL and DBus for the
native desktop, you'll need it for the GUI DVD creating
application you wish to use.



> Freebsd should design a gorgeous interface comparable to macos, in
> addition to a set of init programs comparable to systemd.

Uh... systemd, and the concepts behind it, and especially
their implementation over in Linux world is highly debatabe,
and among system designers heavily criticized, usually as an
approach to "one size fits all egg-laying wool-milk-sow in
a black box". The beauty of FreeBSD lies (among others) in
the fact that things are logical and predictable. Without
even looking, you can tell where certain files are, in what
order services will start, or how things are interconnected.
With systemd, there's the danger of losing the ability to
spot and diagnose problems, because of "black box".



> Therefore,
> both the bootloader and init programs need to be redesigned.

Which boot loader? FreeBSD uses a "multiple stage loader";
see "man 8 boot" for details.

As you can see - even _that_ is documented locally, without
you requiring to search web forums, user pages, wikis, or
anything else scattered online. :-)



> For
> example, when Linux starts, it displays ok and colored driver loading
> reminders. Freebsd can learn from it.

FreeBSD _does_ this, if intended.

Honestly, I prefer a working driver over one that shows me
animated icons - and then crashes. ;-)



> I think that the Linux startup
> program is not perfect. It is still in the startup mode similar to the
> console.

What's the problem? On a server or a network appliance,
that's what you have to work with.



> The more modern startup program should be a perfect
> combination of graphical and startup information.

Which you cannot see on a server. Bad idea. In my opinion,
you should be able - and FreeBSD offers this! - to hide the
boot process; but in case something goes wrong, you can
still immediately view all steps and error messages in a
"live setting" without requiring 3rd party tools to parse
binary databases for error messages.



> The driver is a flaw
> of freebsd.

Which driver?



> Due to the limited number of developers, a large number of
> other systems are required, such as copying from linux. so copy it from
> linux.

FreeBSD and Linux are different systems. They have lots of
stuff in common (which is typical for UNIXes and UNIX-like
operating systems), but they are not the same, so 1:1 copying
isn't technically possible.



> The GPL agreement does not affect the use of freebsd code. Only
> in this way can freebsd and linux form a differentiated competition,
> can freebsd survive the huge wave of linux.

Engaging a discussion about possible licensing issues probably
is futile. Let's just agree that there are incompatible models,
and all those models have their purpose and intention, and each
of them is good for something and someone.



-- 
Polytropon
Magdeburg, Germany
Happy FreeBSD user since 4.0
Andra moi ennepe, Mousa, ...