Uninstalling a package removes other essential packages: What is the best course of action?

[Stella Ashburne]

I did a minimal install of LXQt:

sudo apt install lxqt-core lightdm

and discovered that the following two packages were installed as well:

libthai-data/stable,now 0.1.28-3 all [installed,automatic]
libthai0/stable,now 0.1.28-3 amd64 [installed,automatic]

*I do not speak or write Thai*

When I did the following

sudo apt remove libthai*

I was very surprised to see that many packages that I think are essential to running Debian properly would be removed if I answered "Yes" to the question "Do you want to continue?"

What should I do? What is the best course of action?

Below is the output of sudo apt remove libthai*

Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Note, selecting 'libthai0' for glob 'libthai*'
Note, selecting 'libthai-data' for glob 'libthai*'
Note, selecting 'libthai-dev' for glob 'libthai*'
Note, selecting 'libthai-doc' for glob 'libthai*'
Package 'libthai-dev' is not installed, so not removed
Package 'libthai-doc' is not installed, so not removed
The following packages were automatically installed and are no longer required:
adwaita-icon-theme at-spi2-core cpp cpp-10 cups-pk-helper fonts-quicksand
gir1.2-atk-1.0 gir1.2-freedesktop gir1.2-gdkpixbuf-2.0 gir1.2-glib-2.0
gir1.2-harfbuzz-0.0 gir1.2-notify-0.7 gir1.2-packagekitglib-1.0
gir1.2-polkit-1.0 gir1.2-secret-1 gnome-accessibility-themes
gnome-keyring-pkcs11 gnome-themes-extra gnome-themes-extra-data
gparted-common gsfonts gsfonts-x11 gtk2-engines-pixbuf i965-va-driver
intel-media-va-driver libaom0 libappstream4 libass9 libatk-bridge2.0-0
libatk1.0-0 libatk1.0-data libatkmm-1.6-1v5 libatspi2.0-0 libavutil56
libblas3 libbs2b0 libcairo-gobject2 libcairo2 libcairomm-1.0-1v5
libcodec2-0.9 libcolord2 libcurl3-gnutls libdatrie1 libdav1d4 libepoxy0
libfftw3-double3 libflite1 libgdk-pixbuf-xlib-2.0-0 libgdk-pixbuf2.0-0
libgfortran5 libgirepository-1.0-1 libglibmm-2.4-1v5 libgme0 libgomp1
libgsm1 libgstreamer1.0-0 libgtk-3-common libgtk2.0-common libigdgmm11
libisl23 libjpeg-turbo-progs liblapack3 liblightdm-gobject-1-0 liblilv-0-0
libmfx1 libmp3lame0 libmpc3 libmpfr6 libmpg123-0 libmysofa1
libnet-dbus-perl libnorm1 libnotify4 libnuma1 libopenjp2-7 libopenmpt0
libpackagekit-glib2-18 libpam-gnome-keyring libpgm-5.3-0 libpixman-1-0
libplymouth5 libpocketsphinx3 libpostproc55 libquadmath0 librabbitmq4
librest-0.7-0 librubberband2 libsamplerate0 libserd-0-0 libshine3
libsigc++-2.0-0v5 libsnappy1v5 libsord-0-0 libsoup-gnome2.4-1 libsoxr0
libspeex1 libsphinxbase3 libsratom-0-0 libsrt1.4-gnutls libssh-gcrypt-4
libstartup-notification0 libstemmer0d libswresample3 libswscale5 libtheora0
libtie-ixhash-perl libturbojpeg0 libtwolame0 libunwind8 libva-drm2
libva-x11-2 libva2 libvdpau-va-gl1 libvdpau1 libvidstab1.1 libvorbisfile3
libvpx6 libwavpack1 libwnck-3-common libx11-protocol-perl libx264-160
libx265-192 libxatracker2 libxfce4ui-common libxfce4util-bin
libxfce4util-common libxfce4util7 libxfconf-0-3 libxfont2 libxklavier16
libxml-parser-perl libxml-twig-perl libxml-xpathengine-perl libxpresent1
libxres1 libxvidcore4 libxvmc1 libyaml-0-2 libzmq5 libzvbi-common libzvbi0
mesa-va-drivers mesa-vdpau-drivers ocl-icd-libopencl1 p11-kit
p11-kit-modules p7zip p7zip-full packagekit packagekit-tools plymouth
pocketsphinx-en-us python3-cairo python3-certifi python3-chardet
python3-cups python3-cupshelpers python3-dbus python3-gi python3-idna
python3-pkg-resources python3-requests python3-smbc python3-urllib3
python3-xdg qt5-style-plugin-cleanlooks qt5-style-plugin-motif
qt5-style-plugin-plastique system-config-printer-udev unzip va-driver-all
vdpau-driver-all x11-xserver-utils xauth xdg-utils xfconf xfonts-base
xfonts-encodings xfonts-utils xscreensaver-data xserver-common xserver-xorg
xserver-xorg-core xserver-xorg-input-all xserver-xorg-input-libinput
xserver-xorg-input-wacom xserver-xorg-legacy xserver-xorg-video-all
xserver-xorg-video-amdgpu xserver-xorg-video-ati xserver-xorg-video-fbdev
xserver-xorg-video-intel xserver-xorg-video-nouveau xserver-xorg-video-qxl
xserver-xorg-video-radeon xserver-xorg-video-vesa xserver-xorg-video-vmware
Use 'sudo apt autoremove' to remove them.
The following additional packages will be installed:
lxqt-themes
The following packages will be REMOVED:
desktop-base ffmpegthumbnailer galternatives gcr gir1.2-gtk-3.0
gir1.2-pango-1.0 gnome-keyring gpa gparted libavcodec58 libavfilter7
libavformat58 libayatana-ido3-0.4-0 libayatana-indicator3-7 libchromaprint1
libffmpegthumbnailer4v5 libgail-common libgail18 libgcr-ui-3-1 libgtk-3-
0
libgtk-3-bin libgtk2.0-0 libgtk2.0-bin libgtkmm-3.0-1v5 libpango-1.0-0
libpangocairo-1.0-0 libpangoft2-1.0-0 libpangomm-1.4-1v5 libpangoxft-1.0-0
librsvg2-2 librsvg2-common libthai-data libthai0 libwnck-3-0 libxfce4ui-2-0
lightdm lightdm-gtk-greeter lxqt-branding-debian lxqt-theme-debian
pinentry-gnome3 plymouth-label qt5-gtk-platformtheme qt5-gtk2-platformtheme
qt5-style-plugins system-config-printer system-config-printer-common
xarchiver xfwm4 xfwm4-theme-breeze xscreensaver
The following NEW packages will be installed:
lxqt-themes
0 upgraded, 1 newly installed, 50 to remove and 0 not upgraded.
Need to get 3,178 kB of archives.
After this operation, 97.5 MB disk space will be freed.
Do you want to continue? [Y/n]

