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

freezr said:
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...
Click to expand...
My bad, completely forgot with this aspect!
So to comply with both requirements, text reader that completely ignore escape sequences and control characters (other than some specific ones like bell or [for use as delimiter] cr / lf) would be needed.

Off topic, but successor for Unicode that has structures such as supports for "how it should be read as" per character appearing in texts (in Japanese, called ルビ or ふりがな) should be standardized and forced to replace all existing character sets (keeping for compatibility features) would be strongly wanted.
This should help people with impaired vision a lot, with the costs of extended sizes, especially for CJK character sets regions.
 
RainCoder said:
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.
Click to expand...
Honestly, aesthetics isn't much of a concern for an OS which doesn't ship with a GUI by default. Also, booting tends to be pretty fast and infrequent enough that it's a non-issue. It's been a while, but I thought that it used to be possible to hide the text behind an image the way that Windows does, but it's just not there long enough to worry about.

Distro hopping is really a Linux thing because Linux distros tend to install a lot of random software that isn't strictly needed, but requires an entire distro. It seems to work for people, but if I want a different WM on FreeBSD, I can just uninstall the one I've got and install a new one, no need to switch to NetBSD to do that.
 
My friend: moving parts. They break. You introduce them at your peril, not mine. I like my teams' nights uninterrupted. And yes, I will die on this hill in a far more literal sense than you're prepared to imagine.

That's the frame you get to propose your improvement in. So please do proceed, but tread carefully.
 
Thanks again (as always) to everyone for sharing additional thoughts and for any time spent reading my thread, etc.

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.
Click to expand...

I can understand where you are coming from and strongly relate to it, having myself also witnessed quite a few software packages be ruined by attempts to redesign them, especially with regards to recent trends towards very crippled "minimalist" user interfaces that offer very little user freedom and embody little respect for users and have awkward and wasteful use of space and break many things that previously worked, etc. I too detest such things, and doubly so when it happens to something that I like and use. I would never want any such harm to come to any BSD.

None of that kind of destructive and ill-considered approach to changing things is even remotely along the same lines as what I am advocating for or would ever even want though.

In fact, I have gone to such great length in each of my posts specifically to try to ward off precisely that kind of misinterpretation of the intent. That's why I've spent so much of my time now (literally hours on this post and my comments now) trying to convey the point that easy to use and easy to understand GUI/TUI/etc systems are in no way incompatible with simultaneously high quality CLI systems and indeed in principle there is no reason why it even has to waste much or even any active resources if one permits the systems to simply be easily reconfigured with just slight effort by essentially checking which systems you want or don't and adding or removing and/or loading and unloading them as desired. There is zero inherent incompatibility between ease of use and advanced expressive commands for precise control in any operating system. The fact that the dichotomy of that may seem to apply seems to me to be nothing but coincidences of history. There is no reason why it couldn't be different and why both systems can't be simultaneously very expressive and very easy and thereby create the best of both worlds for the benefit of all.

Granted, in the recent couple decades there have been multiple examples of redesigns to things harmfully steamrolling over important things without regard to consequence and the nuances of what existing users like and benefit from. That is why I have multiple times said that I want to leave all existing information intact (both in the current and proposed "fancy" version) and add additional well-communicated context and organization and ease of viewing at a glance and other bits of useful info and so on, all pleasingly presented to create a better impression.

The foremost guiding principle of the suggestion I made from the first moment I thought of it, and up to and including every single word I've typed about it here, has been specifically to protect the existing systems and workflows from being unjustly removed from existing users and replaced by systemd or similar alternatives down the line based on reasons that are potentially more rooted in the biasing influence of aesthetics and how that is perceived by the public than by objectivity. Perhaps a new init would still be good at some point, but giving the existing init a new look and feel would reduce the potential for throwing it out at some later date just for reasons of the psychology of the "halo effect" of visual presentation style.

As such, I don't understand why you not only don't seem to like the idea (given it is one of the most likely ideas to protect what you already like about the existing system...) but are now by your own admission enraged at me ("blood pressure [...] boiling") when I have come here entirely with the wholesome intention to express my admiration for FreeBSD and its potential and to suggest an idea whose foremost guiding principle is literally to leave as little about the system unchanged as possible, but to just enhance its public image to draw in more support and users.

It seems more than a bit uncalled for considering that my intent is entirely constructive and I have done nothing but express interest and passion for a potential improvement to FreeBSD, etc.

Distro hopping is really a Linux thing because Linux distros tend to install a lot of random software that isn't strictly needed, but requires an entire distro. It seems to work for people, but if I want a different WM on FreeBSD, I can just uninstall the one I've got and install a new one, no need to switch to NetBSD to do that.
Click to expand...

Yes, I know, but "distro hopping" is the only common term I know of for trying out a bunch of different operating system installer images to test the waters.

Is there a better term for it, such as one applicable to the BSDs or to all operating systems more broadly? I don't deny that "distro" is largely a Linux term, but it is still closest to the idea. If there is a better term though then please tell me and I'll try to use it.

Also, I too tend to customize my environment by installing the desktop environment and/or window manager packages I want from command line these days, for better control. I am well aware of that and I want to emphasize again that there is a lot of false dichotomy in presuming that ease of use and advanced command line control are incompatible in any way. I am currently using FVWM3 and XFE as my visual interface on FreeBSD, incidentally, in case you are curious, though I still prefer to run startx manually instead of having it auto-run.

Along those lines, I have for many years noticed a pattern where in Linux and Unix-like environments any time there is any indirect hint at all that I may be some kind of mere GUI user that suddenly people start talking down to me (and to other people in similar situations) despite knowing almost nothing about me in real life and often assuming quite wrongly. That ties in as another example to my point that as a community the biggest factor that holds back Linux and Unix-like communities is (in my opinion) this kind of falsely dichotomous thinking about ease vs power. I literally have the login manager disabled on my FreeBSD install. Does that sound like the choice of someone who doesn't understand the value of command lines interfaces?

