An idea for improving init and rc seamlessly, without causing any conflicts or tedium for anyone

[RainCoder]

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 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!

 

[bvdw78]

Adding moving parts to a system for aesthetic reasons is not the most attractive proposal I've ever seen. Improvements are always welcome, but aesthetics aren't exactly a factor for a system that is more often than not managed remotely over SSH. GhostBSD and HelloSystem derive from FreeBSD and would probably be more welcoming to what you're proposing. As in: visual aesthetics are a part of their goals far more than they are of the FreeBSD project.

For me personally I'm fine with the current situation. I want my FreeBSD to work. Apart from my desktop environment (which isn't part of FreeBSD itself) I don't care how it looks. Most of the systems I run don't even have screens to begin with.

 

[freezr]

I am still trying to understand how this would make the init system better...

 

[bakul]

I am still learning FreeBSD

You might consider focusing on this for the time being. Understand it well, experience its pain points so that you are better informed and can explain clearly how a new method will improve things. Even better, build a prototype and present some benchmarks.

 

[tembun]

From my perspective, this may be a good idea to have this sort of program as a third party software (in ports(7)) (though I'm not sure if that will even be possible to easily integrate it directly into the boot process, but probably it would be feasible with rc.d(5)). But I personally will never like this functionality to be the part of the base system. To me, the main purpose of the boot logs to give an information about detected hardware and started services, and that's it. Granted, it's nice when it's formatted nicely and stuff, but as far as I'm concerned, it doesn't fit the FreeBSD philosophy (in sense, for this feature to be in the base). Moreover, I'd guess this would add an extra level of complexity to the rc(8) (or maybe even init(8)).

In other words, I would agree with the idea that perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away. It's absolutely OK to have nice, clean, fancy and human-readable boot logs, but this is a job of a third-party package. Don't get me wrong, I second your idea and I'd absolutely love to be able to have such fancy logs as an extension to the rc(8) system.

P.S. Welcome to the Forums

 

[T-Aoki]

FreeBSD supports serial console, so colorizing outputs could cause boots to slowing down (even if video console is fast enough, kernel / init and following rc scripts need to wait for output to serial console to finish) if serial console is enabled (not default, though).
And seemingly mangled outputs are often caused by mixing ups between stdout and stderr.

More, dmesg logs outputs from kernel space only (kernel and kmods).
Other messages from init and rc scripts goes to /var/log/messages and/or some others depending on configurations. Some may NOT be configured to be logged.

So the reasonable way would be to prepare GUI / TUI tool to analyze and reorder (if needed) / hide informations and let colorizations done by it on-the-fly.

 

[T-Aoki]

Some appendixes.
Boot time messages are categorized roughly in 3 parts.

The first is from loader (including boot codes), which are BEFORE kernel starts. These ara NOT logged unless logged by terminal emulators connected via serial console (need configuration for loader).

The second is from kernel, including kernel modules.
These are logged to /var/log/dmesg.today. But could partially lost if the buffer holding the messages overflowed (and rewritten from start address) before /var/log/ is ready to be written.

The last is from init and rc scripts. To which file the outputs are logged (or not at all logged) are depend on the configurations for each scripts.

In last 2 cases, errors are shown WHEN ERROR HAPPENED asynchronously.

And there were efforts for running rc scripts in pararrel, at least 2 times, and both are unfortunately abandoned. (The 2nd effort is done recently and abandoned for large reworks.)
Once this kind of pararrelization happenes, logs could be more complicated as of asynchronous writes.

 

[mer]

It merely presents the existing init and rc and boot system as pleasingly as possible.

Unfortunately this not a universal standard. It's the same thing as people that love output in a terminal to be colorized others do not.
Boot time messages go past rapidly, not easy to read or even pause/scroll lock. Then we have screen size: I personally hate it when the i915 kmod is loaded during bootup. Screen resolution switches to something that gets hard for my old eyes to read as things scroll. And Yes I know I can probably tweak that in config files.
Colorizing (say errors in red) as they scroll past leads to more panic especially when you need to scroll back to find out what it was.

I like the suggestion by tembun a third party tool that prettifies existing output without changing anything.
That lets the user control it instead of having something forced on them.

 

[SirDice]

I like the suggestion by tembun a third party tool that prettifies existing output without changing anything.

misc/colortail
deskutils/pipecolor
sysutils/colorize

 

[hedwards]

misc/colortail
deskutils/pipecolor
sysutils/colorize

That's more or less the route that I'd personally go. I remember decades ago discovering the -G flag for ls and then more or less promptly never using it again because it wasn't really worth the hassle of choosing colors that worked better for me.

That being said, when done well, and optional, colors can be nice. I've been messing around with podman and it's cool having containers where there is some color coding of the warnings in red and some of the lesser to other colors, but those are specifically for use over a modern SSH connection or in a modern terminal. Not an older style serial terminal that may not even have color as a possibility.

And this discussion just reminded me that grep has the --color=auto option to highlight any found strings. But, again, that's optional, nobody has to use it if they don't want to.

 

[mer]

because it wasn't really worth the hassle of choosing colors that worked better for me.

Thank you. My point, condensed. Some like term windows that are dark background with light text others the reverse. Colors that work on dark background often don't work on light background.
That's why I start with nothing and then maybe add/change based on my environment.

 

[hedwards]

Thank you. My point, condensed. Some like term windows that are dark background with light text others the reverse. Colors that work on dark background often don't work on light background.
That's why I start with nothing and then maybe add/change based on my environment.

It's also rather telling that while there are a bunch of aliases that are in the shell profile, I can't find any that colorize ls, not even commented out, which probably says something about how popular is, given how easy it would be to add 1 line for "alias lsg = `ls -G'.

 

[mer]

It's also rather telling that while there are a bunch of aliases that are in the shell profile, I can't find any that colorize ls, not even commented out, which probably says something about how popular is, given how easy it would be to add 1 line for "alias lsg = `ls -G'.

I've found a lot of the colorization happens "one level up". bash shell init stuff looking at value of $$TERM and automatically adding flags.

 

[RainCoder]

Thank you all for reading my post and sharing your thoughts.

The links to some color related software from SirDice are especially useful and appreciated.

I admit that I am rather surprised that so many people here apparently seem to prefer not making the boot sequence more aesthetically pleasing to create a potentially much better impression on new users, especially considering that making a symbolic link to the boot messages as /root/boot_messages.txt via /var/run/dmesg.boot or /var/log/dmesg.today (or any similar approach) makes it still easy (indeed arguably easier, since there is no automatic scrolling) to get the same info as before. The idea was specifically designed to minimize ripple effects as much as possible, relative to potential gains in terms of benefit per unit of effort in how FreeBSD may be perceived by prospective new users. I'm not sure what approach to the init situation could be any gentler, besides obvious things applicable to any software such as synchronous optimizations and small additions and tweaks in features and such of course.

The part about colors potentially causing problems for serial connections and some environments was something I was hoping would not be much of an issue, but it sounds like it could be. That makes me wonder though about how the already existing boot menu that shows the beastie logo is able to be colored without (I presume) such problems though. That seems inconsistent with the notion that colors and fancy output would cause problems. I also along similar lines wonder if there is a way to detect what kind of environment the boot sequence is happening in (seems like probably yes) and if it is an incompatible one then to not display any fancy messages. That would largely address the incompatibility problem for colors on constrained environments when booting.

It sounds like this might be something I'll have to implement myself if I do end up making my own "distro" based on FreeBSD, unless the consensus turns the other direction in this thread or elsewhere over time, though I am honestly surprised by that reaction given the potentially very large upside of doing this.

More users tends to bring more resources to all aspects of any operating system and boot output designed to be both as beautiful and as usefully informative as possible would likely be attractive to technical and non-technical users alike.

As for myself, I still new to serious use of FreeBSD, though I've played with it on and off while "distro hopping" and such over the past couple decades (and likewise for the other BSDs, especially NetBSD), and am still reading through Absolute FreeBSD (3rd edition) in fact, to round out my knowledge, but we'll see what happens. It would be good to have less of a monoculture in operating systems and FreeBSD seems like one of the best foundations for at least partially addressing that increasingly prevalent problem in the computing ecosystem. A more polished FreeBSD would help in that regard I think.

 

[bvdw78]

The point I was trying to make above wasn't to discourage you. It's much more that FreeBSD is a foundation that, in its current form, is far more often than not deployed in scenarios where the box doesn't even have a screen to begin with.. if there even is a physical box to speak of.

What you're describing makes sense in only a subset of use cases where FreeBSD could fit, and that would be desktops/laptops and others where a screen is a given. More power to you in these scenarios! Improvements to the desktop use cases for FreeBSD would benefit my own workstation and laptop so you've got a cheerleader here.

In the many use cases where a screen does not exist, however, your proposal must not cause any adverse effect whatsoever or you will get justifiable pushback. The risk to those use cases: adding moving parts increases complexity, increases maintenance burden, and increases the risk of breakage. If there is no return value on these items, people will say no. So while I'm personally not opposed to improvements like what you're proposing, the design of the feature must be crystal clear and not cause any "friction" at all to the use cases of the OS where it is not applicable.

 

[mer]

making the boot sequence more aesthetically pleasing

I think the bigger argument is the bolded words are subjective and very different for folk. As I tried to say based on your first post is "Your suggestions would make the boot messages less useful to me". That's why "leave it alone, use existing or other tools to pretty it up after boot"

 

[hruodr]

I admit that I am rather surprised that so many people here apparently seem to prefer not making the boot sequence more aesthetically pleasing to create a potentially much better impression on new users

My recommendation. If you do not like the boot messages, just do not look at them, or change to an operating system that hides them like Ubuntu, as soon as possible. You are new user and less dependent on FreeBSD, you can change easily.

By the way, new users should first learn.

 

[SirDice]

It's also rather telling that while there are a bunch of aliases that are in the shell profile, I can't find any that colorize ls, not even commented out, which probably says something about how popular is, given how easy it would be to add 1 line for "alias lsg = `ls -G'.

ls(1):

     -G      Enable colorized output.  This option is equivalent to defining
             CLICOLOR or COLORTERM in the environment and setting
             --color=auto.  (See below.)  This functionality can be compiled
             out by removing the definition of COLORLS.  This option is not
             defined in IEEE Std 1003.1-2008 (“POSIX.1”).

     CLICOLOR        Use ANSI color sequences to distinguish file types.  See
                     LSCOLORS below.  In addition to the file types mentioned
                     in the -F option some extra attributes (setuid bit set,
                     etc.) are also displayed.  The colorization is dependent
                     on a terminal type with the proper termcap(5)
                     capabilities.  The default “cons25” console has the
                     proper capabilities, but to display the colors in an
                     xterm(1) (ports/x11/xterm), for example, the TERM
                     variable must be set to “xterm-color”.  Other terminal
                     types may require similar adjustments.  Colorization is
                     silently disabled if the output is not directed to a
                     terminal unless the CLICOLOR_FORCE variable is defined or
                     --color is set to “always”.

No need for an alias.

setenv CLICOLOR # for C shells
export CLICOLOR= # for the Bourne shells.

Try it, env CLICOLOR= ls vs. ls

 

[sko]

I am rather surprised that so many people here apparently seem to prefer not making the boot sequence more aesthetically pleasing

Because it is unnecessary bloat that brings zero benefits - on the contrary, it only complicates things.
FreeBSD is first and foremost a proper server OS for professional users who rather have proper, meaningful diagnostic messages that will help in debugging a failed host and can be read even over a serial console. The last thing anyone wants if things went south so far you had to revert to a serial console, is being prompted with useless crap and having to first dig through "astheatically pleasing" garbage to unveil the actual information you need.

If you want useless bling instead of proper diagnostic messages, use one of the proposed ports or change to an OS that hides everything from you, like ubuntu or windows.

 

[T-Aoki]

I think the bigger argument is the bolded words are subjective and very different for folk. As I tried to say based on your first post is "Your suggestions would make the boot messages less useful to me". That's why "leave it alone, use existing or other tools to pretty it up after boot"

And as already noted by bvdw78, FreeBSD is a base OS for many different use-cases, including IoT having no screen and KIOSK terminals including game consoles like PlayStation 3 to 5.

I don't have any, but PlayStation 5 wouldn't show boot messages at all.
And NETFLIX subscribers wouldn't see any when connecting to their services.

That's it.

And for aesthetic use-cases, as already noted by bvdw78 on comment #2, GhostBSD uses FreeBSD as their base OS and focusing on use-cases directly used by end users.

 

[hardworkingnewbie]

Add this to /boot/loader.conf:

splash_bmp_load="YES"

bitmap_load="YES"

bitmap_name="/boot/logo.bmp"

boot_mute="YES"

Done.

 

[MG]

A little improvement would be preventing that the kernel puts hardware detection output over the curses installer program without even cursor positioning or a redraw screen option. Probably security-related like no program may see what's already on screen before user-level but I don't think this is really necessary. It does look chaotic and poorly managed, though.

 

[freezr]

So the point is to beautify the output during the boot to highlight potential errors, I agree that is good but not essential with a serious caveat, for people with impaired vision adding colors or bold to unicode text means getting a lot of weird characters wrapping words that can make them hard to understand...

 

[RainCoder]

Thanks again to everyone for sharing additional thoughts, etc.

I'm not sure how some people got the idea that I would ever want any of the the technical information from booting up hidden. I am actually suggesting (and strongly prefer) the opposite: both tastefully and thoughtfully increase the amount of technical info being effectively communicated and format it in a way that is both easier to read at a glance in useful ways and more aesthetically pleasing. That would make it both more useful and more impressive to prospective users. More useful details could be communicated and what is already there could also be (in many cases) more usefully explained and delineated and contextualized. I do not like systems that hide technical info and thereby foster ignorance and disempowerment. Systems that show technical info and offer more user freedom in contrast inherently will tend to increase broaden the horizons of all users by stoking interest in and awareness of such things. I am talking about embracing technical info and just conveying it better.

As such, I wouldn't want to move to Ubuntu or Windows, especially since I am moving away from Windows specifically because of its increasing lack of freedom and abundance of spyware, etc. Windows has rapidly become a highly untrustworthy platform and the last time I truly respected it was Windows 7 (Windows 10 has been "grit-my-teeth tolerable", except that the fuzzy start menu search is usually nice, but what I've learned of Windows 11 makes it utterly unacceptable). The Ubuntu and Fedora distro families are also among the Linux distros I am most avoiding since they are the most likely to be user-hostile and to possibly insert AI training spyware bots in their systems in the near future. I would rather use Debian, Arch, Void, Gentoo, Nix, or Guix if I used Linux. Void is more BSD-like than most Linux distros, and was even created by an ex-NetBSD dev from what I've heard. Hyperbola is also another prospective Linux distro (and are working on HyperbolaBSD) and is strongly anti-AI and hence more trustworthy than corporate distros like Ubuntu and Fedora, both of which have recently insinuated that they may add AI bots into their distros by default soon, hence making them now huge liabilities to use from an intellectual property protection and privacy standpoint.