[Bijan Soleymani]

On 2022-02-12 11:03, Stella Ashburne wrote:
> What should I do? What is the best course of action?

It seems that basic X windows or GUI apps are compiled with libthai support.

This is probably done in a way that they won't run without it being
installed (failed to load due to missing library).

If you remove it you probably won't be able to run those programs.

It would seem your options are:
1. Keep libthai installed

2. Remove it the way you are trying to do and lose all those GUI apps
and libraries

3. Remove it some sneaky that only removes libthai but leaves everything
else the same, and have things break and or apt/dpkg complain.

Bijan

[Stella Ashburne]

Hi,

> Sent: Sunday, February 13, 2022 at 12:35 AM
> From: "Bijan Soleymani" <bi...@psq.com>
> To: debia...@lists.debian.org
> Subject: Re: Uninstalling a package removes other essential packages: What is the best course of action?

>
>
> 3. Remove it some sneaky that only removes libthai but leaves everything
> else the same, and have things break and or apt/dpkg complain.
>

Could you show me how to do it please? Thanks.

Stella

[David]

On Sun, 13 Feb 2022 at 08:33, Stella Ashburne <rew...@gmx.com> wrote:

> > 3. Remove it some sneaky that only removes libthai but leaves everything
> > else the same, and have things break and or apt/dpkg complain.
> >
> Could you show me how to do it please? Thanks.

Hi Stella,

With a small effort, you can try something like this:
https://wiki.debian.org/Packaging/HackingDependencies

But, why do you care? There may be many packages installed
that you will never notice that you will never use.
Why pick on this one?

libthai appears to not occupy much disk space:

$ for n in $(dpkg -L libthai-data libthai0) ; do if [[ -f "$n" ]] &&
[[ ! -h "$n" ]] ; then ls -l "$n" ; fi ; done
-rw-r--r-- 1 root root 9314 2019-08-27 10:56
/usr/share/doc/libthai-data/changelog.Debian.gz
-rw-r--r-- 1 root root 28215 2018-08-01 15:08
/usr/share/doc/libthai-data/changelog.gz
-rw-r--r-- 1 root root 2450 2019-08-27 10:56
/usr/share/doc/libthai-data/copyright
-rw-r--r-- 1 root root 579256 2019-08-27 10:56 /usr/share/libthai/thbrk.tri
-rw-r--r-- 1 root root 41000 2019-08-27 10:56
/usr/lib/x86_64-linux-gnu/libthai.so.0.3.1
-rw-r--r-- 1 root root 9314 2019-08-27 10:56
/usr/share/doc/libthai0/changelog.Debian.gz
-rw-r--r-- 1 root root 28215 2018-08-01 15:08
/usr/share/doc/libthai0/changelog.gz

So there's hardly any win for the effort.

Alternatively, don't install lxqt-core. Only install what you want.
Some ideas here:
https://wiki.debian.org/ReduceDebian

Naturally this kind of thing takes time and effort which you may
or may not find is worthwhile depending on your goals, and
what you choose to spend productive time doing.

[David Wright]

On Sat 12 Feb 2022 at 17:03:06 (+0100), Stella Ashburne wrote:
> I did a minimal install of LXQt:
>
> sudo apt install lxqt-core lightdm
>
> and discovered that the following two packages were installed as well:
>
> libthai-data/stable,now 0.1.28-3 all [installed,automatic]
> libthai0/stable,now 0.1.28-3 amd64 [installed,automatic]

Installing those two would add 170 more packages to my system, so
I presume quite a lot more besides those two were installed on yours.

> *I do not speak or write Thai*

Nor I.

> When I did the following
>
> sudo apt remove libthai*
>
> I was very surprised to see that many packages that I think are essential to running Debian properly would be removed if I answered "Yes" to the question "Do you want to continue?"
>
> What should I do?

You should type:

$ apt-cache rdepends libthai0

and notice that the printed list includes libpango-1.0-0.
So now type:

$ apt-cache rdepends libpango-1.0-0 | less

and that shows the cause of your problem. Whether or not
you read Thai, in order to typeset a document that contains,
say, an aphorism in a foreign language, you need to at least
know how to lay out that language, which includes how its
words break or are spaced.

>From a very superficial reading of APT-ish metadata, I'd guess
that you might have spotted the language Thai because there
are some wrinkles in pango's support for it, and perhaps those
led to libthai* being linked to it.

Anyway, the upshot is that you'll have a job to run a system
without pango's support for text.

> What is the best course of action?

Leave it. Worry about bigger issues than the odd library.

Cheers,
David.

[Stella Ashburne]

Hello Dearie

I am happy to hear from you again and hope that everything's fine with you and your family.

> Sent: Sunday, February 13, 2022 at 6:23 AM
> From: "David" <bounci...@gmail.com>
> To: "debian-user" <debia...@lists.debian.org>

> Subject: Re: Uninstalling a package removes other essential packages: What is the best course of action?
>
>

> But, why do you care? There may be many packages installed
> that you will never notice that you will never use.
> Why pick on this one?
>
> libthai appears to not occupy much disk space:
>
>

> So there's hardly any win for the effort.
>

Indeed, you asked a very pertinent question.

"Why pick on this one?", you asked.

It just happens that this file was in my installed Debian. I have checked for other non-English files and found none other than Thai files.

"But, why do you care?" you wondered.

I care because I am worried that it may contain poorly designed code or backdoors that enable root privileges without my explicit intervention. Nobody has bothered to audit the Thai files that I mentioned for integrity and probable malicious activity.

> Alternatively, don't install lxqt-core. Only install what you want.
> Some ideas here:
> https://wiki.debian.org/ReduceDebian
>
> Naturally this kind of thing takes time and effort which you may
> or may not find is worthwhile depending on your goals, and
> what you choose to spend productive time doing.
>

You're right. I don't have the time nor the intellectual capacity to customize my Debian setup. I'll just have to look for other ways to install a custom Debian without foreign-language files.

[Stella Ashburne]

Hello Dearie

> Sent: Sunday, February 13, 2022 at 8:34 AM
> From: "David Wright" <deb...@lionunicorn.co.uk>
> To: debia...@lists.debian.org
> Subject: Re: Uninstalling a package removes other essential packages: What is the best course of action?

>
>
> Installing those two would add 170 more packages to my system, so

OMG

>
>
> > What is the best course of action?
>
> Leave it. Worry about bigger issues than the odd library.
>

For all you know, the odd library which is this Thai file in question may contain poorly designed code, ill-intentioned designed code or backdoors that enable(s) root privileges without a user's direct intervention.