I will die on this hill in a far more literal sense than you're prepared to imagine.

That's the frame you get to propose your improvement in. So please do proceed, but tread carefully.
Click to expand...

So... am I correct in understanding that as a consequence of me coming here expressing high praise for FreeBSD and taking hours out of my life to enthusastically suggest an idea for it (one specifically intended to minimize ripple effects of harm to all existing FreeBSD users as much as possible by being a surface-level change to merely what text characters and colors are displayed, in a system that already appears to support colors and line art characters in the boot menu... regardless of the fact that I haven't touched the relevant code) that it is therefore fitting to issue a death threat against me, or at least as far as I can tell it is an implicit death threat as best I can interpret your words.

This also in a context where just a few messages ago I thought you said you were cheering me on (or was that someone else?), and all I have done since then is further try to explain my perspective on why I think it is a good idea that could draw in more support for FreeBSD conceivably, especially if both the installer and boot messages looked more inviting, in a context where if you actually ask outsiders to try FreeBSD then one of the first things that happens is they instantly assume that since the installer and boot messages look so old and have been so unchanged for decades that the OS is possibly not being updated much (incorrect as that assumption may be, since FreeBSD seems to actually be great and very active, etc). Therefore, a death threat against me is apparently merited for pointing that out and for trying to argue in favor of a way to improve upon the situation with what seems the path of least resistance. Is that correct?

Oh, right, but I guess I am the one out of line and rude for suggesting superficial text art and color changes, compared to one person who says this makes their "blood boil" and another who implies a death threat at the notion of me continuing to argue my point or to express my feelings on the matter, feelings largely motivated by my desire to protect the future freedom of humanity by doing what I can to try to increase the odds that OS lock-in won't result in large scale violations of human rights in the future...

As I said though, I appreciate all of the time and efforts anyone has made responding to me here and also the opportunity that FreeBSD provides to protect my freedom (and to possibly serve as a base to build on for my own and/or other people's use depending on what happens), but I would appreciate it if future comments in this thread were more civil.

I will pass on reporting these two comments to the forum moderators (and/or the police, in the case of the implicit death threat one) this time though.


As before and as of every moment I have participated in this forum so far my intention remains the same: simply to make a wholesome and constructive effort to do what I can to find and/or create a computing environment where both the user experience and the functionality is as good as possible and where one's human rights and property and privacy are respected. I do not understand why such good-natured intentions and such mild-as-possible (as far as I can perceive them) suggestions should ever merit any kind of inflammatory response.

How these kinds of things pan out could ultimately make the difference between whether humanity veers towards a tech dystopia or not. Freedom in technology is essential to the future.

In any case though, putting all such things aside, as always, I am wishing you all (and all of humanity) a wonderful day/night and I hope for a brighter future for us all.
 
May I remind you that good ole syscons(4) colorizes the output at boot‑time. (I actually wonder where the programmatic origins are, it’s not in the rc scripts.)

I think the output could use some formatting – like paragraph breaks (empty lines), tabular alignment, or wrapping lines at logical breaks (space characters) – to become more legible.

Advantage: it’s backward compatible (no Unicode characters, no spinning wheel animation or the like), no separate files as suggested in the opening post, and it can be implemented bit by bit.​
Code: 
---<<BOOT>>---
Copyright (c) 1992-2019 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
	The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 13.0-CURRENT #0 r353709: Fri Oct 18 05:49:35 UTC 2019
    root@releng1.nyi.freebsd.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64
FreeBSD clang version 9.0.0 (tags/RELEASE_900/final 372316) (based on LLVM 9.0.0)

WARNING: WITNESS option enabled, expect reduced performance.

VT(efifb):                 resolution 1366x768
CPU: Intel(R) Core(TM) i5-8265U CPU @ 1.60GHz (1800.11-MHz K8-class CPU)
  Origin="GenuineIntel"  Id=0x806ec  Family=0x6  Model=0x8e  Stepping=12
  Features=0xbfebfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE>
  Features2=0x7ffafbbf<SSE3,PCLMULQDQ,DTES64,MON,DS_CPL,VMX,EST,TM2,SSSE3,SDBG,FMA,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,TSCDLT,AESNI,XSAVE,OSXSAVE,AVX,F16C,RDRAND>
  AMD Features=0x2c100800<SYSCALL,NX,Page1GB,RDTSCP,LM>
  AMD Features2=0x121<LAHF,ABM,Prefetch>
  Structured Extended Features=0x29c67af<FSGSBASE,TSCADJ,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,NFPUSG,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PROCTRACE>
  Structured Extended Features3=0xbc000400<MD_CLEAR,IBPB,STIBP,L1DFL,ARCH_CAP,SSBD>
  XSAVE Features=0xf<XSAVEOPT,XSAVEC,XINUSE,XSAVES>
  IA32_ARCH_CAPS=0x2b<RDCL_NO,IBRS_ALL,SKIP_L1DFL_VME>
  VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID
  TSC: P-state invariant, performance statistics
real memory  = 34359738368 (32768 MB)
avail memory = 33139593216 (31604 MB)
Event timer "LAPIC" quality 600
ACPI APIC Table:           <LENOVO TP-R0Y  >
FreeBSD/SMP:               Multiprocessor System Detected: 8 CPUs
FreeBSD/SMP:               1 package(s) x 4 core(s) x 2 hardware threads
random:                    registering fast source Intel Secure Key RNG
random:                    fast provider: "Intel Secure Key RNG"

arc4random: WARNING: initial seeding bypassed the cryptographic random device
because it was not yet seeded and the knob 'bypass_before_seeding' was enabled.

ioapic0 <Version 2.0> irqs 0-119
Launching APs:             1 7 4 3 2 5 6
Timecounter "TSC" frequency 1800107885 Hz quality 1000
random:                    entropy device external interface

kbd1 at kbdmux0
000.000050 [4335] netmap_init               netmap: loaded module
module_register_init:      MOD_LOAD (vesa, 0xffffffff8105a240, 0) error 19
[ath_hal] loaded
nexus0
efirtc0:                   <EFI Realtime Clock>
efirtc0:                   registered as a time-of-day clock,
                           resolution 1.000000s
cryptosoft0:               <software crypto>
acpi0:                     <LENOVO TP-R0Y>
acpi_ec0:                  <Embedded Controller: GPE 0x20, ECDT>
                           port 0x62,0x66 on acpi0
acpi0:                     Power Button (fixed)
cpu0:                      <ACPI CPU> on acpi0
hpet0:                     <High Precision Event Timer>
                           iomem 0xfed00000-0xfed003ff on acpi0
Timecounter "HPET" frequency 24000000 Hz quality 950
Event timer "HPET" frequency 24000000 Hz quality 550
atrtc0:                    <AT realtime clock>
                           port 0x70-0x77 irq 8 on acpi0
atrtc0:                    Warning: Couldn't map I/O.
atrtc0:                    registered as a time-of-day clock,
                           resolution 1.000000s
Event timer "RTC" frequency 32768 Hz quality 0
attimer0:                  <AT timer>
                           port 0x40-0x43,0x50-0x53 irq 0 on acpi0
Timecounter "i8254" frequency 1193182 Hz quality 0
Event timer "i8254" frequency 1193182 Hz quality 100
Timecounter "ACPI-fast" frequency 3579545 Hz quality 900
acpi_timer0:               <24-bit timer at 3.579545MHz>
                           port 0x1808-0x180b on acpi0
pcib0:                     <ACPI Host-PCI bridge>
                           port 0xcf8-0xcff on acpi0
pci0:                      <ACPI PCI bus> on pcib0
vgapci0:                   <VGA-compatible display>
                           port 0x3000-0x303f
                           mem 0xa0000000-0xa0ffffff,0x90000000-0x9fffffff
                           at device 2.0 on pci0
vgapci0:                   Boot video device
xhci0:                     <XHCI (generic) USB 3.0 controller>
                           mem 0xa1400000-0xa140ffff
                           at device 20.0 on pci0
xhci0:                     32 bytes context size, 64-bit DMA

usbus0 on xhci0
usbus0:                    5.0Gbps Super Speed USB v3.0
pci0:                      <memory, RAM>
                           at device 20.2 (no driver attached)
pci0:                      <simple comms>
                           at device 22.0 (no driver attached)
ahci0:                     <AHCI SATA controller>
                           port 0x3080-0x3087,0x3088-0x308b,0x3060-0x307f
                           mem 0xa141e000-0xa141ffff,0xa1428000-0xa14280ff,0xa1427000-0xa14277ff
                           at device 23.0 on pci0
ahci0:                     AHCI v1.31 with 2 6Gbps ports,
                           Port Multiplier not supported
ahcich1:                   <AHCI channel>
                           at channel 1 on ahci0
ahcich2:                   <AHCI channel>
                           at channel 2 on ahci0
pcib1:                     <ACPI PCI-PCI bridge>
                           at device 28.0 on pci0
pci1:                      <ACPI PCI bus>
                           on pcib1
sdhci_pci0:                <Generic SD HCI>
                           mem 0xa1301000-0xa1301fff,0xa1300000-0xa13007ff
                           at device 0.0 on pci1
sdhci_pci0:                1 slot(s) allocated
pcib2:                     <ACPI PCI-PCI bridge>
                           at device 29.0 on pci0
pci2:                      <ACPI PCI bus>
                           on pcib2
re0:                       <RealTek 8168/8111
                            B/C/CP/D/DP/E/F/G PCIe Gigabit Ethernet>
                           port 0x2000-0x20ff
                           mem 0xa1204000-0xa1204fff,0xa1200000-0xa1203fff
                           at device 0.0
                           on pci2
re0:                       Using 1 MSI-X message
re0:                       ASPM disabled
re0:                       Chip rev. 0x50800000
re0:                       MAC rev. 0x00100000
miibus0:                   <MII bus>
                           on re0
rgephy0:                   <RTL8251/8153 1000BASE-T media interface>
                           PHY 1 on miibus0
rgephy0:                   none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow,
                           100baseTX, 100baseTX-FDX, 100baseTX-FDX-flow,
                           1000baseT-FDX, 1000baseT-FDX-master,
                           1000baseT-FDX-flow, 1000baseT-FDX-flow-master, auto,
                           auto-flow
re0:                       Using defaults for TSO: 65518/35/2048
re0:                       Ethernet address: 98:fa:9b:cd:4a:73
re0:                       netmap queues/slots: TX 1/256, RX 1/256
pcib3:                     <ACPI PCI-PCI bridge>
                           at device 29.2 on pci0
pci3:                      <ACPI PCI bus>
                           on pcib3
pci3:                      <network>
                           at device 0.0 (no driver attached)
pci0:                      <simple comms>
                           at device 30.0 (no driver attached)
isab0:                     <PCI-ISA bridge>
                           at device 31.0 on pci0
isa0:                      <ISA bus>
                           on isab0
hdac0:                     <Intel Cannon Lake HDA Controller>
                           mem 0xa1418000-0xa141bfff,0xa1000000-0xa10fffff
                           at device 31.3
                           on pci0
pci0:                      <serial bus>
                           at device 31.5 (no driver attached)
acpi_button0:              <Sleep Button> on acpi0
acpi_lid0:                 <Control Method Lid Switch>
                           on acpi0
acpi_tz0:                  <Thermal Zone>
                           on acpi0
atkbdc0:                   <Keyboard controller (i8042)>
                           port 0x60,0x64 irq 1 on acpi0
atkbd0:                    <AT Keyboard> irq 1
                           on atkbdc0

kbd0 at atkbd0
atkbd0:                    [GIANT-LOCKED]
psm0:                      <PS/2 Mouse> irq 12
                           on atkbdc0
psm0:                      [GIANT-LOCKED]
psm0:                      model Synaptics Touchpad, device ID 0
acpi_syscontainer0:        <System Container>
                           on acpi0
acpi_acad0:                <AC Adapter>
                           on acpi0
battery0:                  <ACPI Control Method Battery>
                           on acpi0
est0:                      <Enhanced SpeedStep Frequency Control>
                           on cpu0
Timecounters tick every 1.000 msec
hdacc0:                    <Conexant (0x1f86) HDA CODEC>
                           at cad 0 on hdac0
hdaa0:                     <Conexant (0x1f86) Audio Function Group>
                           at nid 1 on hdacc0
ugen0.1:                   <0x8086 XHCI root HUB>
                           at usbus0
pcm0:                      <Conexant (0x1f86) (Analog)>
                           at nid 23 and 25 on hdaa0
pcm1:                      <Conexant (0x1f86) (Left Analog Headphones)>
                           at nid 22 on hdaa0
hdacc1:                    <Intel Kaby Lake HDA CODEC>
                           at cad 2 on hdac0
hdaa1:                     <Intel Kaby Lake Audio Function Group>
                           at nid 1 on hdacc1
pcm2:                      <Intel Kaby Lake (HDMI/DP 8ch)>
                           at nid 3 on hdaa1

uhub0 on usbus0
uhub0:                     <0x8086 XHCI root HUB,
                            class 9/0, rev 3.00/1.00, addr 1>
                            on usbus0
cam_periph_alloc:          attempt to re-allocate valid device
                           pass1 rejected flags 0 refcount 3
passasync:                 Unable to attach new device due to status 0x6:
                           CCB request was invalid

ada0 at ahcich1 bus 0 scbus0 target 0 lun 0
ada0:                      <WDC WD10SPZX-08Z10 05.01A05>
                           ACS-3 ATA SATA 3.x device
ada0:                      Serial Number WD-WXR1A49J4AK8
ada0:                      600.000MB/s transfers
                           (SATA 3.x, UDMA6, PIO 8192bytes)
ada0:                      Command Queueing enabled
ada0:                      953869MB (1953525168 512 byte sectors)

ada1 at ahcich2 bus 0 scbus1 target 0 lun 0
ada1:                      <SAMSUNG MZNLN256HAJQ-000L7 MVT25L6Q>
                            ACS-3 ATA SATA 3.x device
ada1:                      Serial Number S3RZNX0M827825
ada1:                      600.000MB/s transfers (SATA 3.x, UDMA6, PIO 512bytes)
ada1:                      Command Queueing enabled
ada1:                      244198MB (500118192 512 byte sectors)
Trying to mount root from ufs:/dev/ufs/FreeBSD_Install [ro,noatime]...

WARNING: WITNESS option enabled, expect reduced performance.

uhub0:                     18 ports with 18 removable, self powered
ugen0.2:                   <VIA Labs, Inc. USB2.0 Hub> at usbus0

uhub1 on uhub0
uhub1:                     <VIA Labs, Inc. USB2.0 Hub,
                            class 9/0, rev 2.10/90.11, addr 1>
                            on usbus0
Root mount waiting for:    usbus0
uhub1:                     4 ports with 4 removable, self powered
Root mount waiting for:    usbus0
ugen0.3:                   <C-Media Electronics Inc. USB Audio Device> at usbus0
ugen0.4:                   <vendor 0x413c Dell KB216 Wired Keyboard> at usbus0

ukbd0 on uhub1
ukbd0:                     <vendor 0x413c Dell KB216 Wired Keyboard,
                            class 0/0, rev 1.10/1.08, addr 3>
                            on usbus0

kbd2 at ukbd0
Root mount waiting for:    usbus0
ugen0.5:                   <Logitech USB Receiver> at usbus0

ukbd1 on uhub1
ukbd1:                     <Logitech USB Receiver,
                            class 0/0, rev 2.00/29.01, addr 4>
                            on usbus0

kbd3 at ukbd1
Root mount waiting for:    usbus0
Root mount waiting for:    usbus0
ugen0.6:                   <Generic USB3.0 Card Reader> at usbus0

umass0 on uhub0
umass0:                    <Generic USB3.0 Card Reader,
                            class 0/0, rev 3.00/15.32, addr 5>
                            on usbus0
umass0:                    SCSI over Bulk-Only; quirks = 0x8100
umass0:2:0:                Attached to scbus2
mountroot:                 waiting for device /dev/ufs/FreeBSD_Install...
(probe0:umass-sim0:0:0:0): REPORT LUNS. CDB: a0 00 00 00 00 00 00 00 00 10 00 00 
(probe0:umass-sim0:0:0:0): CAM status: SCSI Status Error
(probe0:umass-sim0:0:0:0): SCSI status: Check Condition
(probe0:umass-sim0:0:0:0): SCSI sense: ILLEGAL REQUEST
                           asc:20,0 (Invalid command operation code)
(probe0:umass-sim0:0:0:0): Error 22, Unretryable error

da0 at umass-sim0 bus 0 scbus2 target 0 lun 0
da0:                       <Generic STORAGE DEVICE 1532>
                           Removable Direct Access SPC-4 SCSI device
da0:                       Serial Number 000000001532
da0:                       400.000MB/s transfers
da0:                       1938MB (3970048 512 byte sectors)
da0:                       quirks=0x3<NO_SYNC_CACHE,NO_6_BYTE>
random:                    unblocking device.
lo0:                       link state changed to UP
re0:                       link state changed to UP

uaudio0 on uhub1
uaudio0:                   <C-Media Electronics Inc. USB Audio Device,
                            class 0/0, rev 1.10/1.00, addr 2>
                            on usbus0
uaudio0:                   Play:   48000 Hz,
                                   2 ch,
                                   16-bit S-LE PCM format,
                                   2x8ms buffer.
uaudio0:                   Play:   44100 Hz,
                                   2 ch,
                                   16-bit S-LE PCM format,
                                   2x8ms buffer.
uaudio0:                   Record: 48000 Hz,
                                   1 ch,
                                   16-bit S-LE PCM format,
                                   2x8ms buffer.
uaudio0:                   Record: 44100 Hz,
                                   1 ch,
                                   16-bit S-LE PCM format,
                                   2x8ms buffer.
uaudio0:                   No MIDI sequencer.
pcm3:                      <USB audio> on uaudio0
uaudio0:                   HID volume keys found.

uhid0 on uhub1
uhid0:                     <vendor 0x413c Dell KB216 Wired Keyboard,
                            class 0/0, rev 1.10/1.08, addr 3>
                            on usbus0

ums0 on uhub1
ums0:                      <Logitech USB Receiver,
                            class 0/0, rev 2.00/29.01, addr 4>
                            on usbus0
ums0:                      18 buttons and [XYZT] coordinates ID=2
Disadvantages: grep(1) works on physical lines (to be fair, there are already some multi‑line messages), predicting reasonable tabs(1) is difficult, esp. on an 80×25 screen it wastes a lot of space … just to name some issues.​
 
Here's the thing - bikeshedding output format styling or symlink paths doesn't really improve anything with regards to the core functionality of the init system. Which is what the title of this post is declaring. For something like this, you could just write a script and go on about your day.

To the OP; read the rcd mailing list thread and use that as a starting point for your own potential improvements.

The main thing I like about rcd (which borrows much from SMF); is that the CLI experience (and its unit file format) is much more streamlined (much like ZFS), so a TUI isn't really necessary in these cases. IMO, UCL reads like english; so it's very easy to parse and finesse to your liking.
 
hedwards said:
Honestly, aesthetics isn't much of a concern for an OS which doesn't ship with a GUI by default.
Click to expand...
I disagree. Aesthetic is important and is not only a GUI thing. Due to readability.
Linux dmesg, in opposite to *BSD dmesg, are difficult to read for me.
Colors and ornaments may make them more unreadable, due to distraction.
All is the question, what you mean with aesthetic.
 
If the aesthetic things are done by any of downstreams (consumers, like GhostBSD) and upstreamed back, possibly it would be accepted, as non-default options.

For kernel, FreeBSD has kernel configuration files like GENERIC, GENERIC-MMCCAM and MINIMAL (GENERIC is the default). Adding another and preparing underlying supports may be possible.

For userland, FreeBSD has build knobs for optional configurations managed by /usr/share/mk/bsd.opts.mk (source: /usr/src/share/mk/bsd.opts.mk).

Maybe adding the functionality as DEFAULT_NO would have far less objections, and could help downstream projects (just need to enable on builds).

Another downside to colorizing boot time outputs would be the polutions of logs obtained via serial consoles. Opening the log with editors to look into suddenly becomes harder, as a plenty of ESC sequences are contained.
To satisfy both requirements, console drivers would be needed to become something like GEOM for disks or NETGRAPH for networks to allow inserting colorization layer, but it would be quite complexed and huge works.
 
mer said:
Agree completely. Not just boot logs, but when I'm doing script on a system to capture steps and outputs when the term window is colorized.
Click to expand...
I'm always struggling with reading poudriere build logs of ports that use colorized outputs in editors to determine actual errors.:eek:

With this (a plenty of) experiences, my opinion is to output without colorization and prepare log readers that analyze logs and properly colorize would be the good way to go.
 
RainCoder said:
and more aesthetically pleasing. That would make it both more useful and more impressive to prospective users
Click to expand...
I recommend you attempt to experience FreeBSD from a serial terminal. You will realise that colors and special escape characters make the experience much, much worse for new and experienced users. The use of serial in the casual consumer space is growing due to things like Raspberry Pi, etc.

RainCoder said:
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.
Click to expand...
No. But we can instead direct you to see more things that your current narrower view-point as a traditional PC user has missed. For example serial comms, redirect logs, etc. Did you think about those?

Some emperors also tend not to wear colourful clothes. Only some cultures see garish colours as a sign of wealth. For many of the richest, most powerful people, tend to wear understated, earthy tones. You can absolutely think with your own mind, but do note that as a human, that can be very fallible and limited. Its much better to seek a consensus of viewpoints.

Or... just go off and do your own thing is fine too. Share the results and people can take what works. Simples 🍺
 
mer said:
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.
Click to expand...

off topic, maybe is only in my machine,but if I use the intel xorg driver and not modesetting there is no need to load i915kms at boot time, when startx the i915kms module is loaded
the intel xorg driver is deprecated..but works for me
 
hruodr said:
I disagree. Aesthetic is important and is not only a GUI thing. Due to readability.
Linux dmesg, in opposite to *BSD dmesg, are difficult to read for me.
Colors and ornaments may make them more unreadable, due to distraction.
All is the question, what you mean with aesthetic.
Click to expand...
Colors become a clown car blur. For errors just give me gray or bold or red or yellow and that's all one needs if they need it at all
 
drhowarddrfine said:
Colors become a clown car blur. For errors just give me gray or bold or red or yellow and that's all one needs if they need it at all
Click to expand...
Yep. Anyone that has done telco work knows to be careful with LED colors and patterns. Picture a server room full of systems in racks: amongst a sea of green leds the single red on the 3rd rack from the end catches your eye.

Bolded errors are typically serial console friendlier than colors.
 
I was very pleasantly surprised when I logged on to see a lot of very constructive and thoughtful comments. Thank you all for that! 🏞️🤩

Yesterday I was avoiding logging on at all because I was dreading having to potentially deal with some kind of disproportionate reaction to my objection to the two angry comments. It is great to see that the tone is civil and helpful again from all respondents!

I especially appreciate the useful and thoughtful information provided by Beastie7 and Kai Burghardt.

I was unaware of the existence of the rcd service manager and that does look promising. I am looking forward to seeing how the various projects for improving FreeBSD for desktop use and other important initiatives for key aspects of the OS pan out and it sounds like FreeBSD 16 could be an exciting release.

Kai Burghardt's provided example of even just doing something as simple as adding line breaks and such is also a great illustration of how even just slight improvements could help legibility a lot. Making the lines breaks space aware so that it doesn't break at bad moments would also indeed be a big (but still simple) improvement.

Several respondents have also provided some very helpful links and good relevant info about related matters and the considerations involved in these kinds of things.

That being said, I still believe that the easiest way for FreeBSD to increase its new user adoption rate (and hence also long-term funding and contributions to all aspects of the OS) is to maximize the visceral appeal of both the installer and the boot process and general ease of setup for all possible use cases (both for technical functionality and aesthetics, and both servers and desktop uses, etc). Computers are machines for doing essentially any arbitrary thing and so all this is therefore always possible to any level of polish at least in theory (though legacy issues interfere with that in practice of course). I still think it is worth investing in how FreeBSD's first impression comes across just as heavily as in fundamentals like the filesystem and drivers, rather than treating it as an afterthought.

However, I understand that there are lots of implementation issues to consider in any mature codebase and I (as a relative newcomer) of course don't know what the full ripple effects may be.

For the time being, I will continue learning more about FreeBSD (reading through the books I got, etc), just as has been suggested by some here, even though I don't expect my feelings on aesthetics and how important they are to change, especially since my goals are largely directed at daily driver desktop use and similar kinds of highly user experience oriented contexts. I have no expectation to ever need to use a serial cable for anything I have in mind, for example, nor to benefit from such, though I may try one just to experience it for learning purposes as suggested.

Anyway, those are my thoughts after reading through all the new responses. I thank you all for your time (as always) and wish you all the best of weekends and a great upcoming week. 😎👋
 
drhowarddrfine said:
Colors become a clown car blur. For errors just give me gray or bold or red or yellow and that's all one needs if they need it at all
Click to expand...
Yep, personally, I prefer when the output of such things just gives me something easy to grep for. My dmesg output isn't so bad, it's only 87 lines at the moment, but sometimes output for things can get even longer, but even at 87 lines, that's still multiple terminal heights.

Plus, if I'm on a color terminal, I can always use the --color option for grep to highlight whatever it is that I'm personally looking for rather than what somebody else thought was going to be important.
 
RainCoder said:
That being said, I still believe that the easiest way for FreeBSD to increase its new user adoption rate (and hence also long-term funding and contributions to all aspects of the OS) is to maximize the visceral appeal of both the installer
Click to expand...
Appealing installer you said... Here is something I forced Claude to do (work in not so much progress, I can procrastinate only to a certain extend) when I vaguely remembered there was talk long time ago about incorporating some form of internet browser only to get little graphics into installation procedure and I know we had vgl and creating couple of colorful rectangles can't be so hard. It requires UEFI boot for now, starts under xen@amd64, under qemu@aarch64 (UTM on macOS) you need kernel patch to mmap support, included. Also in design doc is short consideration about mass install driven by DHCP data for quick school lab setup for example.

To be clear, I also prefer text installer, doing 99 % of installs on servers via remote KVM, less what can break is better.
 

Attachments

There isn't actually any reason why my suggestion would cause any problems for grep nor any other similar tools, especially considering (if you've read my comments fully, though I know they are lengthy) that I've said from the start (from my very 1st post) that all the existing boot message info should be preserved as is and made easy to find by symbolic linking /var/run/dmesg.boot as /root/boot_messages.txt so that it can be browsed at one's leisure after booting and likewise for the fancy messages. There is thus no impediment to grep whatsoever, in reality, unless you are running grep during the boot sequence somehow, which strikes me as quite unlikely and impractical.

It is similarly untrue to think that just because the boot itself optionally uses colors to create a better first impression that it wouldn't be trivially easy to also generate (during boot or later on) a version of the fancy boot messages that has all color removed and which leaves only the plain ASCII or UTF-8 characters if desired and which thus would itself also have no grep problems.

In these regards, it is imperative to think from first principles and imaginatively and to not conflate possibilities in ways that create false dichotomies that are not grounded in any necessary reality. Any given change to any system has countless nuances of the details of how it can be done and what other things can be changed or left alone or altered without harming existing use cases.

Though grep is very useful as a general tool of course, using it after booting wouldn't do anything at all to help users' first impressions of the OS and hence is irrelevant to the primary motivation behind my suggestion and why I created this thread. Conflating such uses cases is a recipe for lost opportunities. There is no conflict when the idea is understood rigorously and imaginatively.


Regarding Lua, it has one of the smallest implementations of any extant language (short of Scheme and Forth of course) and integrates very well with C, and I thus find it somewhat strange that one would cite it as an example of bloat when it is objectively easily one of the least bloated choices for an auxiliary language they could have made. The manual for the core language for version 5.1 was only 27 pages long for example, compared to hundreds of pages for C and thousands for C++. Whether or not one wants any interpreted language added at all is a separate matter of course, but I see little potential for harm. No worries though, I know such things are highly subjective and there is still a great deal of potential for better programming languages in theory.


Though this should still be fine for the OP who just seems to want "change" ;).
Click to expand...

