Hello everyone! This is my first post here on the FreeBSD forums. I am still learning FreeBSD and currently planning migrating to it as my platform and daily driver and am excited enough that I am even considering perhaps creating my own "distro" for it (i.e. in the sense of GhostBSD, etc; not a truly independent BSD OS) eventually, but I have been watching BSD and Linux and open source and FOSS more broadly for years and had a great idea yesterday that I want to share nonetheless, even though I am still a bit early since FreeBSD is not yet my daily driver (I am testing it thoroughly in VirtualBox and USB flash drive mostly first, for practical reasons).
The idea is actually quite simple really, but like many simple but prominently applicable things I think it could actually really disproportionately improve perceptions of FreeBSD and perhaps the other BSDs too if they did similarly, and all with very little effort, very few ripple effects, and very little maintenance burden! It comes from my long-term observations of the way people react and perceive the qualities of software in ways that they are often not really self-aware of, even in technical fields where we have the pretense of being not subject to such latent cognitive biases.
So that you understand my point more clearly before I give it, I will share a brief but very salient motivating example: I remember years ago in college in my capstone game development project we were grouped into teams and periodically gave presentations to the rest of the class about our progress and what we had done and showed demos of the state of the projects. One of the presentations my team gave has always stuck out though as being a fantastic illustration of human cognitive biases even in tech and science where we pretend to be less biased than we are. In particular, in the span of time between that presentation and the prior one we had actually only worked solely on a few fancy animated particle effects and a visually mesmerizing gyroscope portal-like object that superficially looked very impressive. After each presentation, the rest of the class was required to fill out surveys grading the state of our projects along several categories, including looks but also things like code quality and engineering and so on. Yet, even though the only thing we changed during that time interval was adding a few visually impressive special effects, the ratings we received skyrocketed across the board for everything... even though nothing but those visuals changed and the code quality and engineering (etc) were in fact entirely unchanged despite having received lower ratings before. This is essentially the "halo effect" as applied to software. It showed me beyond all doubt how incredibly influential aesthetics and perception of fluency are in sculpting how things are perceived.
Merely presenting something in the right way can cause a night and day difference in how it is perceived by almost anyone who sees it, even in people who think they are highly resistant to such things.
This brings me to my very simple and easy suggestion (yet still probably highly effective in terms of perception!) idea for improving FreeBSD's
During the
Look for example at OpenRC, which is perhaps the most aesthetically pleasing of the init boot messages I've seen of the init systems I've tested, just for one partial example, but instead make the new fancy FreeBSD
Tangentially, I am reminded of the old "defrag" program on Windows 9x systems, where the information was conveyed so compellingly that I would be partially mesmerized by it and multiple family members actually enjoyed periodically looking at the defragger GUI just to see it in action. That is the power of technical information conveyed with true love and care. Obviously a boot sequence is much different than a defrag program and indeed could be far better than the Windows 9x defrag example I tangentially mentioned just now, but I am trying to illustrate a broader point about perceptions of even the simplest things here and hence the immense undertapped potential for shifting perceptions of FreeBSD by polishing every slightest detail of the intialization and aesthetics of startup and of the whole system and how much it could drastically improve how average users view it while simultaneously causing almost no negative ripple effects in the functional parts of the system.
Basically, unlike switching to any other init system, the above proposal would have virtually no burdensome or unintended consequences except merely for the fact that two different versions of the
The
This also fits well with BSD philosophy of improving on what already exists instead of forcing unnecessary changes on things.
It also doesn't impede eventually switching to a new init if the project eventually wants to. It merely presents the existing
Having a new FreeBSD release that has this in addition to other better installer experiences (such as the upcoming FreeBSD 16 reputably) could go a long way to conveying that FreeBSD is fresh and alive to the FOSS community, all while breaking nothing at all and thereby also showing good pragmatic judgement and taste yet while still improving things and I think that may attract more people.
What are your thoughts? Personally, I think it'd be a big improvement if something like this was done!
PS: Other adjustments and improvements designed to ease the process of working with init (such as alternative command-line and/or TUI and/or GUI interfaces designed to look and feel like other init systems in terms of convenience but translating automatically but deterministically to the existing init system) could also potentially be made and performance could be optimized more without changing to a new init. However, I don't want to derail this thread by conflating those kinds of functional ideas with the purely aesthetic and informational suggestion I am making above in this thread and which could be done with (in contrast) little/no dependencies or ripple effects since this suggestion is just fancy text output and arbitrarily collected and presented info polished to be as pleasing and viscerally impressive as possible. Anyway, thanks for reading!
The idea is actually quite simple really, but like many simple but prominently applicable things I think it could actually really disproportionately improve perceptions of FreeBSD and perhaps the other BSDs too if they did similarly, and all with very little effort, very few ripple effects, and very little maintenance burden! It comes from my long-term observations of the way people react and perceive the qualities of software in ways that they are often not really self-aware of, even in technical fields where we have the pretense of being not subject to such latent cognitive biases.
So that you understand my point more clearly before I give it, I will share a brief but very salient motivating example: I remember years ago in college in my capstone game development project we were grouped into teams and periodically gave presentations to the rest of the class about our progress and what we had done and showed demos of the state of the projects. One of the presentations my team gave has always stuck out though as being a fantastic illustration of human cognitive biases even in tech and science where we pretend to be less biased than we are. In particular, in the span of time between that presentation and the prior one we had actually only worked solely on a few fancy animated particle effects and a visually mesmerizing gyroscope portal-like object that superficially looked very impressive. After each presentation, the rest of the class was required to fill out surveys grading the state of our projects along several categories, including looks but also things like code quality and engineering and so on. Yet, even though the only thing we changed during that time interval was adding a few visually impressive special effects, the ratings we received skyrocketed across the board for everything... even though nothing but those visuals changed and the code quality and engineering (etc) were in fact entirely unchanged despite having received lower ratings before. This is essentially the "halo effect" as applied to software. It showed me beyond all doubt how incredibly influential aesthetics and perception of fluency are in sculpting how things are perceived.
Merely presenting something in the right way can cause a night and day difference in how it is perceived by almost anyone who sees it, even in people who think they are highly resistant to such things.
This brings me to my very simple and easy suggestion (yet still probably highly effective in terms of perception!) idea for improving FreeBSD's
init and rc and boot situation:During the
init / rc bootup, generate two different streams of dmesg output (the text that is emited after the boot menu selection and before the system is fully active): (1) one which is identical to the existing output of the boot messages but not visible by default and instead just written into /var/run/dmesg.boot as usual and (2) another which is a highly refined and polished version of the same info (and perhaps more) but designed to be as aesthetically pleasing and as readable at a glance as possible, including things like ASCII or UTF-8 box line TUI art (much like already exists in the boot menu selection and hence will already feel natural and actually even more stylistically consistent with what already is presented during bootup for that reason!) and color coding for different types of info and section boxes and dividers and such and also write that much more fancy and formatted boot message info into a new file called /var/run/dmesg_fancy.boot (or similar). Also, I suggest adding to the root account's home directory a symbolic link /root/boot_messages.txt that points to /var/run/dmesg.boot and also another symbolic link /root/boot_messages_fancy.txt that links to /var/run/dmesg_fancy.boot so that admins immediately and intuitively can see where all the boot info went and can read it in a better environment where it is not zooming by so fast.Look for example at OpenRC, which is perhaps the most aesthetically pleasing of the init boot messages I've seen of the init systems I've tested, just for one partial example, but instead make the new fancy FreeBSD
dmesg version of it even more technically informative and even more beautiful and communicative and useful. Put lots of love into it and make it the most beautiful and useful sequence of boot messages of any BSD or Linux system ever, even though it is still using plain init and rc and such. Make it as viscerally impressive and pleasing to see and use and spot useful information in as possible, exuding professionalism and quality from every pore and treating it as a serious and essential part of the sytem instead of just aesthetically seeming like an afterthought of dry text spewed into the console haphazardly and tastelessly like it currently is. Make it the "red carpet experience" of boot info in the open source world; the "best of both worlds" of aesthetics and useful technical info.Tangentially, I am reminded of the old "defrag" program on Windows 9x systems, where the information was conveyed so compellingly that I would be partially mesmerized by it and multiple family members actually enjoyed periodically looking at the defragger GUI just to see it in action. That is the power of technical information conveyed with true love and care. Obviously a boot sequence is much different than a defrag program and indeed could be far better than the Windows 9x defrag example I tangentially mentioned just now, but I am trying to illustrate a broader point about perceptions of even the simplest things here and hence the immense undertapped potential for shifting perceptions of FreeBSD by polishing every slightest detail of the intialization and aesthetics of startup and of the whole system and how much it could drastically improve how average users view it while simultaneously causing almost no negative ripple effects in the functional parts of the system.
Basically, unlike switching to any other init system, the above proposal would have virtually no burdensome or unintended consequences except merely for the fact that two different versions of the
dmesg output would need to be maintained and a couple of new files would need created (which would be extremely unlikely to conflict with any existing systems in any substantive way). The
/var/run/dmesg.boot file should be kept in its plain format forever so that programs that read that file and depend on it can continue working unchanged and so that information can be gleaned without having to process extraneous text such as text line art and color coding noise and such. In contrast, the /var/run/dmesg_fancy.boot output of the new system should be allowed to change with no notice and completely freely (and thus no program should be designed to read it and depend on it) so that FreeBSD thereby can both sustain all existing programs with no changes yet will simultaneously gain the ability to arbitrarily improve the aesthetic perception of its init system. I have a feeling that doing this will actually massively improve perceptions of the old init system and that much of its bad perceptions originate from aesthetics and not as much on function as people think because most people are bad at seeing how their biases actually distort their feelings on such things, though there are of course still many opportunities for improvement inevitably.This also fits well with BSD philosophy of improving on what already exists instead of forcing unnecessary changes on things.
It also doesn't impede eventually switching to a new init if the project eventually wants to. It merely presents the existing
init and rc and boot system as pleasingly as possible.Having a new FreeBSD release that has this in addition to other better installer experiences (such as the upcoming FreeBSD 16 reputably) could go a long way to conveying that FreeBSD is fresh and alive to the FOSS community, all while breaking nothing at all and thereby also showing good pragmatic judgement and taste yet while still improving things and I think that may attract more people.
What are your thoughts? Personally, I think it'd be a big improvement if something like this was done!
PS: Other adjustments and improvements designed to ease the process of working with init (such as alternative command-line and/or TUI and/or GUI interfaces designed to look and feel like other init systems in terms of convenience but translating automatically but deterministically to the existing init system) could also potentially be made and performance could be optimized more without changing to a new init. However, I don't want to derail this thread by conflating those kinds of functional ideas with the purely aesthetic and informational suggestion I am making above in this thread and which could be done with (in contrast) little/no dependencies or ripple effects since this suggestion is just fancy text output and arbitrarily collected and presented info polished to be as pleasing and viscerally impressive as possible. Anyway, thanks for reading!