I honestly don't understand why Linux and BSD and Unix users so often seem to presume that systems can't provide both easy aesthetically pleasant interfaces and simultaneously be just as easy to precisely control from command line interface and on restricted and resource-limited platforms as before. In fact, I would go so far as to say that this mentality is the #1 thing holding back Unix-like systems in terms of market share. It is extremely much a false dichotomy. There is nothing about making things easier that is in any way inherently incompatible with also making them more technically capable. Detecting the environment would also make pretty much any user experience idea adaptable to context and there is also nothing stopping the system from providing options on how the user wants it set up to behave.

Indeed, rigorously speaking, it is even possible that if an operating system had been designed with it in mind from the beginning (e.g. by providing an API for it) that every single command in the system could always have a corresponding optional GUI for filling it out (with little/no additional effort since the API could reuse the provided info about each command (like a built in manual and system relationship spec) both for the command line interface and a GUI) that would reduce cognitive overhead and could be run as a lightweight script using a shared GUI library (like Tcl/Tk scripts for example) and would simultaneously increase the command line interface quality too and that would have made the whole Unix-like ecosystem far more appealing to average users and we could even already be living in a world where most desktop users use it in that case perhaps.

Never underestimate the power of conveying things pleasingly, both for technical and non-technical users.

The point about the psychology of it is also of paramount importance. It reminds me of the old saying that if someone had asked Ford what they wanted for transportation they would have asked for faster horses, but then once they actually saw and used cars then that whole mentality immediately went out the window. I feel like many people here are analogously telling me they don't want cars and just want their horses to go faster. It is a case of not knowing what you don't know, frankly. And before someone says the obvious thought-terminating and easy to say but substantively empty jab of pointing out that I am still learning parts of FreeBSD (as if that somehow gave you any grounds whatsoever to dismiss the actual substance of the matter pre-emptively... which is essentially largely just an "old boys club" mentality): being new to serious use of FreeBSD is far from being new to the broader software ecosystem, nor does it in any way make one not able to think rigorously nor frankly just to even see with one's own eyes and to think with one's own mind from first principles and to be willing to say "the emperor has no clothes" and such. Even putting aside that I am in fact a lifelong programmer and already experienced with many things in the related ecosystem, newcomers to anything also often see the first principles based reality of things much more clearly because the "Curse of Knowledge" bias and fluency bias have not yet set in and thus one is often more able to see issues of user experience and communication gaps much more clearly. The status quo is rarely ever the pinnacle of how things should be and lack of respect for user experience is largely how the BSDs have lost so much ground to Linux. Don't you not want the BSDs to lose even more ground over time? If enough momentum is not sustained in terms of new users then all of the work of the BSDs could fade into a footnote of history, which would be a big loss, so I continue to be in dismay at this reaction to what is the gentlest possible approach to improving public perception of FreeBSD's init system that I could ever imagine.