I understand your motivation to preemptively defend what you like, especially in light of the fact that so often in tech in the past couple decades unwanted changes have been made to many software packages (especially by "big tech"), but is quite untrue that I just want change. My motivation and my guiding principles have long been to always preserve all existing value in any system I work with and to never damage existing use cases but to instead always frame redesigns and suggestions for anything from a well-grounded and respectful perspective.

That is precisely why I went to such lengths to ensure my idea was designed specifically to minimize all ripple effects beyond those that are superficial but seem strategically necessary.

Along those lines, that is highly salient for what has most surprised me about the reaction to the thread: I was not expecting so much pushback for an idea designed to be as conservative as possible with regards to how the system could be changed while still having a good chance of substantively making a real positive impact on FreeBSD's future.

I think a fair few of you here are greatly underestimating what the long-term costs of this kind of falsely dichotomous mindset could have on the future, though at the same time I deeply empathize with being defensive against misguided changes to software considering that so many such blunders have happened over the years. My philosophy is not such a case though.


incorporating some form of internet browser only to get little graphics into installation procedure
Click to expand...

This is the exact opposite of the kind of changes I would want made to a system. In fact I have been very sharply criticizing such tends in software for many years now.

I would never want a browser incorporated into anything just to create a simple GUI nor certainly (and even more so) for anything like the text output of the boot sequence!

