Re: The First Distro To Offer XLibre

On Wed, 2 Jul 2025 06:23:08 +0530, Not Necessary wrote:

On 02/07/25 3:51 am, Lawrence D'Oliveiro wrote:

>
So where does the “computers can’t understand plaintext, they
understand binaries” come in?

 
The computer does not understand the `glyph'; we do. Plaintext is the
glyph that we read and write with. Digital computing devices can only
use the encoding for the glyph, based on the software it is provided to
do so.

That “encoding” is what is defined as “plaintext”, is it not?

What if it’s in ROM? What if it’s in the ROM of a power controller or
management-engine chip that’s built into the motherboard or even
integrated into the CPU die, that needs to start up before your CPU
can even work?

 
You are conflating two different concepts: A sequence of zeros and ones,
even if it is etched permanently on to any integrated circuit is still
software; they are instructions, not pathways. Current can only flow
through pathways. Instructions, even if they are part of the circuit
design and integrated within it, is low-level software.

What about PLAs, then, where the instructions *are* the pathways?

Consider also that CPU instructions also control pathways: e.g. LOAD/STORE
instructions activate pathways to move bits between registers and main
memory, while an ADD instruction switches bits from two input registers
into the adder circuit, while switching the output back to a third
register (or perhaps one of the two input ones). Everything is switching;
all sequential logic involves flows along pathways.

Sure you can. It’s all abstract machines on top of abstract machines:
you can build a more special-purpose CLI on top of a more
general-purpose one.

 
Can you name a special-purpose CLI on top of a general-purpose one?

The ability to extend the power of a POSIX shell through:
  * External commands
  * Function definitions

The shell itself only provides its own built-in commands out of the box;
everything else has to come from extension mechanisms, like those above.

And at the final step, you can build GUI front-ends to CLI tools.

 
You are using a CLI tool as an API for your GUI front-end. There is no
interaction with the command line.

When is a CLI not a command line?

I’ve got news for you: Emacs has long had the option to run in its own
GUI windows, independent of any terminal (though it can still work
through a terminal). It also includes the basics of a GUI toolkit, for
you to create custom interfaces to an Emacs extension.

 
I'm not referring to the Emacs GUI interface.

I am.

No you don’t. Emacs can run CLI commands that take input from editor
buffers and return output to editor buffers. And of course there is
copy and paste between editor windows and terminal windows.

 
If you use the terminal version of Emacs, you enter into the Emacs
editor interface, where you cannot pipe or re-direct data to the
terminal.

You can do the process-buffer thing there too. Those subprocess commands
work just as well whether Emacs is running in a terminal window or in its
own GUI.

You *do* realize KDE is just a framework for implementing Dolphin and
other apps, right? So yes, they *are* built on top of KDE!

 
I hope you know that Qt is the framework ...

Remember what I said about abstract machines on top of abstract machines?
Qt is built on top of C++, which already provides its own framework aka
“standard library”. KDE is another level of framework built on top of
that, to implement common services for all apps in the KDE family.