Path: 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: Tue, 1 Jul 2025 22:21:08 -0000 (UTC)
Organization: A noiseless patient Spider
Lines: 60
Message-ID: <1041n0k$33014$2@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>
	<1040fkc$1ht32$1@solani.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Injection-Date: Wed, 02 Jul 2025 00:21:09 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="e9ef4a4bf4acba6663e85965c9fb094a";
	logging-data="3244068"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+8tjGVbrA+BBKoKITvn9j4"
User-Agent: Pan/0.162 (Pokrosvk)
Cancel-Lock: sha1:KnxPa5+XmIxrdAMQKalh/DGwAJg=

On Tue, 1 Jul 2025 16:39:01 +0530, Not Necessary wrote:

> On 01/07/25 8:20 am, Lawrence D'Oliveiro wrote:
>>
>> But you said “computers can’t understand plaintext, they understand
>> binaries”. But if they’re the same thing, then why would computers
>> understand one but not the other?
> 
> The characters or glyphs we see are ultimately mapped according to the
> encoding format, which represent a numeric value for that character or
> glyph. The computer can't understand the glyph; we do. It can only use
> the numeric value associated with it to store / parse / transmit it.

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

>> So do “microcode” and “firmware”. Are they part of the “software” or
>> the “hardware”?
> 
> Microcode is software, and so is firmware.

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?

>> It’s the one layer of abstract machine that is not designed for
>> additional layers to be built on top.
> 
> GUI is one of the paradigms of user interface, just like the CLI is. You
> can't build an interface on top of a CLI.

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. 
And at the final step, you can build GUI front-ends to CLI tools.

A lot of GUI apps work this way. That also means you can automate 
operations by writing scripts that drive the back-ends directly, without 
having to resort to flaky and fragile fake-mouse-clicks-and-keystrokes 
GUI-automation tools.

> A program using a pseudo-graphical interface such as Emacs on the
> terminal does not build ``on top'' of the CLI

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.

> -- one loses the ability to pipe and redirect data that they can do on
> the command line.

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.

> Likewise a file manager such as Dolphin isn't build on top of KDE.

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