Indeed, I'm not fond of much of the web tech "stack" in general, honestly, and am rather a proponent of strongly preferring offline and tightly efficient programs as much as possible.

My viewpoint is one of real respect for all possible nuances of a system and I am specifically highly against bloat and rat's nests of harmful dependencies and liabilities.

The specifics of how something is implemented make a world of difference in outcomes.

It is analogous to how much a piece of music can differ based on who makes it and how, such as if multiple musicians were given the same basic criteria such as "something electronic but also rustic" or whatever else, and you'd heard a bad example of that before and then assumed that all further instances of that would be bad. Such a mindset is a recipe for self-deception and I am hoping that my words in these regards get through to more people so that more understand the lost opportunity inherent to this kind of unfortunately common stance in Linux and the Unix-likes.

Most saliently though, as a strictly anti-AI (and anti-plagiarism and pro-ethics more broadly) person I am never willing to knowingly use any content "generated" (in reality: aggregated, randomized, transformed, and plagiarized to provide a means of copyright laundering essentially) by the slop bots if there is any other practically viable choice and I would sooner stop using computers entirely than be forced to use these "AI" frankly. Some projects have used "AI" to varying degrees, including some essential foundational ones like Clang/LLVM (though 99% of its features were complete before the advent of "AI"), but only when there is no practical viable choice am I willing to use things that have been very significantly tainted by any form of inherent immorality (of which "AI' is just one example... other breaches of ethics likewise turn me away from using other things). I am doing everything in my power to move against such trends and to minimize the reach of "AI" in my life as much as possible and I even would refuse to ever work on or with such systems no matter what the personal cost may be.

The greatest irony of "AI" use is that the most commonly cited "reason" of its proponents (that not using it would "cause you to fall behind") is very clearly the least true when you actually think from first principles and human incentives about what the implications are. In particular, since use of "AI" prompting not only requires very little/no skill, and functions in a manner akin to giving a healthy person a cane and forcing them to walk with it (and hence to atrophy their once previously healthy legs over time), it is most likely that it is ironically the "AI" users who will most inevitably fall behind over time. Only skills that take significant effort to obtain retain competitive market value. Similarly, anything produced in unlimited quantities inevitably undergoes hyperinflation and hence devaluation. The scammers who have invested so many billions (or trillions?) in such systems though are very motivated to trick as many as possible into giving them a return on investment.


Anyway, my tangents and my rambling aside, I thank you all again for taking time in your days to share your thoughts!

To all readers and commentators: May your week be both productive and enlightening! 🗓️🌅
 
You're playing a bit fast and loose with people's willingness to be "imaginative" here. The best code in the world is code that does not exist. Why? Because it does not break, nor does it get hacked or need maintenance. My Prime Directive reads like this: you never interfere with a system that meets its requirements.

Sure you're welcome to debate the requirements themselves up to high heaven and back. That's fine. That's the kind of debate where change is supposed to originate. Please don't try to discuss implementation details before you have the newly adjusted set requirements in front of you crystal clear, and the debate on those is fully settled. What problem are you really trying to solve, and what would the system look like exactly in a world where your problem doesn't exist anymore?
 
  • Like
Reactions: mer
RainCoder said:
There isn't actually any reason why my suggestion would cause any problems for grep nor any other similar tools, especially considering (if you've read my comments fully, though I know they are lengthy) that I've said from the start (from my very 1st post) that all the existing boot message info should be preserved as is and made easy to find by symbolic linking /var/run/dmesg.boot as /root/boot_messages.txt so that it can be browsed at one's leisure after booting and likewise for the fancy messages. There is thus no impediment to grep whatsoever, in reality, unless you are running grep during the boot sequence somehow, which strikes me as quite unlikely and impractical.