Best regards.

Stella

[Andy Smith]

I think there is a more fundamental issue here, that may call in to
question whether Debian is suitable for you at all.

You focus on "foreign-language files" perhaps because with limited
experience these stand out to you as being worthless to you, so a
prime candidate for removal in the goal of having the most
slimmed-down and therefore secure operating system.

The problem is that this is antithetical to the entire way that
Debian is designed. Since Debian distributes binary packages,
someone at some point has to decide what optional features each
package will have baked into it, and everyone gets those (and all
their dependencies) whether they use those features or not.

Now in some cases the programs themselves can detect at runtime what
features are present and disable those that aren't. This enables the
package maintainer to split up the package into a core package and
several optional packages (might be "Recommends" rather than
"Depends" in Debian parlance). So in that case there is some degree
of control over what features are present.

Also there are some packages that can be compiled in such different
ways that they warrant having different variants with different
compile-time options. For example, there is exim-daemon-light which
does the basic job, but for a more feature-rich experience you'd
want exim-daemon-heavy, which is the same application but with many
extras compiled in and a much bigger dependency list as a result.

But these examples are outliers and most moderately complex packages
in Debian have just one variant and no modularity, so the maintainer
has erred on the side of features and enabled pretty much
everything.

Therefore what I am saying is, Debian starts from a position of
enabling and installing a lot of dependencies that you may never
use, so if you don't like that, you don't like Debian. I am
suggesting that the only reason why this isn't more obvious to you
is that you probably don't notice what (the fictional example)
libfoobarbaz3 might be, but you DO notice libthai and wonder why you
have Thai things on your system. Yet both things have the
possibility to include buggy code that an attacker might leverage.

The task you seem to want to set yourself, that of auditing what is
the minimal software requirement and only installing that, is a big
one. I am not convinced that it's a good use of time and on the
whole the risk proposition of having unused and unaudited code
sitting on your storage isn't that bad especially if you take other
steps to improve security ("defence in depth"). However, it is your
time to use as you please. I am suggesting that if you want to do
this, Debian may not be a great place to start from.

If you want an operating system where you have high levels of
customisation over how each and every package is compiled, such that
you can disable every feature that you don't need, I think you want
a source-based operating system like Gentoo, NixOS or Guix. Or you
could go for one like Arch where the core operating system is quite
small but you can build additional software to your whim:

https://wiki.archlinux.org/title/Arch_Build_System

If that "ports" style of system appeals, then you may even consider
going for something BSD-based like OpenBSD which tries to have a
very small and security-audited base OS, with additional software
compiled and added by the user through ports.

Cheers,
Andy

--
https://bitfolk.com/ -- No-nonsense VPS hosting

[Andy Smith]

Hello,

On Sun, Feb 13, 2022 at 07:36:55AM +0100, Stella Ashburne wrote:
> > From: "David Wright" <deb...@lionunicorn.co.uk>

> > Leave it. Worry about bigger issues than the odd library.
> >
> For all you know, the odd library which is this Thai file in
> question may contain poorly designed code, ill-intentioned
> designed code or backdoors that enable(s) root privileges without
> a user's direct intervention.

Wait until you find out that every single Intel CPU in the world has
a full install of Minix OS running inside of it.

General computing - it'll be the death of us!

[Andrew M.A. Cater]

Stella (and others)

This is apparently a long standing bug from pango1.0

Debian bug #565500

and has been outstanding for a decade or so. Thai poses interesting font,
formatting and display properties - if you're not Thai, it doesn't matter
to you, but, as you can see it's fairly well embedded into various
libraries.

It's about as relevant to you as the fact that the Debian installer supports
several languages: if you don't use them in install and set up the locales
they're essentially irrelevant but are there for the convenience of people
who need them.

Hope this helps.

With every good wish, as ever,

Andy Cater

[David Wright]

Tee-hee. We Brits can sneak our code into Debian without arousing
suspicion — we just label it "english". That's when we bother to
label it at all — Most of it just slips in as the default language
of Debian. And Linux. And computing in general. And the world.

Cheers,
David.

[Stella Ashburne]

Dearie

> Sent: Monday, February 14, 2022 at 1:02 AM

> From: "David Wright" <deb...@lionunicorn.co.uk>
> To: debia...@lists.debian.org
> Subject: Re: Uninstalling a package removes other essential packages: What is the best course of action?
>
>

> Tee-hee. We Brits can sneak our code into Debian without arousing
> suspicion — we just label it "english". That's when we bother to
> label it at all —

Indeed and the world is fortunate to have James and Jane Bond with their sidekick Q to maintain world peace.

Over here, we can count on Jason Bourne, Jack Ryan and Jack Reacher to do the same job.

In more recent memory, the real hero is undoubtedly Edward Snowden who revealed to the world the extent of NSA's snooping.

> Most of it just slips in as the default language
> of Debian.

Does Debian have a default language? What is it? Latin? Esperanto? American English?

Best regards.

Stella

[Stella Ashburne]

Hi Andy

> Sent: Sunday, February 13, 2022 at 9:14 PM
> From: "Andrew M.A. Cater" <amac...@einval.com>

> To: debia...@lists.debian.org
> Subject: Re: Uninstalling a package removes other essential packages: What is the best course of action?
>

> Stella (and others)
>
> This is apparently a long standing bug from pango1.0
>
> Debian bug #565500
>
> and has been outstanding for a decade or so.

And why has the decade-old bug not been resolved, may I ask? Won't it pose a security risk such as in escalation of root privileges?

> Thai poses interesting font,
> formatting and display properties - if you're not Thai, it doesn't matter
> to you, but, as you can see it's fairly well embedded into various
> libraries.

I wonder who embed Thai fonts and code in the first place..

> It's about as relevant to you as the fact that the Debian installer supports
> several languages: if you don't use them in install and set up the locales
> they're essentially irrelevant but are there for the convenience of people
> who need them.

Indeed, I don't use non-English language versions during install and/or set up Thai-specific locales but libthai still ends up in my installed system.

My concern is whether libthai poses a security risk to Debian users.

Best regards.

Stella

[The Wanderer]

On 2022-02-14 at 05:28, Stella Ashburne wrote:

> Hi Andy

>
>> From: "Andrew M.A. Cater" <amac...@einval.com>
>>

>> Stella (and others)
>>
>> This is apparently a long standing bug from pango1.0
>>
>> Debian bug #565500
>>
>> and has been outstanding for a decade or so.
>
> And why has the decade-old bug not been resolved, may I ask?

I have only a vague guess about this, based on reading the bug report
and the other bug reports (not all on the Debian bug tracker) linked
from it. Your guess on that front may well be as good as mine; have you
read those bug reports?

