Thoughts on the underlying OS

The main point of this whole project seems to be offering a nice way for just about everybody to use a computer. I do not have any need for a polished desktop personally but I applaud visionary thinking and courage to try reaching for the stars! For that reason Hello is pretty appealing to me nevertheless.

What I'd like to point to are a few of FreeBSD's shortcomings. Don't get me wrong, this is not another "you should just use Linux instead!" topic. On the contrary; I'm using FreeBSD as the sole OS on my computers, I truly love it and I think that you made a good choice. But there are things that require work. Things that do not have any direct impact visible on shiny screenshots but can mean a lot to how the system feels as a whole. And no, I'm not talking about the splash screen feature being in a less than ideal state. It's things that go quite a bit deeper, more like - to the core.

FreeBSD has some weaknesses that show when it comes to the desktop. One thing is that multi-seat functionality is not available. While on Linux I can login with a different user without logging the other out, I can't do the same here. I'm a former team member of GhostBSD, had fun and learned quite a bit. But honesty demands also mentioning that the system is appealing more or less only to more technical people who know (!) what the advantages of FreeBSD are and are willing to accept the disadvantages for having them. If you are aiming for a general-purpose system for "mere mortals" there are some fields that would really require work - and ideally we should try to add more advantages over Linux to the list as well.

1. **Boot time and service reliability** are actually one problem that needs to be solved. FreeBSD doesn't take terribly long to boot but for people used to e.g. Linux (or Windows) it's an annoyance. A good part of that is the kernel taking much longer - and while there are FreeBSD committers who have done work in that area, there's probably a lot more to do. While on a pretty bare server system the userland part doesn't matter as much, the concept of Hello sounds like it's going to load quite a few helpers. Firing these up takes more time than it needs to due to FreeBSD's init system (rc.d) not doing parallel startups.

There has been initiatives to introduce OpenRC as an optional alternative, but it hasn't happened, yet. TrueOS (upon which GhostBSD is built these days) made the switch and as a result the desktop is ready quite a bit faster. It requires giving up things people have come to love (configuring services via rc.conf variables) but offers a couple of advantages over the old way. What it does not do however is provide reliable service management! To get that today still requires using venerable programs like daemontools. Solaris has SMF, Linux has Systemd (which merits a lot of critique but regarding service supervision it's definitely some form of progress!) - we're lacking behind here.

Recently there has been some interest in the s6 supervisor suite and the author of 66 (utils around s6 to make using it as init easier) has offered help if anybody was to seriously try getting it working properly on FreeBSD. Considering something like that would solve the problems of slow boot time and missing service reliability both for good _and_ elegantly.

2. **Not all base system components are ideal for a desktop system.** Do we need things like Sendmail? BSNMP? Svnlite, portsnap and the like (if FreeBSD's packages are not to be used in the long run)? And on the other hand: Wouldn't it make sense to include zsh in base? What about making the attempt to import Xorg (or OpenBSD's Xenocara as done by the Hyperbola guys) into base? A system like Hello would _never ever_ under _no circumstances_ want to break the GUI! But by keeping X and the actual OS separate this is much more likely (and it has happened to me before) than if X was part of the OS.

3. **Configuration is a mess on Unix-likes - and when it comes to the benefits of context-aware configuration, we're still living in the age of barbarism.** I can only point to the [book](https://github.com/ElektraInitiative/book) published by the Elektra initiative, chapter 0 alone has been a real eye-opener for me. We're wasting so much potential here by not designing our systems according to the results of that research. Hello is about things like auto-configuration? The Elektra principles could help a lot here.

These are just three points to start with. Other people do user-visible things way better than me, but if any of these (or other "under the hood" topics) would be of interest to the project I could probably contribute at least some research.