It is similarly untrue to think that just because the boot itself optionally uses colors to create a better first impression that it wouldn't be trivially easy to also generate (during boot or later on) a version of the fancy boot messages that has all color removed and which leaves only the plain ASCII or UTF-8 characters if desired and which thus would itself also have no grep problems.

In these regards, it is imperative to think from first principles and imaginatively and to not conflate possibilities in ways that create false dichotomies that are not grounded in any necessary reality. Any given change to any system has countless nuances of the details of how it can be done and what other things can be changed or left alone or altered without harming existing use cases.

Though grep is very useful as a general tool of course, using it after booting wouldn't do anything at all to help users' first impressions of the OS and hence is irrelevant to the primary motivation behind my suggestion and why I created this thread. Conflating such uses cases is a recipe for lost opportunities. There is no conflict when the idea is understood rigorously and imaginatively.


Regarding Lua, it has one of the smallest implementations of any extant language (short of Scheme and Forth of course) and integrates very well with C, and I thus find it somewhat strange that one would cite it as an example of bloat when it is objectively easily one of the least bloated choices for an auxiliary language they could have made. The manual for the core language for version 5.1 was only 27 pages long for example, compared to hundreds of pages for C and thousands for C++. Whether or not one wants any interpreted language added at all is a separate matter of course, but I see little potential for harm. No worries though, I know such things are highly subjective and there is still a great deal of potential for better programming languages in theory.