> Won't it pose a security risk such as in escalation of root
> privileges?

Only if libthai itself contains a security vulnerability which would
make such escalation possible - in which case it would be more important
and more appropriate to fix that bug than to fix this one.

>> Thai poses interesting font, formatting and display properties - if
>> you're not Thai, it doesn't matter to you, but, as you can see it's
>> fairly well embedded into various libraries.
>
> I wonder who embed Thai fonts and code in the first place..

I think you're reading this wrong.

If you look at the package description for libpango-1.0-0 (which, as
pointed out elsewhere, depends on libthai0 and is the reason why
libthai0 is installed on your system), you'll see that it says in part:

>>> Pango is a library for layout and rendering of text, with an
>>> emphasis on internationalization. Pango can be used anywhere
>>> that text layout is needed.

It includes layout-and-rendering support for many, many languages. What
this means in practice is that it implements a set of functions which
other programs can call when they want to delegate the task of laying
out and rendering text.

The benefit of using those functions when writing a program, rather than
handling the work yourself, is that A: you have less work to do, and B:
you can automatically get layout and rendering right for every language
the library supports, rather than having to worry about implementing
every single one of them yourself.

Most of the languages supported by Pango do not depend on
language-specific external libraries; the code to support them is either
internal to Pango, or contained in non-language-specific internal
libraries. The Thai language (and apparently also related languages,
such as Lao) is an exception, because the rules for laying it out and
rendering it are both sufficiently complex and sufficiently distinct
from those needed by most other languages that it was deemed better to
implement that logic as a separate library.

Any program that wants to let its text be translated into languages
which use layout, etc., rules that differ from the language in which
that text was written is likely to use libpango.

Because libpango provides this type of support for Thai by depending on
an external library, installing any of those programs will result in
installing not only libpango-1.0-0, but also libthai0.

None of those programs have embedded Thai fonts, or "Thai code"
(whatever one might intend that to mean) - at least not by this avenue,
and probably not at all. Rather, they have simply delegated layout and
rendering work to libpango, by calling appropriate functions (which will
cause the program to break if libpango is not available).

libpango has also not embedded either of those things. Rather, it has
delegated the task of laying out and rendering Thai-language text to
libthai, by calling appropriate functions (which will cause the library,
and the programs calling it, to break if libthai is not available).

If a program on your system is configured to display Thai text - for
example, if you go to a Website which contains text written in that
language, such as https://en.wikipedia.org/wiki/Thai_language, and
your browser is configured to display that Website as intended - then
very probably the program will call the functions in libpango, which
will recognize the Thai language and call the functions in libthai,
which will do the layout-and-rendering work, and return the result up
the stack, so that the program will be able to display the text correctly.

If no program on your system ever encounters Thai text in a way that
makes it want to call those functions, then the code in libthai will
never actually run on your system. (And therefore your system will not
be at risk from any security vulnerabilities contained in that code.)

Please note that the only way that Thai is special here is that its
support is provided by a language-specific external library. Pango
contains comparable support for many, many other languages, they're just
all implemented internally or using non-language-specific external
libraries.

Given that the intent of libpango is to provide support for layout and
rendering of all of these languages, the alternative to having it depend
on libthai0 would not be to omit the code which supports these things;
rather, it would be to include that code in libpango-1.0-0 itself
directly, where you'd never have noticed that it was present.

>> It's about as relevant to you as the fact that the Debian installer
>> supports several languages: if you don't use them in install and
>> set up the locales they're essentially irrelevant but are there for
>> the convenience of people who need them.
>
> Indeed, I don't use non-English language versions during install
> and/or set up Thai-specific locales but libthai still ends up in my
> installed system.

And you also don't use any of the other non-English languages for which
layout is supported by libpango (unless you happen to go to a Website
which has text in that language), but that also gets installed on your
system, so that the functions which programs use to delegate the
layout-and-rendering tasks are going to be available.

> My concern is whether libthai poses a security risk to Debian users.

Do you have any reason to believe that it might? As compared to any
other random library that Debian provides.

--
The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw

[Andrew M.A. Cater]

On Mon, Feb 14, 2022 at 11:18:12AM +0100, Stella Ashburne wrote:
> Dearie

>
> > Most of it just slips in as the default language
> > of Debian.
>
> Does Debian have a default language? What is it? Latin? Esperanto? American English?
>

Probably N. European English as learned in school - which covers most denizens
of the UK, Ireland, Netherlands, Germany, Austria, Switzerland - and also
Australia and NZ (and Commonwealth English - which is largely influenced
by British spelling - Canadian is a hybrid spelling.)

If English is not your first language, then your English will normally be
determined by where your English teacher studied.

This question came up - I think on debian-devel many years ago - and somebody
said, as I remember it: - "British/American English - it really doesn't matter
if you'll accept bad English" - and I think that's the right attitude.

Debian does support many languages - but the level of translation and
percentage of wiki/www.debian.org is significantly higher for some than for
others.

With every good wish, as ever,

Andy Cater

> Best regards.
>
> Stella
>

[David Wright]

On Mon 14 Feb 2022 at 11:18:12 (+0100), Stella Ashburne wrote:
> > Sent: Monday, February 14, 2022 at 1:02 AM
> > From: "David Wright" <deb...@lionunicorn.co.uk>
> >

> > Tee-hee. We Brits can sneak our code into Debian without arousing
> > suspicion — we just label it "english". That's when we bother to
> > label it at all —
>
> Indeed and the world is fortunate to have James and Jane Bond with their sidekick Q to maintain world peace.
>
> Over here, we can count on Jason Bourne, Jack Ryan and Jack Reacher to do the same job.
>
> In more recent memory, the real hero is undoubtedly Edward Snowden who revealed to the world the extent of NSA's snooping.
>
> > Most of it just slips in as the default language
> > of Debian.
>
> Does Debian have a default language? What is it? Latin? Esperanto? American English?

Perhaps the simplest way of answering this is to configure
your system with /etc/default/locale file as LANG=C.UTF-8,
and unset any specific i18n or L10n settings and see what
you get. Perhaps try again in 50 years: it could differ.

But in view of that single letter in your reply, and another
post on d-u, I'll not bother to continue this thread. I'm
just not interested in taking what looks to me like a
xenophobic approach to foreign language scripts or anything
else in Debian.

People who are genuinely concerned about security vulnerabilities
normally work on fixing them, rather than spreading insinuations
of conspiracies.

Cheers,
David.

[to...@tuxteam.de]

On Mon, Feb 14, 2022 at 05:14:36PM -0600, David Wright wrote:

[...]

