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

[T-Aoki]

Do you think these READABLE? I don't think so.

An example how colorized log is seen using misc/lv.

And in editors/leafpad.

 

[hedwards]

Do you think these READABLE? I don't think so.

An example how colorized log is seen using misc/lv.
View attachment 26747

And in editors/leafpad.
View attachment 26748

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.

 

[ondra_knezour]

I don't see a particular problem there.

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

 

[kent_dorfman766]

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?

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?

 

[T-Aoki]

Maybe all those ^[[0;34 etc. may be considered less legible by some?

ESC sequences hurts the position of the error positiom marker "^".
This is quite annoying.

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

The square means character code "001B" in hex, that is ESC code ("^[" in the first example).

 

[hedwards]

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

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.

Output like that is readable to the people that need to read it. Without looking up the source code it's hard to make much sense of it, and reformatting things isn't likely to do much about that. However, if you really want to, you can always redirect the output and use sed to split the lines to make it easier to read. I don't see any real point in doing so, but it can be done without having to throw the baby out with the bathwater.

That's not to say that I'm personally opposed to changes being made, I just don't see any pressing need to do so, and I'm not personally convinced that doing so would really do much other than create more work. And it likely would be more work.

 

[kjpetrie]

This certainly doesn't belong in the base system. That has to be as lean as possible to keep it compact. Its job is to provide basic functionality, not bells or whistles.

As a port to be added for those wanting it, fine if someone is prepared to devote the considerable effort needed to write the code and maintain it, but not at the expense of more important things like security upgrades which matter far more.

While FreeBSD can be installed on a desktop/laptop and has the necessary ports to implement that, it's not really its core purpose. None of my FreeBSD machines, real or virtual, has a GUI. I use it for headless servers. I use PCLinuxOS on my desktop and 64-bit laptops, and Devuan Linux on my 32-bit laptops, apart from one minimal system used as a music player, which uses TinyCore.

I could run FreeBSD on my desktop, but Linux generally has better hardware support and is close enough to Unix (with the distros I use) to be good enough for my daily needs.

The problem the OP has is his/her belief that this big idea is an obvious improvement rather than a distraction from a good workhorse server system which would suck huge amounts of limited developer time into tinsel rather than solid structure. He/she assumes FreeBSD wants to be aesthetically pleasing to people with his/her tastes and that would make it look more professional rather than less which, for me, it would. I don't want slick presentation. I want a good solid dependable system I can rely on to serve my sites and deliver my mail. It doesn't need to be pretty. It needs to be dependable, and that's where I want the effort to go.

If the OP thinks developing the idea would be an improvement and a worthwhile use of time, well then, use your time to produce it, but don't expect to use other people's time to implement your idea. If we thought it worthwhile, someone would already have done it.

On my desktop I use KDE Plasma because it's pretty and has functionality that aids my workflow, but I'd never trust a KDE application with my data because they can change and obsolete formats on a whim without warning and I've lost information too many times through upgrades in the past when my old mails or records have been rendered unreadable. That's where the OP's approach goes, where fashion becomes more important than function. I can back up my data as much as I like, but that's useless if the software suddenly can't read it any more.

As for those minimalist icons the OP hates so much, somebody else thought they looked better. That's the problem with aesthetics. One person's beautiful is someone else's ugly.

 

[T-Aoki]

This certainly doesn't belong in the base system. That has to be as lean as possible to keep it compact. Its job is to provide basic functionality, not bells or whistles.

As a port to be added for those wanting it, fine if someone is prepared to devote the considerable effort needed to write the code and maintain it, but not at the expense of more important things like security upgrades which matter far more.

While FreeBSD can be installed on a desktop/laptop and has the necessary ports to implement that, it's not really its core purpose. None of my FreeBSD machines, real or virtual, has a GUI. I use it for headless servers. I use PCLinuxOS on my desktop and 64-bit laptops, and Devuan Linux on my 32-bit laptops, apart from one minimal system used as a music player, which uses TinyCore.

I could run FreeBSD on my desktop, but Linux generally has better hardware support and is close enough to Unix (with the distros I use) to be good enough for my daily needs.

The problem the OP has is his/her belief that this big idea is an obvious improvement rather than a distraction from a good workhorse server system which would suck huge amounts of limited developer time into tinsel rather than solid structure. He/she assumes FreeBSD wants to be aesthetically pleasing to people with his/her tastes and that would make it look more professional rather than less which, for me, it would. I don't want slick presentation. I want a good solid dependable system I can rely on to serve my sites and deliver my mail. It doesn't need to be pretty. It needs to be dependable, and that's where I want the effort to go.

If the OP thinks developing the idea would be an improvement and a worthwhile use of time, well then, use your time to produce it, but don't expect to use other people's time to implement your idea. If we thought it worthwhile, someone would already have done it.

On my desktop I use KDE Plasma because it's pretty and has functionality that aids my workflow, but I'd never trust a KDE application with my data because they can change and obsolete formats on a whim without warning and I've lost information too many times through upgrades in the past when my old mails or records have been rendered unreadable. That's where the OP's approach goes, where fashion becomes more important than function. I can back up my data as much as I like, but that's useless if the software suddenly can't read it any more.

As for those minimalist icons the OP hates so much, somebody else thought they looked better. That's the problem with aesthetics. One person's beautiful is someone else's ugly.

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.

So implementing in base and disabled by default would be the way to go if someone (not me, as I myself don't want the feature) intend to do.

Of course, anyone who want the feature should need building base from source. Or some downstream project like GhostBSD could want to enable by default "on THEIR builds".