I understand your motivation to preemptively defend what you like, especially in light of the fact that so often in tech in the past couple decades unwanted changes have been made to many software packages (especially by "big tech"), but is quite untrue that I just want change. My motivation and my guiding principles have long been to always preserve all existing value in any system I work with and to never damage existing use cases but to instead always frame redesigns and suggestions for anything from a well-grounded and respectful perspective.

That is precisely why I went to such lengths to ensure my idea was designed specifically to minimize all ripple effects beyond those that are superficial but seem strategically necessary.

Along those lines, that is highly salient for what has most surprised me about the reaction to the thread: I was not expecting so much pushback for an idea designed to be as conservative as possible with regards to how the system could be changed while still having a good chance of substantively making a real positive impact on FreeBSD's future.

I think a fair few of you here are greatly underestimating what the long-term costs of this kind of falsely dichotomous mindset could have on the future, though at the same time I deeply empathize with being defensive against misguided changes to software considering that so many such blunders have happened over the years. My philosophy is not such a case though.




This is the exact opposite of the kind of changes I would want made to a system. In fact I have been very sharply criticizing such tends in software for many years now.

I would never want a browser incorporated into anything just to create a simple GUI nor certainly (and even more so) for anything like the text output of the boot sequence!

Indeed, I'm not fond of much of the web tech "stack" in general, honestly, and am rather a proponent of strongly preferring offline and tightly efficient programs as much as possible.

