Path: nntp.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: Lawrence D'Oliveiro <ldo@nz.invalid>
Newsgroups: comp.os.linux.advocacy
Subject: Re: The First Distro To Offer XLibre
Date: Fri, 11 Jul 2025 23:32:42 -0000 (UTC)
Organization: A noiseless patient Spider
Lines: 84
Message-ID: <104s6uq$1o14i$11@dont-email.me>
References: <184d439321081200$22529$367819$802601b3@news.usenetexpress.com>
	<103t4h0$1gnjn$1@solani.org> <103thsr$22ifd$4@dont-email.me>
	<103u32s$1haki$1@solani.org>
	<pan$41a33$85d637b3$46d41771$6eeb831a@linux.rocks>
	<103v4g5$1i0el$1@solani.org> <103v96u$2etla$3@dont-email.me>
	<103vh6a$1i5f9$1@solani.org> <103viei$2k9oo$1@dont-email.me>
	<1041vti$1insg$1@solani.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Injection-Date: Sat, 12 Jul 2025 01:32:42 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="b0585261fe77f2a7eb861bacdb0c7515";
	logging-data="1836178"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/aRvFIhPXrxj57i3c+Pjq2"
User-Agent: Pan/0.162 (Pokrosvk)
Cancel-Lock: sha1:uE8cSXPbvfVA6S9bUjbOFnhz0Mo=

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.