Date: Fri, 17 Apr 2020 12:00:35 +0200 From: Polytropon <freebsd@edvax.de> To: malaizhichun@tom.com Cc: freebsd-questions@freebsd.org Subject: Re: freebsd should be rewritten based on microkernel architecture Message-ID: <20200417120035.477d1fc5.freebsd@edvax.de> In-Reply-To: <3f1496d1f598c84b3871b630f161256e152aca75.camel@tom.com> References: <3f1496d1f598c84b3871b630f161256e152aca75.camel@tom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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, ...
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20200417120035.477d1fc5.freebsd>