My viewpoint is one of real respect for all possible nuances of a system and I am specifically highly against bloat and rat's nests of harmful dependencies and liabilities.

The specifics of how something is implemented make a world of difference in outcomes.

It is analogous to how much a piece of music can differ based on who makes it and how, such as if multiple musicians were given the same basic criteria such as "something electronic but also rustic" or whatever else, and you'd heard a bad example of that before and then assumed that all further instances of that would be bad. Such a mindset is a recipe for self-deception and I am hoping that my words in these regards get through to more people so that more understand the lost opportunity inherent to this kind of unfortunately common stance in Linux and the Unix-likes.

Most saliently though, as a strictly anti-AI (and anti-plagiarism and pro-ethics more broadly) person I am never willing to knowingly use any content "generated" (in reality: aggregated, randomized, transformed, and plagiarized to provide a means of copyright laundering essentially) by the slop bots if there is any other practically viable choice and I would sooner stop using computers entirely than be forced to use these "AI" frankly. Some projects have used "AI" to varying degrees, including some essential foundational ones like Clang/LLVM (though 99% of its features were complete before the advent of "AI"), but only when there is no practical viable choice am I willing to use things that have been very significantly tainted by any form of inherent immorality (of which "AI' is just one example... other breaches of ethics likewise turn me away from using other things). I am doing everything in my power to move against such trends and to minimize the reach of "AI" in my life as much as possible and I even would refuse to ever work on or with such systems no matter what the personal cost may be.

The greatest irony of "AI" use is that the most commonly cited "reason" of its proponents (that not using it would "cause you to fall behind") is very clearly the least true when you actually think from first principles and human incentives about what the implications are. In particular, since use of "AI" prompting not only requires very little/no skill, and functions in a manner akin to giving a healthy person a cane and forcing them to walk with it (and hence to atrophy their once previously healthy legs over time), it is most likely that it is ironically the "AI" users who will most inevitably fall behind over time. Only skills that take significant effort to obtain retain competitive market value. Similarly, anything produced in unlimited quantities inevitably undergoes hyperinflation and hence devaluation. The scammers who have invested so many billions (or trillions?) in such systems though are very motivated to trick as many as possible into giving them a return on investment.


Anyway, my tangents and my rambling aside, I thank you all again for taking time in your days to share your thoughts!

To all readers and commentators: May your week be both productive and enlightening! 🗓️🌅
Click to expand...
It's not that it would cause problems for grep, it's that there's no reason to have colorized output when the system works just fine and if your watching the output then you probably expect something in particular to be going wrong that the programmers would have fixed if they expected it. As far as newbs go, the fact that there's a bunch of text is going to be the problem if there is one at all. And really, if you don't like looking at a wall of text, then *BSD may not be for you. If that's the thing that is turning somebody off from using any of these OSes, then I don't even know what to say.
 
You must log in or register to reply here.
Back
Top