> Perhaps the simplest way of answering this is to configure
> your system with /etc/default/locale file as LANG=C.UTF-8,
> and unset any specific i18n or L10n settings and see what
> you get. Perhaps try again in 50 years: it could differ.

I guess that is an avenue of investigation. still, I think
packages like a modern Web browser will pull in such
dependencies, either through the distro or (worse) bringing
in their own versions. A browser can't "know" which scripts
a Web page brings along and will insist in rendering Unicode
correctly.

> But in view of that single letter in your reply, and another
> post on d-u, I'll not bother to continue this thread. I'm
> just not interested in taking what looks to me like a
> xenophobic approach to foreign language scripts or anything
> else in Debian.

Please, hold your horses. Lack of knowledge sometimes might
come across as "xenophobic" -- things sometimes clear themselves
once knowledge grows. Give us people a chance to learn :-)

Cheers
--
t

[Emanuel Berg]

Andrew M.A. Cater wrote:

>> Does Debian have a default language? What is it? Latin?
>> Esperanto? American English?
>
> Probably N. European English as learned in school - which
> covers most denizens of the UK, Ireland, Netherlands,

> Germany, Austria, Switzerland [...]

Haha, English is thought all over the WORLD in schools :)

UK and Ireland BTW LOL :)

> This question came up - I think on debian-devel many years
> ago - and somebody said, as I remember it: -
> "British/American English - it really doesn't matter if
> you'll accept bad English" - and I think that's the
> right attitude.

Yeah, US English with all about computers that are
about computers. Obviously spellcheckers for different
languages if you want to spellcheck personal mails and stuff
in whatever language. Just because you are using a computer
doesn't mean what you do is _about_ computers, so then it is
OK to use whatever language.

But all programming, scripts etc that does things with
computers - US English. So no "colour" even, please. Why do it
wrong when it is so easy to do it right?

--
underground experts united
https://dataswamp.org/~incal

[David Wright]

On Tue 15 Feb 2022 at 07:48:57 (+0100), to...@tuxteam.de wrote:
> On Mon, Feb 14, 2022 at 05:14:36PM -0600, David Wright wrote:
>
> [...]
>
> > Perhaps the simplest way of answering this is to configure
> > your system with /etc/default/locale file as LANG=C.UTF-8,
> > and unset any specific i18n or L10n settings and see what
> > you get. Perhaps try again in 50 years: it could differ.
>
> I guess that is an avenue of investigation. still, I think
> packages like a modern Web browser will pull in such
> dependencies, either through the distro or (worse) bringing
> in their own versions. A browser can't "know" which scripts
> a Web page brings along and will insist in rendering Unicode
> correctly.

Oh, that's part of the investigation too. For example, I just typed
$ less /home/auser/.cache/mozilla/firefox/sole-random.default/cache2/entries/0*
and kept pressing → (the zero avoids too long a command line,
and → implicitly answers "no" to "binary file. See it anyway?").
That which isn't random text or numbers is almost all in the usual
"North Atlantic" English. For me, that it. Others might have
different results.

I'm afraid I won't be around in 50 years time.

> > But in view of that single letter in your reply, and another
> > post on d-u, I'll not bother to continue this thread. I'm
> > just not interested in taking what looks to me like a
> > xenophobic approach to foreign language scripts or anything
> > else in Debian.
>
> Please, hold your horses. Lack of knowledge sometimes might
> come across as "xenophobic" -- things sometimes clear themselves
> once knowledge grows. Give us people a chance to learn :-)

Look back: the OP has had plenty of help from me, and may well
in future. Just not in this thread, not beating up on libthai*
just because they're the only "non-English files" found by
the OP.

Cheers,
David.

[to...@tuxteam.de]

On Tue, Feb 15, 2022 at 10:09:35AM -0600, David Wright wrote:
> On Tue 15 Feb 2022 at 07:48:57 (+0100), to...@tuxteam.de wrote:

> > Please, hold your horses. Lack of knowledge sometimes might

> > come across as "xenophobic" [...]

> Look back: the OP has had plenty of help from me, and may well
> in future. Just not in this thread, not beating up on libthai*
> just because they're the only "non-English files" found by
> the OP.

Was just a shy attempt on my part. If I've failed to convince you,
it's my failure.

Nevermind

Cheers
--
t

[Stella Ashburne]

Dearie,

Thanks for your reply.

> Sent: Tuesday, February 15, 2022 at 2:48 PM
> From: to...@tuxteam.de

> To: debia...@lists.debian.org
> Subject: Re: Uninstalling a package removes other essential packages: What is the best course of action?
>
>

> Please, hold your horses. Lack of knowledge sometimes might
> come across as "xenophobic" -- things sometimes clear themselves
> once knowledge grows. Give us people a chance to learn :-)
>

We have to make allowance for the fact that some people are quick to judge others....

Best regards.

Stella

[to...@tuxteam.de]

On Tue, Feb 15, 2022 at 06:26:18PM +0100, Stella Ashburne wrote:
> Dearie,
>
> Thanks for your reply.

[...]

> We have to make allowance for the fact that some people are quick to judge others....

Right. But we have to make allowance for the fact that no one of us
is right all the time ;-)

Cheers
--
t

[Stella Ashburne]

> Sent: Tuesday, February 15, 2022 at 7:14 AM
> From: "David Wright" <deb...@lionunicorn.co.uk>

> To: debia...@lists.debian.org
> Subject: Re: Uninstalling a package removes other essential packages: What is the best course of action?
>
>

> But in view of that single letter in your reply, and another
> post on d-u, I'll not bother to continue this thread. I'm
> just not interested in taking what looks to me like a
> xenophobic approach to foreign language scripts or anything
> else in Debian.
>

My dear David,

I am surprised you are quick to pass judgments on people. I don't think that's you.

Me a xenophobe? Nothing can be further from the truth.

One of my parents is a diplomat and I spent a significant part of my childhood and adolescence in Asia and Latin America.

> People who are genuinely concerned about security vulnerabilities
> normally work on fixing them, rather than spreading insinuations
> of conspiracies.
>

You are right. I would fix them if I had the knowledge and competency.

Best regards.

Stella

[Stella Ashburne]

Hello The Wanderer

> Sent: Monday, February 14, 2022 at 8:48 PM
> From: "The Wanderer" <wand...@fastmail.fm>

> To: debia...@lists.debian.org
> Subject: Re: Uninstalling a package removes other essential packages: What is the best course of action?
>
>

> Do you have any reason to believe that it might? As compared to any
> other random library that Debian provides.
>

No, I don't have the technical knowledge to audit libthai. My point is that why pull in non-English dependencies for an English-language installation....Doing so may increase the chance of attacks by hackers.

The argument that an app, library or distro is open source does not really mitigate the risks of attacks.

Consider the below decade-old bugs that had been "hiding" in plain sight:

CVE-2016-5195 (Dirty COW)
CVE-2014-0160 (Heartbleed)
CVE-2016-8655
CVE-2017-6074
CVE-2021-3156 (Baron_Samedit)

Best regards.

Stella

[to...@tuxteam.de]

On Tue, Feb 15, 2022 at 06:35:46PM +0100, Stella Ashburne wrote:

[...]

> You are right. I would fix them if I had the knowledge and competency.

Back to the libthai thing. Perhaps it is unfixable nowadays: what shall
a browser do? Look at this harmless page [1]. Somewhere down there is
the Thai translation of the likewise harmless English word "water".

Your browser wouldn't be capable to represent that correctly without the
rendering capability provided by libthai, I guess.

(What I cant say is whether your browser is using the OS provided libthai,
via pango, or whether it has ingested an own version of pango with its
own version of libthai. This is left as an exercise for the reader).

In short: computers have grown up a lot since the good ol' days of ASCII.
Sometimes it's difficult to keep up.

Heck, I remember the times where there was a Germanized version of ASCII
(yeah, 7 bit, curly and square brackets, and I think backslash, solidus
and a couple of other innocent signs were sacrificed for the umlauts).

Needless to say, mixing C code with comments in German was... strange.

Then, the upper bit came, and we got Latin-1; but still you couldn't
have German and, say, Greek or Russian in the same text. Now I can just
say "γεια σου". That easy.

Yes, Unicode is a beast. But it reflects the chaotic and lively mess we
humans are! I don't want my ISO-8859-x back thankyouverymuch (but: a
friend of mine, who knows a lot, heartily disagrees with me: I might
be wrong, after all).

Cheers

[1] https://en.wiktionary.org/wiki/water/translations

--
t

[Stella Ashburne]

Dearie

> Sent: Wednesday, February 16, 2022 at 1:55 AM
> From: to...@tuxteam.de
> To: "Stella Ashburne" <rew...@gmx.com>
> Cc: debia...@lists.debian.org

> Subject: Re: Uninstalling a package removes other essential packages: What is the best course of action?
>
>

> Heck, I remember the times where there was a Germanized version of ASCII
> (yeah, 7 bit, curly and square brackets, and I think backslash, solidus
> and a couple of other innocent signs were sacrificed for the umlauts).
>
> Needless to say, mixing C code with comments in German was... strange.
>
> Then, the upper bit came, and we got Latin-1; but still you couldn't
> have German and, say, Greek or Russian in the same text. Now I can just
> say "γεια σου". That easy.
>

Gosh...you have just revealed your age....(my father's contemporary perhaps?)

Best regards.

Stella

[Kushal Kumaran]

You'll have to make your case in a bug report on the relevant package
(pango?). The usual debian position is to enable as many options as
possible, so that the same binary package will work for a wide variety
of users.

If this does not suit your security posture, you'll need to do one or
more of the following:

- take your concerns to the upstream developers (they might need more
concrete reasons than what you have so far)

- build the packages yourself with the offending features disabled

- uninstall the packages and manage without the additional packages that
get removed

- isolate the packages you have issues with (and everything that depends
on them) in separate virtual machines or other isolation mechanisms
that satisfy your security requirements

- pay someone to audit the codebase so your security needs are met (but
first check with upstream if they will be willing to act on issues
discovered during audit; if not you'll need other arrangements).
Perhaps you could offer to run one or more of the automated tools that
can help with finding security issues (there are various open-source
and proprietary tools in this area)

--
regards,
kushal

[Stefan Monnier]

> No, I don't have the technical knowledge to audit libthai. My point is that
> why pull in non-English dependencies for an English-language
> installation....Doing so may increase the chance of attacks by hackers.

It's pretty hard to know what might be needed and what not.
Even monolingual computer users may very well want to see characters
written in non-latin scripts on their screen. Whether it's math
symbols, emojis, or names of coworkers of Thai origins.

It's also hard to write the code in such a way that you can have support
for Thai scripts and latin scripts but not other scripts.

And of course, the same issue holds for completely different aspects
such as support for hardware devices you'll never use, or support for
file formats you'll never use, or support for specific features of your
programs which you'll never use.

If we could generate an installation image of Debian special-custom-made
to only support the functionality that you will use, and really remove
all the code and data that can be removed without affecting your
experience, I suspect that image would be *significantly* smaller.
And arguably more secure as well, as you point out.

But it's damn hard to do it automatically. And before we can start
doing it, we'd need to know the future (which functionality will you
use). So instead, we have to satisfy ourselves with the very crude
approximation offered by Debian's choice of packages to install :-(

Some distributions offer a bit more control, BTW. I'm thinking of
distributions like OpenWRT, or Gentoo. But what they offer is still
very crude compared to what could be done in theory, with unlimited
programmer-resources.


Stefan

[to...@tuxteam.de]

On Tue, Feb 15, 2022 at 07:00:59PM +0100, Stella Ashburne wrote:
> Dearie

[...]

> > Heck, I remember the times where there was a Germanized version of ASCII

[...]

> Gosh...you have just revealed your age....(my father's contemporary perhaps?)

Could well be :-)

Cheers
--
t

[The Wanderer]

On 2022-02-15 at 12:56, Stella Ashburne wrote:

> Hello The Wanderer

>> Do you have any reason to believe that it might? As compared to any
>> other random library that Debian provides.
>
> No, I don't have the technical knowledge to audit libthai. My point
> is that why pull in non-English dependencies for an English-language
> installation....

Because just because the main OS is configured to be in English, doesn't
mean there won't be a time when the user needs to read a document
written in that non-English language.

What if someone sends you a document that has one or more words written
in Thai? In order to be able to display that document correctly, the
computer will need code that knows how to handle the Thai language.
Whether that code is in libthai, or in a more general library, or
embedded directly in whatever program it is that's reading the document,
it's still there.

Even if you can be sure you'll never have any reason to want to read a
document that contains Thai, the same thing applies for every other
language that doesn't just use the same character set, etc., as English.
Most of them don't have sufficiently unusual and/or complex rules that
they need a dedicated library to handle them, as Thai apparently does,
but they do need something to handle whatever rules there may be.

> Doing so may increase the chance of attacks by hackers.

Not any more than pulling in any other dependency does.

> The argument that an app, library or distro is open source does not
> really mitigate the risks of attacks.

I hadn't made that argument, I don't think, so this seems like a non
sequitur.

[Stella Ashburne]

Hello

> Sent: Wednesday, February 16, 2022 at 10:04 AM

> From: "The Wanderer" <wand...@fastmail.fm>
> To: debia...@lists.debian.org
> Subject: Re: Uninstalling a package removes other essential packages: What is the best course of action?
>

> What if someone sends you a document that has one or more words written
> in Thai? In order to be able to display that document correctly, the
> computer will need code that knows how to handle the Thai language.
> Whether that code is in libthai, or in a more general library, or
> embedded directly in whatever program it is that's reading the document,
> it's still there.
>
> Even if you can be sure you'll never have any reason to want to read a
> document that contains Thai, the same thing applies for every other
> language that doesn't just use the same character set, etc., as English.
> Most of them don't have sufficiently unusual and/or complex rules that
> they need a dedicated library to handle them, as Thai apparently does,
> but they do need something to handle whatever rules there may be.
>

So why not create libraries for Burmese, Laotian and Cambodian (Khmer) languages? Why don't we have libburmese, liblaotian and libkhmer and make them essential dependencies for libpango?

Best regards.

Stella

[The Wanderer]

On 2022-02-16 at 08:31, Stella Ashburne wrote:

> Hello

>> What if someone sends you a document that has one or more words
>> written in Thai? In order to be able to display that document
>> correctly, the computer will need code that knows how to handle the
>> Thai language. Whether that code is in libthai, or in a more
>> general library, or embedded directly in whatever program it is
>> that's reading the document, it's still there.
>>
>> Even if you can be sure you'll never have any reason to want to
>> read a document that contains Thai, the same thing applies for
>> every other language that doesn't just use the same character set,
>> etc., as English. Most of them don't have sufficiently unusual
>> and/or complex rules that they need a dedicated library to handle
>> them, as Thai apparently does, but they do need something to handle
>> whatever rules there may be.
>
> So why not create libraries for Burmese, Laotian and Cambodian
> (Khmer) languages? Why don't we have libburmese, liblaotian and
> libkhmer and make them essential dependencies for libpango?

There are a few possible answers.

A: Because the rules for handling those languages are similar enough to
those used for other languages that they can be handled by the
non-language-specific code already built in to libpango, but the rules
for handling Thai are not.

B: Because the rules for handling those languages are similar enough to
those used for Thai that they can be handled by the code already present
in libthai, so there's no need for another library.

C: Because the people who wrote the language-specific code to handle
those languages decided to write it as part of libpango, rather than as
an external library which libpango can depend on.

I don't know which of those answers is accurate, and I can't rule out
that other answers may be possible as well, but those are the
possibilities that come quickly to mind.

It may be instructive to note that the listed maintainer of libthai0 is
also the person who filed bug 620001, against libpango, about a
rendering issue that affects (affected?) both Lao and Thai. This leaves
me thinking that option B is probably less likely than the others, but I
don't know that for certain.

[to...@tuxteam.de]

On Wed, Feb 16, 2022 at 02:31:21PM +0100, Stella Ashburne wrote:
> Hello

[...]

> So why not create libraries for Burmese, Laotian and Cambodian (Khmer) languages? Why don't we have libburmese, liblaotian and libkhmer and make them essential dependencies for libpango?

So why not do your research yourself?

;-)

