helloSystem / hello

Desktop system for creators with a focus on simplicity, elegance, and usability. Based on FreeBSD. Less, but better!
2.31k stars 57 forks source link

Thoughts on the underlying OS #37

Open kraileth opened 4 years ago

kraileth commented 4 years ago

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.

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

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

grahamperrin commented 3 years ago

http://www.daemonspawn.org/2016/01/a-comparison-of-alternatives-to-init8.html helped me to remember the name, now I see it was mentioned above by @kraileth:

The nosh package

Bookmarked in 2015, referred from https://forums.pcbsd.org/thread-20225.html (no longer available). Also featured in a FreeBSD quarterly status report, https://www.freebsd.org/status/report-2015-10-2015-12.html#The-nosh-Project. Obscure historic mentions of nosh: https://web.archive.org/web/20201231033053/https://jdebp.eu./about-the-site.html#ThirdParty

I have no idea whether it's suitable, it's simply something that caught my attention a few years ago.

Daasin commented 3 years ago

Hi all, relatively new to all this and more of a "mere mortal" as reference earlier lol 😅 But I was wondering about why not based on Open/PureDarwin could be aided by the work done on GNU-Darwin & of Darwin-Ports (aka MacPorts)

Was it because of licensing not being able to work? Or something else? I mean sure it's not the biggest group of community projects to draw on but can't be called non-existent neither and this could be bringing it back to life or a passing of the torch as the code finds new uses 🚀❤️

Also if not going to be done, how difficult would it be for someone else even one who knows nothing about anything to rebase the stuff here from FreeBSD to the PureDarwin base? I know it's not completely compatible and needs ports but surely not the same as trying to make an equivalent of ReactOS but with XNU instead of NT or trying to port from Linux or something, right? 😕

EDIT: 20/10/2021 May have been barebones in the past but has a good base to take over from now and could be worth considering again to see if maybe it's not still a waste of time? 🤔

grahamperrin commented 3 years ago

… why not based on Open/PureDarwin could be aided by the work done on GNU-Darwin & of Darwin-Ports (aka MacPorts) …

Does earlier commentary help to put this in context? In particular, https://github.com/helloSystem/hello/issues/37#issuecomment-728340185 respectfully

… advised me that rather wasting my time with Darwin I should better hack on FreeBSD). …

davidchisnall commented 3 years ago

In particular, sound on Darwin is implemented in CoreAudio, which is not open source. If you want to build a desktop OS on top of Darwin and you are not Apple then you need to write a new audio stack from scratch (or try to port the FreeBSD one) just to be able to go 'beep'.

Daasin commented 3 years ago

I am genuinely really sorry if this counts as 'necroing a dead thread'

but is it okay if we request this topic to be put in "Discussions" aswell? Or have a tag added to allow it to show up there? 🤔

9gay commented 2 years ago

@joelewing openbsd and dragonflybsd are about research and the needs of their own developers, so they don't have stable kernel ABI, so sooner or later (in case of openbsd - each release, so every 6 months) existing app bundles will break only because kernel ABI has incompatible change, so the only options for regular desktop users are freebsd and netbsd, but netbsd doesn't have proprietary nvidia drivers, instead they use nouveau, plus netbsd's GPU support is lagging behind freebsd (latest netbsd release uses drivers from linux 4.x (4.9? 4.14? can't remember) while latest netbsd snapshot uses linux 5.6 drivers which are gonna be shipped with netbsd 10.0), so freebsd suits more desktop users than netbsd because they have a huge difference in amount of resources

9gay commented 2 years ago

speaking of parallel init and service supervision, how about runit? seems to be a simple solution