I love the freedom of the various Unix-like operating systems and the many things they provide, but one greatly clarifying thing about being a past user of Windows when it was still good (e.g. Windows 9x era) and also of the golden era of desktop environments such as embodied by things like Trinity Desktop Environment (TDE) in Linux, and using various other highly freeform yet still simultaneously technically friendly interfaces, and having a broad capacity for imaging what else is also possible, is that I know as much and as viscerally as I know that the sun rises every day that the potential (both for ease/beauty and technical use cases) for conveying information and user interfaces better is immense and if you actually used a system like what I have in mind in a desktop/workstation/etc context and imagined the full range of how much better it could be instead of having status quo tunnel vision then you likely would just take it for granted and wouldn't ever want it to be gone. Outside of restrictive environments and dealing with conceivable obstacles to proper implementation, there is virtually no downside to what I am suggesting in all honesty. The points about aesthetics being "subjective", for example, are just as applicable to what the current system is as to any new system, but effortfully improving it inevitably has a "sky is the limit" potential for making it work better and be communicated more clearly and effectively for all uses, both technical and non-technical. I implore you to not be caught by false dichotomies.

For systems without any monitor/screen then the output would of course just be best disabled, but I would think that probably either already happens on such systems already or could be made to do so, so that therefore strikes me as essentially irrelevant to considerations of whether or not it is worth doing. The idea obviously only applies on screens anyway, just like is already true of the existing boot messages, and of course one would only want colors applied on systems that support color. There's also the fact that even without color the format and information conveyed could be greatly improved regardless of color. The arguments seem like non-sequiturs. It is like saying that because the crowbar side of a hammer isn't always in use that it shouldn't be included at all. Nothing about having more well-conveyed and impressive information for display available has any inherent reason at all to inhibit any system that doesn't use or need that system, etc.