As far as I can see [1], Thai standardisation is the farthest
along. I guess Burmese, Laotian and Cambodian are waiting for
helping hands (yours, perhaps?).

Perhaps we get a libmranmabhasa, then, who knows?

Cheers

[1] https://en.wikibooks.org/wiki/FOSS_Localization/Localization_Efforts_in_the_Asia-Pacific

--
t

[Curt]

On 2022-02-16, <to...@tuxteam.de> <to...@tuxteam.de> wrote:
>
>> So why not create libraries for Burmese, Laotian and Cambodian (Khmer) la=
> nguages? Why don't we have libburmese, liblaotian and libkhmer and make the=

> m essential dependencies for libpango?
>
> So why not do your research yourself?
>
> ;-)
>

Of course, it’s an excellent question. But the problem, you see, when you ask
why something happens, how does a person answer why something happens? For
example, Aunt Minnie is in the hospital. Why? Because she went out, slipped on
the ice, and broke her hip. That satisfies people. It satisfies, but it
wouldn’t satisfy someone who came from another planet and knew nothing about
why when you break your hip do you go to the hospital. How do you get to the
hospital when the hip is broken? Well, because her husband, seeing that her hip
was broken, called the hospital up and sent somebody to get her. All that is
understood by people. And when you explain a why, you have to be in some
framework that you allow something to be true. Otherwise, you’re perpetually
asking why.

https://fs.blog/richard-feynman-on-why-questions/

Stella!!!!!!!!!!!

[David Wright]

Tomas's question seems to me more rhetorical than a scientific inquiry.
Great video, though. Thanks.

Cheers,
David.

[to...@tuxteam.de]

On Wed, Feb 16, 2022 at 02:37:02PM -0600, David Wright wrote:
> On Wed 16 Feb 2022 at 15:38:22 (-0000), Curt wrote:
> > On 2022-02-16, <to...@tuxteam.de> <to...@tuxteam.de> wrote:

[...]

> > > So why not do your research yourself?
> > >
> > > ;-)
> >

> > Of course, it’s an excellent question [...]

> > https://fs.blog/richard-feynman-on-why-questions/
>
> Tomas's question seems to me more rhetorical than a scientific inquiry.

In a way, yes. I was trying my best to animate people to look into stuff.
The answer is, nevertheless, a good read.

> Great video, though. Thanks.

Absolutely.

Cheers
--
t

[Stella Ashburne]

Dearie

> Sent: Wednesday, February 16, 2022 at 10:05 PM
> From: to...@tuxteam.de

> To: debia...@lists.debian.org
> Subject: Re: Uninstalling a package removes other essential packages: What is the best course of action?
>
>

> So why not do your research yourself?
>

Honestly I don't know where to start.

You're my daddy's contemporary and besides, I wasn't even born when Linux or Debian burst onto the scene.

> As far as I can see [1], Thai standardisation is the farthest
> along. I guess Burmese, Laotian and Cambodian are waiting for
> helping hands (yours, perhaps?).
>

I do not possess the technical skills to accomplish it.

Best regards.

Stella

[Stella Ashburne]

Dearie

> Sent: Wednesday, February 16, 2022 at 9:45 PM

> From: "The Wanderer" <wand...@fastmail.fm>
> To: debia...@lists.debian.org
> Subject: Re: Uninstalling a package removes other essential packages: What is the best course of action?
>
>

> There are a few possible answers.
>

I love reading your answers and found them to be informative. And I appreciate your effort and time spent on writing them.

Best regards.

Stella

[to...@tuxteam.de]

On Thu, Feb 17, 2022 at 07:05:33AM +0100, Stella Ashburne wrote:
> Dearie
>
> > Sent: Wednesday, February 16, 2022 at 10:05 PM
> > From: to...@tuxteam.de
> > To: debia...@lists.debian.org
> > Subject: Re: Uninstalling a package removes other essential packages: What is the best course of action?
> >
> >
> > So why not do your research yourself?
> >
> Honestly I don't know where to start.

