Do you think these READABLE? I don't think so.
An example how colorized log is seen using misc/lv.
And in editors/leafpad.
An example how colorized log is seen using misc/lv.
And in editors/leafpad.
I don't see a particular problem there. If you really don't like it, there's no reason why you can't just use sed to add line breaks where you want them. Again, if you're trying to read that, then you probably have a reason for doing so that would dictate what parts to pay attention to. I'm not being obstinate here, but the sort of people that would be scared off by a lot of text aren't going to be reading that in the first place.
Maybe all those ^[[0;34 etc. may be considered less legible by some?
Dude! I'm getting a serious bro-crush on you for your description of the problem and solution above. Thank you! You come across as someone who hasn't been broken by the "agile philosophy" yet. Requirements? who needs those?
ESC sequences hurts the position of the error positiom marker "^".
The square means character code "001B" in hex, that is ESC code ("^[" in the first example).Also squares in the second screenshot don't relay exactly useful information, even considering T-Aoki writes (AFAIK) from Japan, so our idea what shape can communicate information and what not may differ significantly
I don't personally have any trouble reading that. I see that somebody was pressing buttons while the output was going and I see some missing fonts that really should be installed on the system.Maybe all those ^[[0;34 etc. may be considered less legible by some?
Also squares in the second screenshot don't relay exactly useful information, even considering T-Aoki writes (AFAIK) from Japan, so our idea what shape can communicate information and what not may differ significantly
Unfortunately, what OP wants wouldn't be able to implement as ports, as modifying rc* and rc.d/* in /etc by ports is basically NOT allowed.
alias ls='ls -G'
alias grep='grep --color=auto'set -g default-command "${SHELL}"Well said. As a lot of us ole-timers have pointed out, post processing to colorize and "make pretty" is fine, but leave the boot messages alone.
If "beauty" doesn't harm performance in any aspect, no reason to deny it.
Agreed, but I'm an old school silver halide black and white photograph type of person, so my idea of beauty is Ansel Adams not William Eggleston
Me, too.Agreed, but I'm an old school silver halide black and white photograph type of person, so my idea of beauty is Ansel Adams not William Eggleston
0x1b[31merror:0x1b[0m as "Red error alert" or "Error colon in red" or "turn charactor color to red, error colon, color restored", the person would hear "Escape code left large brace thirtyone merror colon escape code left large blace zero em". It shall NOT happen at all!That is an aspect I did not consider. But it is a very important one.
slurredlowercase device names are members of a specific category of device you could provide category headers to that same effect or parenthetical asides and other bits of contextual info and doing so could greatly improve the communicative qualities of those entries. Color coding and whitespace and tabular formats can be applied in myriad different ways that could likewise improve on both functional and aesthetic aspects of everything. There is truly an abundance of opportunity for polish. Use your imagination. systemd distros and most distros that use its largest init competitor OpenRC. Linux is also (of course) more popular for both most server uses and most desktop uses. Clearly then it doesn't cause Linux many problems though and certainly not enough to make it worth avoiding implementation of it for them.
So, code, without using LLM / AI (allow it or not would be still under discussion, so not using LLM / AI would be safer to be accepted).Neither of the above sentences is true.
(1) First impressions of an OS (or practically any software for that matter) will inevitably be heavily influenced by how the it is presented, with extra weight to anything that occurs early in the process of trying it, and taking a stance that is dismissive of the value or cost of accounting for all that (proactively vs neglectfully) seems like a very clear example of a lapse in imagination regarding the long-term consequences of such choices. Typically anything that decreases user adoption rates will also decrease future support for all other aspects of a software package. Plus, the fact that reformatting and colorization are among the most inert changes one could make and among the least likely to introduce harmful ripple effects, yet these things are being treated as a serious liability here remains an alarming "canary in the coal mine" for the project's chances of being able to see from an outsider's perspective to thereby sustain and enhance long-term momentum. Indeed, even if it were hard to implement in the existing codebase (and that seems overstated) then that would seem indicative of poor architectural structure in that respect and may be worth of refactoring.
(2) Code that doesn't exist can't do anything and thus can't provide any meaningful benefit to any human. Yet, the whole point of software is to be useful and/or interesting and/or entertaining. Less is not more, just as war is not peace. As popular as such sayings are, they are fundamentally and transparently fallacious and are in fact ungrounded rhetorical contortions of reality. Strangely though, the past decade or two in software been blighted by a highly destructive and logically fallacious trend of largely embracing blind minimalism with respect to the design of user interfaces, both functionally and aesthetically, thus reducing both utility and freedom, perhaps encouraged by the likes of Apple/Mac and by largely unjustified trends and assumptions in Silicon Valley, which has created a kind of "Orwellian minimalism" that has harmfully held software back for the past decade and seems responsible for much of why this once much more aesthetically and functionally diverse world of software design has in recent years become so bland and so routine and so devoid of human spirit, as one can see especially in trends like "flat design" and in "big tech" removing more and more freedoms from users with every passing year, and we are all the poorer for it. Indeed, even our human dignity and our ability to aspire to (or sometimes to even see) what wonders are possible has seemed in decline for years and I personally am extremely tired of the past decade or two's irrational march towards soul-crushingly uncreative and sterile user-hostile minimalism.
There is a high risk that such a mindset will maximize analysis paralysis and the committee effect and hence minimize productive outcomes. Expecting a fully settled debate also imposes an disproportionate burden, one tellingly not presumed of other parts of the system, thereby de facto silencing the idea under false pretenses of due consideration (a common political stratagem).
There's plenty of reason. The entire point of the idea (as I have reiterating in nearly every comment I've made, including the original post itself) is one of creating a very plausible path for improving the first impression that FreeBSD makes on outsiders in order to increase its rate of adoption, all while simultaneously also making it more functional, legible, and aesthetically pleasing.
No amount of saying that the system functions adequately (which is all well and good, of course), changes that. Indeed, it is largely irrelevant.
Like ships passing in the night, we're in a sense are not even having the same conversation. Perhaps that will help you understand why I am largely unmoved.
A true counterargument would have to credibly address that core center of gravity of the idea and I honestly don't see any comments in this thread that substantively do so. I think that's largely because on some level many of you realize that the idea likely would improve outsiders' 1st impressions and adoption rates at least moderately. Irrelevancies won't help you in that regard.
I also am of the belief that fundamentally all people (whether presently "technical people" or not) can be made to appreciate and be inspired by the technical aspects of a system if the system was presented throughout all aspects of itself in as friendly and as smooth and as polished a way as possible and that doing so could greatly improve the likely outcomes of the future for humanity as a whole regarding software. There is no conflict between ease and power. It seems clear as day to me that the Linux and Unix-likes' greatest mistake as a community is continuing to treat those two things (ease and power) as much more incompatible than those things actually are. This is (as a reminder) essentially the "false dichotomy" I have previously referred to a few times.
Not true. Text is not in itself scary to anyone. What scares people is anything that is perceived as incoherently intractable and riddled with unknowns, of which cryptic techno-babble in the boot sequence from a naive first impression standpoint is just one example. Every piece of information that has not been communicated clearly to someone thereafter becomes a liability of unknown and potentially boundless magnitude from that person's perspective, like yet another unaccounted for thing: a mine in a minefield of myriad unaccounted for risks to both one's time and one's purpose in trying to use something. The fact that we (as more technically inclined people currently) can see through much of this with sufficient (though often needlessly very large...) time investment doesn't change the reality for most prospective users nor does it obviate any of the immense lost opportunity caused by communicating things less well than what is possible.
The meaning of all aspects of the boot sequence's messages could be greatly clarified and reformatted and made more legible and expanded to include even more useful technical info.
For example, instead of leaving it implicit that certain shortslurredlowercasedevice names are members of a specific category of device you could provide category headers to that same effect or parenthetical asides and other bits of contextual info and doing so could greatly improve the communicative qualities of those entries. Color coding and whitespace and tabular formats can be applied in myriad different ways that could likewise improve on both functional and aesthetic aspects of everything. There is truly an abundance of opportunity for polish. Use your imagination.
Nope, that's not at all an accurate portrayal of what I prioritize, nor of what I am suggesting, nor even of my design philosophy and computing philosophy whatsoever.
Function and aesthetics are always intertwined with and inseparable from each other. Every choice about how information is conveyed is also an aesthetic choice, but many such choices are significantly better overall than others. Placing yellow text on a white background is a poor design choice in much the same sense that leaving boot sequence info needlessly cryptic and harder to read at a glance benefits no one (and in an properly engineered system designed from first principles could even be made to be free of other side effects through context awareness or through changes in how color or other formatting aspects are represented in tandem with the text, such as making it a separate data stream that doesn't muck up the text body at all).
The only place I've ever seen it being a volatile topic is in this thread, as far as I can recall. The vast majority of Linux distros now seem to now use colorized boot sequence information for legibility and aesthetic reasons, including mostsystemddistros and most distros that use its largest init competitorOpenRC. Linux is also (of course) more popular for both most server uses and most desktop uses. Clearly then it doesn't cause Linux many problems though and certainly not enough to make it worth avoiding implementation of it for them.
Luckily though, such surface-level and inert changes (with very few moving parts compared to most software) can be made without harming the most substantive aspects of any system. In those regards, FreeBSD could benefit greatly from improving its public image so that it no longer creates the unenviable impression of "probably barely maintained" that its current install and boot message sequence creates in many people who try FreeBSD out without taking the time to look more carefully. People have limited time and use proxies like that to make choices quickly.
It will be a big mistake in terms of lost opportunity and momentum to not start recognizing that more and to not start accounting for it much more vigorously I think.
Also, I want to reiterate again (as I have in multiple of my other comments) that my suggestion is not much motivated by vanity or superficiality, but rather by the very real impact that these kinds of changes could have in increasingly user adoption and in making the boot sequence more legible at a glance, among many other potential untapped benefits.
The potential upsides are huge and the potential downsides are small and likely to be easily mitigated (especially from a first principle standpoint that allows for refactoring the codebase and treats the presentation of FreeBSD for first impressions as a much higher priority than seems currently apparent).
Any formatting characters could be easily removed from any output through post processing, or by sending color data in a separate I/O stream from the text data in some way, among other possibilities.
Also, it is not clear to me that text-to-voice screen readers can even run during the boot message sequence at all!
Aren't the audio devices not even loaded yet until partway through? Wouldn't the text slip by too fast to even be read, unless the system slows the messages to a spoken reading speed? Is it even possible currently to read the boot messages by screen reader currently except after the boot up has finished and hence after other means of getting info become available and preferable?
It therefore seems to me that this is just a "grasping at straws" kind of point of rhetoric: essentially another way to try to engineer a rationalization for "why" the formatting couldn't be improved (when it obviously can be greatly improved, both functionally and artistically) and even though Linux already does such things as a standard across most distros now without much problems.
I honestly do not understand the magnitude of the resistance to the idea coming from some here.
It is one of the most inert ideas for how to improve things and has some of the least amount of moving parts that any software change could have. It is just formatted and marked up text... yet some here talk as if this is rocket science. Granted, I don't know FreeBSD's codebase, but honestly if adding color and reformatting the layout of the boot messages is rocket science currently then that is a sign that there is ripe potential for significantly refactoring the code for that part, both for the benefit of the idea itself and for the benefits that refactoring may bring in other structural respects.
I reiterate that I think that the aesthetics (and all other aspects of presentation) are likely among the foremost contributors to adoption rates (or the lack there of) of any OS and that there is almost no philosophical mistake you could probably make in terms of impact on the future of an OS project worse than continuing to treat such parts of the system like an afterthought or as something merely dry and negligible and to thereby act in ways that are likely highly disconnected from the psychology of a very large body of potential users and supporters (for both desktops and servers).
There is also the "chick and egg" and "dead sea effect" to consider. A large selection bias may be in play here, in that a small minority users who don't care about such aesthetics and adoption strategies are more likely to stick around here, but for this fact to therefore cause a disproportionate and misleading sense of what the full range of potential users of the system as a whole would actually want if they weren't deterred by such things at the outset from the impression it makes. In other words, there is a great deal of potential circularity in terms of the user base's preferences that I would advise any FreeBSD developers considering these matters to be wary of that bias. That also makes sense in light of the core team having new public initiatives that seem to disregard these forums' preferences against desktop-related polish and other critical modernization efforts, where the team seems (I guess) probably aware of the damage to adoption rates that many such long-unattended-to things are likely causing.
If FreeBSD had a larger user base it would also have much more chance of being able to produce more software that isn't just ported from Linux. This is a great irony in a sense, because it means that by trying to prevent FreeBSD's first impressions from becoming more appealing (by very falsely conflating that with becoming "more Linux-like" or with "becoming bloated", neither of which is in any way inherent to the suggested idea nor even hard to avoid) you will likely be further worsening the extent to which FreeBSD lacks the resources to do anything much more than just continue importing things from Linux. It is like a Chinese finger trap in a sense.
In contrast though, if the dev team were proactive on taking every conceivable thing that influences first impressions into account and polishing such things as much as possible then that is the best thing one could do to have the most plausible chance of increasing future support and hence expand the project's ability to make itself more distinct from Linux.
It would be hilarious if it weren't so sad and so frustrating.
I really wish there were more real (genuinely substantively different) options for operating systems. Do you not see how my suggestion, properly implemented, could help that?
Regardless though, I again thank you all kindly for taking the time to read my thoughts and for participating in any discussion here. Have an awesome day/night!
Deciding which OS to run based on the cosmetics of how it boots seems very strange to me. I agree that sometimes the boot process needs to be debugged or watched. Colorizing the dmesg output might help some in finding problems. But this is an extremely small part of how I interact with a computer. And when I do need to debug the boot process, this is usually done after the fact, by inspecting logs. The boot process and how easy it is to observe and fix is a tiny part of the OS choice.
Do you have RTC? I tried a dozen different things to a systemd timer and it'd either not run or run immediately on boot regardless of time.
But if the output has stuff in RED that flies by and you can't stop and scroll back all you've done is induced panic without resolution. And I have never chosen an operating system by how pleasing the boot messages look; I also don't believe the argument that "making the boot messages prettier is going to bring in a huge market share".
Yes, all my RPi now have a hardware RTC added to it. The ones that are using custom base-boards or hats have the chip and battery on there. For the others, you can get a little PC board (for a few dollars on Ebay, Amazon, Temu, ... or a few more dollars on Adafruit, Sparkfun ...) which attaches to the top left 5 pins, including power, ground, and the I2C connection.
At least seeing something red fly by has the advantage that you know there is SOME problem there and you should look. And on FreeBSD you can actually scroll back, by using the scroll lock and page up/down keys. I don't know whether that works once you start a GUI on the console.
I wouldn't be so harsh. The idea of colorizing dmesg output is not actually bad. It is just of very limited usefulness, and if implemented carelessly could have nasty side effects that break things (as was discussed above, having log files stuffed full of esc [ 1;34 m would be very bad). To do it right would require re-designing lots of existing code, which is completely out of the scope of one amateur programmer, and perhaps not really doable in the "bazaar" model of open source development.
* Warning water level low: 9888 gal
*** Alarm water level low: 9801 gal
E-mail and SMS sent to ralph@example.com and 321-555-1212
Alarm cleared, water level normal: 9876 gal
E-mail sent to ralph@example.comI accept that, but one has to be looking to see it.
Agreed. I typically do this after every reboot (which is basically every update)
This is the crux of it. Standards are good if you follow them but then "it's too much effort to follow them so I'll just do what I want". Every logging framework supports at least "error, warning, info, debug" so a specific log would get tagged with ERROR|WARNING|INFO|DEBUG but then a different framework may do Error|Warning|Info|Debug so post processing needs to account for that. I know me looking at a set of log files my brain gets wired for ERROR and misses Error|error.