The irony is that protecting the status quo so unilaterally to protect what you know and love is probably precisely the thing doing the most to undermine its long-term future and survivability.

This is of course just one idea among countless possible ones, but these kinds of things have long struck me as a "canary in the coal mine" for the evolution of open source communities.

Human freedom is currently being greatly endangered by recent trends in tech and we need for there to be more popular genuine alternatives to Windows, Mac, and Linux.

We can't achieve that kind of critical mass to protect the future of our society if even the simplest of ideas for improvement are dismissed so out of hand all the time.

I respect you all and your opinions and experience greatly, but I am here to build a better future for both myself and others and that requires change and the willingness to see things from first principles and rigorously grabbing reality by the horns.

No amount of people telling me that the emperor is wearing the best and most regal clothes will ever convince me to stop seeing with my own eyes and thinking with my own mind.

 

[kent_dorfman766]

As I read the monsterous OP my blood pressure started boiling: another who wants to convert a professional expert system OS into consumer drivvel...so after reading all the responses I'm somewhat calmed by those who are attempting to talk OP off the ledge, so to speak.

I'm reminded of working at a company I affectionately called "spam cannon dot com" back in the 90s. we had several different flavors of UNIX and the uninitiated attempted to make the init systems across all the diverse platforms look alike (what could possibly go wrong there?). Even their golden haired so called expert thought it was a good idea. I think I quit after about four months of the stupidity.