There are, of course, many ways to go about it. And, of course, it
has the potential to eat all the time resources available, and then
some. So everyone has to choose where to cut :)

I'll present one way here, which always reminds me of the incredible
gift we have: access to most of the source code for the things we
use. For our case (libthai), start with apt. The library package is
called libthai0, so (I'm on buster; YMMV):

tomas@trotzki:~$ apt rdepends libthai0
libthai0
Reverse Depends:
Depends: libthai-dev (= 0.1.28-3)
Depends: php-wikidiff2 (>= 0.1.25)
Depends: libsombok3 (>= 0.1.12)
Depends: scim-thai (>= 0.1.12)
Suggests: libqt5core5a
Depends: libpango-1.0-0 (>= 0.1.25)
Depends: libm17n-0 (>= 0.1.12)
Depends: ibus-libthai (>= 0.1.19)
Breaks: libthai-data (<< 0.1.10)
Depends: gtk-im-libthai (>= 0.1.12)
Depends: gtk3-im-libthai (>= 0.1.12)

That gives you the "reverse dependencies", i.e. which packages do
depend on libthai? Many of those (roughly: those having "im" in
their name) are "input methods". Also that ibus- thing. The two
dependencies with potential to "spread" are libpango (nearly
everything rendering text these days uses that) and libqt5core5a
(if you are using Qt applications).

Let's have a look at this libpango-1.0-0:

tomas@trotzki:~$ apt show libpango-1.0-0
Package: libpango-1.0-0
Version: 1.46.2-3
Priority: optional
Section: libs
Source: pango1.0
Maintainer: Debian GNOME Maintainers <pkg-gnome-...@lists.alioth.debian.org>
Installed-Size: 441 kB
Depends: fontconfig (>= 2.1.91), libc6 (>= 2.14), libfribidi0 (>= 1.0.0), libglib2.0-0 (>= 2.61.2), libharfbuzz0b (>= 2.1.1), libthai0 (>= 0.1.25)
[...]

So the source package is pango1.0. You could install the source
package and have a look into it, but Debian offers you:

https://sources.debian.org/

Enter "pango1.0" into that little box ("by package name"). If
you're bold, you can just stick that into the URL

https://sources.debian.org/search/pango1.0/

You click on that one URL and there you have the sources, nicely
sorted by Debian version. Click on yours (mine is buster). You'll
notice that little box on the right labelled "search" (there's
also a dropdown: we'll ignore that). It is pre-set with
"package:pango1.0". We add to it (separated by a space) "libthai"
and click on "search".

Now it searches all of pango's sources for occurrences of libthai.

I'll leave that here. Explore. Come back with questions. And mind
those rabbit holes. Only pick the enjoyable ones :)

Cheers
--
t

[Curt]

Actually, I wanted to allude to Stella but should've obviously just
responded to one of *her* posts.

And when Feynman refers to someone from another planet I think instead
of AI, and how deep you have to go in knowledge of all sorts, in
successively deeper frameworks of truth, before you can arrive at what
we do "naturally."


> Cheers,
> David.
>
>


--

[Curt]

On 2022-02-17, <to...@tuxteam.de> <to...@tuxteam.de> wrote:
>
> --Isw399PmXxwTK8QE
> Content-Type: text/plain; charset=utf-8
> Content-Disposition: inline
> Content-Transfer-Encoding: quoted-printable

>
> On Wed, Feb 16, 2022 at 02:37:02PM -0600, David Wright wrote:
>> On Wed 16 Feb 2022 at 15:38:22 (-0000), Curt wrote:
>> > On 2022-02-16, <to...@tuxteam.de> <to...@tuxteam.de> wrote:
>
> [...]
>
>> > > So why not do your research yourself?
>> > >
>> > > ;-)

>> > =20
>> > Of course, it=E2=80=99s an excellent question [...]
>
>> > https://fs.blog/richard-feynman-on-why-questions/
>>=20

>> Tomas's question seems to me more rhetorical than a scientific inquiry.
>
> In a way, yes. I was trying my best to animate people to look into stuff.
> The answer is, nevertheless, a good read.

Yeah, I really meant to refer to Stella, sorry.

>> Great video, though. Thanks.
>
> Absolutely.
>
> Cheers

> --=20
> t
>
> --Isw399PmXxwTK8QE
> Content-Type: application/pgp-signature; name="signature.asc"
>
>
> --Isw399PmXxwTK8QE--
>
>


--

[to...@tuxteam.de]

On Thu, Feb 17, 2022 at 09:41:30AM -0000, Curt wrote:
> On 2022-02-17, <to...@tuxteam.de> <to...@tuxteam.de> wrote:

[...]

> > On Wed, Feb 16, 2022 at 02:37:02PM -0600, David Wright wrote:

[...]

> >> Tomas's question seems to me more rhetorical than a scientific inquiry.
> >
> > In a way, yes. I was trying my best to animate people to look into stuff.
> > The answer is, nevertheless, a good read.
>
> Yeah, I really meant to refer to Stella, sorry.

No need. I enjoyed the exchange. All of it.

Cheers
--
t

[to...@tuxteam.de]

On Thu, Feb 17, 2022 at 09:40:40AM -0000, Curt wrote:
> On 2022-02-16, David Wright <deb...@lionunicorn.co.uk> wrote:

[...]

> > Tomas's question seems to me more rhetorical than a scientific inquiry.
> > Great video, though. Thanks.
>
> Actually, I wanted to allude to Stella but should've obviously just
> responded to one of *her* posts.
>
> And when Feynman refers to someone from another planet I think instead
> of AI, and how deep you have to go in knowledge of all sorts, in
> successively deeper frameworks of truth, before you can arrive at what
> we do "naturally."

Add to it: "it's a process, not a state", and then you've got the whole
mess :)

Cheers
--
t

[Jonathan Dowland]

On Mon, Feb 14, 2022 at 11:28:18AM +0100, Stella Ashburne wrote:
>I wonder who embed Thai fonts and code in the first place..

อย่าเหยียดเชื้อชาติ



--
Please do not CC me for listmail.

👱🏻 Jonathan Dowland
✎ jm...@debian.org
🔗 https://jmtd.net

[Tixy]

On Thu, 2022-02-17 at 10:02 +0000, Jonathan Dowland wrote:
> On Mon, Feb 14, 2022 at 11:28:18AM +0100, Stella Ashburne wrote:
> > I wonder who embed Thai fonts and code in the first place..
>
> อย่าเหยียดเชื้อชาติ

+1

--
Tixy