From the «text is good enough» department:
Title: Using (only) a Linux terminal for my personal computing in 2024
Author: Thom Holwerda
Date: Sun, 24 Nov 2024 22:13:32 +0000
Link: https://www.osnews.com/story/141194/using-only-a-linux-terminal-for-my-personal-computing-in-2024/

A month and a bit ago, I wondered if I could cope with a terminal-only
computer[1].
[…]

The only way to really find out was to give it a go.

My goal was to see what it was like to use a terminal-only computer for my
personal computing for two weeks, and more if I fancied it.
↫ Neil’s blog[2]

I tried to do this too, once.

Once.

Doing everything from the terminal just isn’t viable for me, mostly because I
didn’t grow up with it. Our family’s first computer ran MS-DOS (with a Windows
3.1 installation we never used), and I’m pretty sure the experience of using
MS-DOS as my first CLI ruined me for life. My mental model for computing didn’t
start forming properly until Windows 95 came out, and as such, computing is
inherently graphical for me, and no matter how many amazing CLI and TUI
applications are out there – and there are many, many amazing ones – my brain
just isn’t compatible with it.

There are a few tasks I prefer doing with the command line, like updating my
computers or editing system files using Nano, but for everything else I’m just
faster and more comfortable with a graphical user interface. This comes down to
not knowing most commands by heart, and often not even knowing the options and
flags for the most basic of commands, meaning even very basic operations that
people comfortable using the command line do without even thinking, take me
ages.

I’m glad any modern Linux distribution – I use Fedora KDE on all my computers –
offers both paths for almost anything you could do on your computer, and unless
I specifically opt to do so, I literally – literally literally – never have to
touch the command line.

Links:
[1]: https://neilzone.co.uk/2024/10/could-i-cope-with-a-terminal-only-computer/ (link)
[2]: https://neilzone.co.uk/2024/11/using-only-a-linux-terminal-for-my-personal-computing-in-2024/ (link)

On Mon, 25 Nov 2024, Retrograde wrote:

> From the «text is good enough» department:
> Title: Using (only) a Linux terminal for my personal computing in 2024
> Author: Thom Holwerda
> Date: Sun, 24 Nov 2024 22:13:32 +0000
> Link: https://www.osnews.com/story/141194/using-only-a-linux-terminal-for-my-personal-computing-in-2024/
>
>
> A month and a bit ago, I wondered if I could cope with a terminal-only
> computer[1].
> […]
>
> The only way to really find out was to give it a go.
>
> My goal was to see what it was like to use a terminal-only computer for my
> personal computing for two weeks, and more if I fancied it.
> ↫ Neil’s blog[2]
>
> I tried to do this too, once.
>
> Once.
>
> Doing everything from the terminal just isn’t viable for me, mostly because I
> didn’t grow up with it. Our family’s first computer ran MS-DOS (with a Windows
> 3.1 installation we never used), and I’m pretty sure the experience of using
> MS-DOS as my first CLI ruined me for life. My mental model for computing didn’t
> start forming properly until Windows 95 came out, and as such, computing is
> inherently graphical for me, and no matter how many amazing CLI and TUI
> applications are out there – and there are many, many amazing ones – my brain
> just isn’t compatible with it.
>
> There are a few tasks I prefer doing with the command line, like updating my
> computers or editing system files using Nano, but for everything else I’m just
> faster and more comfortable with a graphical user interface. This comes down to
> not knowing most commands by heart, and often not even knowing the options and
> flags for the most basic of commands, meaning even very basic operations that
> people comfortable using the command line do without even thinking, take me
> ages.
>
> I’m glad any modern Linux distribution – I use Fedora KDE on all my computers –
> offers both paths for almost anything you could do on your computer, and unless
> I specifically opt to do so, I literally – literally literally – never have to
> touch the command line.
>
> Links:
> [1]: https://neilzone.co.uk/2024/10/could-i-cope-with-a-terminal-only-computer/ (link)
> [2]: https://neilzone.co.uk/2024/11/using-only-a-linux-terminal-for-my-personal-computing-in-2024/ (link)
>

Fascinating experiment. I would not be able to do it. I need a browser to
run my business, manage my finances etc. so terminal only, while nice,
would be very difficult without some serious programming and hacking
around problems.

On 25 Nov 2024 13:34:25 GMT, Retrograde wrote:

> This comes down to not knowing most commands by heart,
> and often not even knowing the options and flags for the most basic of
> commands ...

Don’t need to. Type “man «cmd»” to see all the details of the options
available for any external command. I do this all the time.

> I’m glad any modern Linux distribution – I use Fedora KDE on all my
> computers – offers both paths for almost anything you could do on your
> computer, and unless I specifically opt to do so, I literally –
> literally literally – never have to touch the command line.

Also, running a command line through a GUI terminal emulator lets you take
advantage of cut/copy/paste between windows, which is a feature not
available on a pure-command-line system.

Retrograde <fungus@amongus.com.invalid> wrote:
> From the ?text is good enough? department:
> Title: Using (only) a Linux terminal for my personal computing in 2024
> Author: Thom Holwerda
> Date: Sun, 24 Nov 2024 22:13:32 +0000
> Link: https://www.osnews.com/story/141194/using-only-a-linux-terminal-for-my-personal-computing-in-2024/
>
>
> A month and a bit ago,?I wondered if I could cope with a terminal-only
> computer[1].
> [?]
>
> The only way to really find out was to give it a go.

I am glad you tried, sure it was a nice and very different
experience.

<snip>
>
> Doing everything from the terminal just isn't viable for me,
> mostly because I didn't grow up with it.

Fair enough, but at least you tried to see what things were
like for us old people. But yes, big changes like this are
hard to deal with.

I started before DOS existed on minis and I remember when
GUIs became a thing. I had to be dragged kicking and
screaming into that environment :) Still I pretty much live
in Xterms and only need a GUI for browsing and html email.

<snip>

Nice post!

--
csh(1) - "An elegant shell, for a more... civilized age."
- Paraphrasing Star Wars

Lawrence D'Oliveiro <ldo@nz.invalid> writes:

> Also, running a command line through a GUI terminal emulator lets you take
> advantage of cut/copy/paste between windows, which is a feature not
> available on a pure-command-line system.

The command line is like language. The GUI is like shopping.

Turns out, lots of my highly educated friends aren't all that good
with language. :-o

A windowing system is not in itself what most people mean by GUI and
is, yes, a huge leap forward over plain command-line terminals.

I do use a GUI browser and, occasionally, a GUI image editing device.
I can imagine that audio/video editing my work best in a full GUI.

But my default is a simple window manager (twm) on top of X with
numerous xterms open or iconified, some running things like dmesg -w,
one with root access etc.

I took one look, long ago, at Windows 95 and moved straight to Linux.
Took one look at KDE (shopping) and found twm.

FWIW,
--
Mike Spencer Nova Scotia, Canada

Lawrence D'Oliveiro <ldo@nz.invalid> wrote:

> Also, running a command line through a GUI terminal emulator lets you take
> advantage of cut/copy/paste between windows, which is a feature not
> available on a pure-command-line system.

I still can use Cut&Paste on Linux's "real VTs" but I'd prefer a
decorationless fullscreen XTerm over those if I would try to work
GUIfree for a while because of easier size switching, Sixel and TeK40xx
graphics.

Screen and Tmux would offer (keyboard driven) Cut&Paste.

There now may be framebuffer terminals with most of the features of
XTerm, but testing those still is crying for attention in my eternally
growing (™Dark Energy Inside!™) to do list. *sigh!*

--
1. Hitchhiker 5: (101) "You just come along with me and have a good
time. The Galaxy's a fun place. You'll need to have this fish in your
ear."

On Tue, 26 Nov 2024, John McCue wrote:

> Retrograde <fungus@amongus.com.invalid> wrote:
>> From the ?text is good enough? department:
>> Title: Using (only) a Linux terminal for my personal computing in 2024
>> Author: Thom Holwerda
>> Date: Sun, 24 Nov 2024 22:13:32 +0000
>> Link: https://www.osnews.com/story/141194/using-only-a-linux-terminal-for-my-personal-computing-in-2024/
>>
>>
>> A month and a bit ago,?I wondered if I could cope with a terminal-only
>> computer[1].
>> [?]
>>
>> The only way to really find out was to give it a go.
>
> I am glad you tried, sure it was a nice and very different
> experience.
>
> <snip>
>>
>> Doing everything from the terminal just isn't viable for me,
>> mostly because I didn't grow up with it.
>
> Fair enough, but at least you tried to see what things were
> like for us old people. But yes, big changes like this are
> hard to deal with.
>
> I started before DOS existed on minis and I remember when
> GUIs became a thing. I had to be dragged kicking and
> screaming into that environment :) Still I pretty much live
> in Xterms and only need a GUI for browsing and html email.

Through the wonders of alpine, atleast you can do html email in the
terminal as well! =)

I use the gui for web browsing, reading pdf:s and libreoffice. The rest
sits in the terminal (email, programming/scripting, tinkering, reading
text files).

I have been thinking about moving the reading part of web browsing into
the terminal as well, but haven't found a browser I'm happy with. Modern
web sites tend to become too messed up when viewed in the terminal. Maybe
it would be possible to write a kind of "pre-processor" that formats web
sites with a text based browser in mind?

> <snip>
>
> Nice post!
>
>

D <nospam@example.net> wrote:

> I have been thinking about moving the reading part of web browsing
> into the terminal as well, but haven't found a browser I'm happy
> with.

I use Elinks, Emacs/EWW and W3m, but none of them can replace the scary
fullfat browsers. They seem to just fit Smolweb stuff (FTP, Gemini,
Gopher and similar).

> Maybe it would be possible to write a kind of "pre-processor" that
> formats web sites with a text based browser in mind?

Despite me finding this solution really scary, something like that
indeed exists:

<https://www.brow.sh/>

--
4. Hitchhiker 11:
(72) "Watch the road!'' she yelped.
(73) "Shit!"

On Tue, 26 Nov 2024, yeti wrote:

> D <nospam@example.net> wrote:
>
>> I have been thinking about moving the reading part of web browsing
>> into the terminal as well, but haven't found a browser I'm happy
>> with.
>
> I use Elinks, Emacs/EWW and W3m, but none of them can replace the scary
> fullfat browsers. They seem to just fit Smolweb stuff (FTP, Gemini,
> Gopher and similar).

True.

>> Maybe it would be possible to write a kind of "pre-processor" that
>> formats web sites with a text based browser in mind?
>
> Despite me finding this solution really scary, something like that
> indeed exists:
>
> <https://www.brow.sh/>

Ah yes... I've seen this before! I did drop it due to its dependency on
FF, but the concept is similar. My idea was to aggressively filter a web
page before passing it on to elinks or similar.

Perhaps rewriting it a bit in order to avoid the looooooong list of menu
options or links that always come up at the top of the page, before the
content of the page shows after a couple of page downs (this happens for
instance if I go to wikipedia).

Instead parsing it, and adding those links at the bottom, removing
javascript, and perhaps passing on only the text. Well, those are only
ideas. Maybe I'll try, maybe I won't. Time will tell! =)

On Tue, 26 Nov 2024 09:22:50 +0042, yeti wrote:

> Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>
>> Also, running a command line through a GUI terminal emulator lets you
>> take advantage of cut/copy/paste between windows, which is a feature
>> not available on a pure-command-line system.
>
> I still can use Cut&Paste on Linux's "real VTs" but I'd prefer a
> decorationless fullscreen XTerm over those if I would try to work
> GUIfree for a while because of easier size switching, Sixel and TeK40xx
> graphics.

But then it becomes difficult to have more than one terminal session open
at once.

I typically have about two dozen.

On 26 Nov 2024 03:18:45 -0400, Mike Spencer wrote:

> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>
>> Also, running a command line through a GUI terminal emulator lets you
>> take advantage of cut/copy/paste between windows, which is a feature
>> not available on a pure-command-line system.
>
> The command line is like language. The GUI is like shopping.

Did you learn in Comp Sci about the concept of “abstract machines”? To
program a computer, you start with the bare hardware, and add layers of
software on top of that, each creating a new “abstract machine” that is
easier to use for narrower and narrower classes of problems, albeit less
flexible than the machine layer below.

The command line is itself such an abstract machine, and you can create
additional layers on top of that by writing shell scripts.

GUIs, on the other hand, are not suited to having any additional layers
built on top of them. They are designed to be used by humans, and that’s
that. Attempts to automate GUI operations tend not to work very well.

> Took one look at KDE (shopping) and found twm.

KDE Konsole is probably the most versatile of all the GUI terminal
emulators.

D <nospam@example.net> wrote:
> On Tue, 26 Nov 2024, yeti wrote:
>> D <nospam@example.net> wrote:
>>> I have been thinking about moving the reading part of web browsing
>>> into the terminal as well, but haven't found a browser I'm happy
>>> with.
>>
>> I use Elinks, Emacs/EWW and W3m, but none of them can replace the scary
>> fullfat browsers. They seem to just fit Smolweb stuff (FTP, Gemini,
>> Gopher and similar).
>
> True.

I like seeing useful images, so prefer Dillo and Links (the latter
does support display via the framebuffer so you can run it
graphically without X).

>>> Maybe it would be possible to write a kind of "pre-processor" that
>>> formats web sites with a text based browser in mind?
>>
>> Despite me finding this solution really scary, something like that
>> indeed exists:
>>
>> <https://www.brow.sh/>
>
> Ah yes... I've seen this before! I did drop it due to its dependency on
> FF, but the concept is similar. My idea was to aggressively filter a web
> page before passing it on to elinks or similar.
>
> Perhaps rewriting it a bit in order to avoid the looooooong list of menu
> options or links that always come up at the top of the page, before the
> content of the page shows after a couple of page downs (this happens for
> instance if I go to wikipedia).

Lucky if it's just a couple of page-downs, I can easily be
hammering the button on some insane pages where 10% is the actual
content and 90% is menu links. Often it's quicker to press End
and work up from the bottom, but many websites have a few pages of
junk at the bottom too now, so you have to hunt for the little
sliver of content in the middle.

> Instead parsing it, and adding those links at the bottom, removing
> javascript, and perhaps passing on only the text.

A similar approach is taken by frogfind.com, except rather than
parsing the links and putting them at the end, it detetes them,
which makes it impossible to navigate many websites. It does the
other things you mention, but the link rewriting would probably be
the hardest part to get right with a universal parser.

Site-specific front-ends are a simpler goal. This is a list of ones
that work in Dillo, and therefore without Javascript:
https://alex.envs.net/dillectory/

Of course then you have the problem of them breaking as soon as the
target site/API changes or blocks them.

--
__ __
#_ < |\| |< _#

D <nospam@example.net> writes:

> On Tue, 26 Nov 2024, yeti wrote:
>
>> <https://www.brow.sh/>
>
> Ah yes... I've seen this before! I did drop it due to its dependency on
> FF, but the concept is similar. My idea was to aggressively filter a web
> page before passing it on to elinks or similar.
>
> Perhaps rewriting it a bit in order to avoid the looooooong list of menu
> options or links that always come up at the top of the page, before the
> content of the page shows after a couple of page downs (this happens for
> instance if I go to wikipedia).
>
> Instead parsing it, and adding those links at the bottom, removing
> javascript, and perhaps passing on only the text. Well, those are only
> ideas. Maybe I'll try, maybe I won't. Time will tell! =)

I've done this for a few individual sites that I visit frequently.

+ A link to that site resides on my browser's "home" page.

+ That home page is a file in ~/html/ on localhost.

+ The link is actually to a target-specific cgi-bin Perl script on
localhost where Apache is running, restricted to requests from
localhost.

+ The script takes the URL sent from the home page, rewrites it for
the routable net, sends it to the target using wget and reads all
of the returned data into a variable.

+ Using Perl's regular expressions, stuff identified (at time of
writing the script) as unwanted is elided -- js, style, svg,
noscript etc. URLs self-referencing the target are rewritten to
to be sent through the cgi-bin script.

+ Other tweaks peculiar to the specific target...

+ Result is handed back to the browser preceded by minimal HTTP
headers.

So far, works like a charm. Always the potential that a target host
will change their format significantly. That has happened a couple of
times, requiring fetching an unadorned copy of the target's page,
tedious reading/parsing and edit to the script.

This obviously doesn't work for those sites that initially send a
dummy all-js page to verify that you have js enabled and send you a
condescending reproof if you don't. Other server-side dominance games
a potential challenge or a stone wall.

Writing a generalized version, capable of dealing with pages from
random/arbitrary sites is a notion perhaps worth pursuing but clearly
more of a challenge than site-specific scripts. RSN, round TUIT etc.

--
Mike Spencer Nova Scotia, Canada

On Tue, 27 Nov 2024, Computer Nerd Kev wrote:

> D <nospam@example.net> wrote:
>> On Tue, 26 Nov 2024, yeti wrote:
>>> D <nospam@example.net> wrote:
>>>> I have been thinking about moving the reading part of web browsing
>>>> into the terminal as well, but haven't found a browser I'm happy
>>>> with.
>>>
>>> I use Elinks, Emacs/EWW and W3m, but none of them can replace the scary
>>> fullfat browsers. They seem to just fit Smolweb stuff (FTP, Gemini,
>>> Gopher and similar).
>>
>> True.
>
> I like seeing useful images, so prefer Dillo and Links (the latter
> does support display via the framebuffer so you can run it
> graphically without X).

For some reason, I never managed to get the framebuffer to work. Have no
idea why. =( I would like to get it to work though. Dillo was a good tip!
I did play with it for a bit, but then forgot about it. Maybe the reason
was a lack of tabs or buffers. I think links or maybe it was elinks, had a
way for me to replicate tabs or vi buffers in the browser. It was super
convenient!

Basically my ideal would be to move all my "reading" to a text based
browser, so that I would only have to keep work related stuff in the
massive GUI browser. All the other 60+ tabs, would live in the text
browser where I would reference them when needed.

>>>> Maybe it would be possible to write a kind of "pre-processor" that
>>>> formats web sites with a text based browser in mind?
>>>
>>> Despite me finding this solution really scary, something like that
>>> indeed exists:
>>>
>>> <https://www.brow.sh/>
>>
>> Ah yes... I've seen this before! I did drop it due to its dependency on
>> FF, but the concept is similar. My idea was to aggressively filter a web
>> page before passing it on to elinks or similar.
>>
>> Perhaps rewriting it a bit in order to avoid the looooooong list of menu
>> options or links that always come up at the top of the page, before the
>> content of the page shows after a couple of page downs (this happens for
>> instance if I go to wikipedia).
>
> Lucky if it's just a couple of page-downs, I can easily be
> hammering the button on some insane pages where 10% is the actual
> content and 90% is menu links. Often it's quicker to press End
> and work up from the bottom, but many websites have a few pages of
> junk at the bottom too now, so you have to hunt for the little
> sliver of content in the middle.

I know... as a perfectionist this does not go down well with me. ;)

>> Instead parsing it, and adding those links at the bottom, removing
>> javascript, and perhaps passing on only the text.
>
> A similar approach is taken by frogfind.com, except rather than
> parsing the links and putting them at the end, it detetes them,
> which makes it impossible to navigate many websites. It does the
> other things you mention, but the link rewriting would probably be
> the hardest part to get right with a universal parser.

Did not know about frogfind! This could be a great start to improve the
readability! In my home brew rss2email script, I automatically create
archive.is links, so that when I want to read articles behind paywalls,
archive.is is already built in.

I imagine that I could whip up something similar, running page through
http://frogfind.com/read.php?a=xyz... !

> Site-specific front-ends are a simpler goal. This is a list of ones
> that work in Dillo, and therefore without Javascript:
> https://alex.envs.net/dillectory/
>
> Of course then you have the problem of them breaking as soon as the
> target site/API changes or blocks them.

This is the truth!

On Tue, 26 Nov 2024, Mike Spencer wrote:

>
> D <nospam@example.net> writes:
>
>> On Tue, 26 Nov 2024, yeti wrote:
>>
>>> <https://www.brow.sh/>
>>
>> Ah yes... I've seen this before! I did drop it due to its dependency on
>> FF, but the concept is similar. My idea was to aggressively filter a web
>> page before passing it on to elinks or similar.
>>
>> Perhaps rewriting it a bit in order to avoid the looooooong list of menu
>> options or links that always come up at the top of the page, before the
>> content of the page shows after a couple of page downs (this happens for
>> instance if I go to wikipedia).
>>
>> Instead parsing it, and adding those links at the bottom, removing
>> javascript, and perhaps passing on only the text. Well, those are only
>> ideas. Maybe I'll try, maybe I won't. Time will tell! =)
>
> I've done this for a few individual sites that I visit frequently.
>
> + A link to that site resides on my browser's "home" page.
>
> + That home page is a file in ~/html/ on localhost.
>
> + The link is actually to a target-specific cgi-bin Perl script on
> localhost where Apache is running, restricted to requests from
> localhost.
>
> + The script takes the URL sent from the home page, rewrites it for
> the routable net, sends it to the target using wget and reads all
> of the returned data into a variable.
>
> + Using Perl's regular expressions, stuff identified (at time of
> writing the script) as unwanted is elided -- js, style, svg,
> noscript etc. URLs self-referencing the target are rewritten to
> to be sent through the cgi-bin script.
>
> + Other tweaks peculiar to the specific target...
>
> + Result is handed back to the browser preceded by minimal HTTP
> headers.
>
> So far, works like a charm. Always the potential that a target host
> will change their format significantly. That has happened a couple of
> times, requiring fetching an unadorned copy of the target's page,
> tedious reading/parsing and edit to the script.
>
> This obviously doesn't work for those sites that initially send a
> dummy all-js page to verify that you have js enabled and send you a
> condescending reproof if you don't. Other server-side dominance games
> a potential challenge or a stone wall.
>
> Writing a generalized version, capable of dealing with pages from
> random/arbitrary sites is a notion perhaps worth pursuing but clearly
> more of a challenge than site-specific scripts. RSN, round TUIT etc.

Brilliant! You are a poet Mike!

Frogfind.com was a great start! I would love to have some kind of crowd
sourced html5->html1 - javascript - garbage script.

I also wondered if another approach might just be to take the top 500
sites and base it on that? Or even looking through my own history, take
the top 100.

Due to the bad development of the net, it seems like a greater and greater
part of our browsing takes place on ever fewer numbers of sites.

D <nospam@example.net> wrote:
> On Tue, 27 Nov 2024, Computer Nerd Kev wrote:
>> D <nospam@example.net> wrote:
>>> On Tue, 26 Nov 2024, yeti wrote:
>>>> D <nospam@example.net> wrote:
>>>>> I have been thinking about moving the reading part of web browsing
>>>>> into the terminal as well, but haven't found a browser I'm happy
>>>>> with.
>>>>
>>>> I use Elinks, Emacs/EWW and W3m, but none of them can replace the scary
>>>> fullfat browsers. They seem to just fit Smolweb stuff (FTP, Gemini,
>>>> Gopher and similar).
>>>
>>> True.
>>
>> I like seeing useful images, so prefer Dillo and Links (the latter
>> does support display via the framebuffer so you can run it
>> graphically without X).
>
> For some reason, I never managed to get the framebuffer to work. Have no
> idea why. =( I would like to get it to work though.

I guess the framebuffer is working for the console, otherwise it
will probably be a low-res BIOS character display like in DOS. So
either a permissions problem or do you know that you need to start
Links with the "-g" option?

> Dillo was a good tip!
> I did play with it for a bit, but then forgot about it. Maybe the reason
> was a lack of tabs or buffers. I think links or maybe it was elinks, had a
> way for me to replicate tabs or vi buffers in the browser. It was super
> convenient!

Links doesn't do tabs, eLinks might but I haven't used it much.
Dillo has tabs, but isn't great for managing huge numbers of them
(although I avoid trying to do that anywhere).

--
__ __
#_ < |\| |< _#

not@telling.you.invalid (Computer Nerd Kev) wrote:

> Links doesn't do tabs, eLinks might

Elinks does.

.... but now for something completely different:

Have you seen Twin?

<https://github.com/cosmos72/twin>

--
1. Hitchhiker 5: (101) "You just come along with me and have a good
time. The Galaxy's a fun place. You'll need to have this fish in your
ear."

D <nospam@example.net> writes:

> Brilliant! You are a poet Mike!

I'm doubtful that poetry can be done in Perl. Maybe free verse in
Lisp.

> Frogfind.com was a great start! I would love to have some kind of crowd
> sourced html5->html1 - javascript - garbage script.

Do note that Frogfind delivers URLs that send your click back to
Frogfind to be proxied. I assume that's how you get de-enshitified
pages in response to clicking a link returned from a search.

Here's a curiosity:

Google also sends all of your clicks on search results back through
Google. I assume y'all knew that.

If you search for (say):

leon "the professional"

you get:

https://www.google.com/url?q=https://en.wikipedia.org/wiki/L%25C3%25A9on:_The_Professional&sa=U&ved=2ahUKEwi [snip tracking hentracks/data]

Note that the "real" URL which Google proposes to proxy for you
contains non-ASCII characters:

en.wikipedia.org/wiki/L%25C3%25A9on:_The_Professional

Wikipedia does *not* *have* a page connected to that URL! But if you
click the link and send it back through Google, you reach the right
Wikipedia page that *does* exist:

en.wikipedia.org/wiki/Leon:_The_Professional

AFAICT, when spidering the net, Google finds the page that *does*
exist, modifies it according to (opaque, unknown) rules of orthography
and delivers that to you. When you send that link back through
Google, Google silently reverts the imposed orthographic "correction"
so that the link goes to an existing page.

Isn't the weird?

Try it. Copy the "real" URL from such a Google response, eliding
everything before (and including) "?q=" and after (and including) the
first "&", paste it into your browser. Wikipedia will politely tell
you that no such page is available and offer search suggestions.
Revert the non-ASCII "e with a diacritical mark" to 'e' (mutatis
mutandem for similar Google "hits") and it will work.

> I also wondered if another approach might just be to take the top 500
> sites and base it on that? Or even looking through my own history, take
> the top 100.

Now there's a project suitable for AI: train the NN to treat a response
containing stuff you don't want ever to see as a failure. Grovel
repetitively through terabytes of HTML and finally come up with a
generalized filter solution.

> Due to the bad development of the net, it seems like a greater and
> greater part of our browsing takes place on ever fewer numbers of
> sites.

--
Mike Spencer Nova Scotia, Canada

On 28 Nov 2024 01:41:56 -0400, Mike Spencer wrote:

> AFAICT, when spidering the net, Google finds the page that *does*
> exist, modifies it according to (opaque, unknown) rules of orthography
> and delivers that to you.

It adds an entirely unnecessary extra level of URL quoting.

Trying your example through a redirection-removal script I hacked
together:

ldo@theon:unredirect> ./unredirect 'https://en.wikipedia.org/wiki/L%25C3%25A9on:_The_Professional&sa=U&ved=2ahUKEwi'" rel="nofollow" target="_blank">https://www.google.com/url?q=https://en.wikipedia.org/wiki/L%25C3%25A9on:_The_Professional&sa=U&ved=2ahUKEwi'
https://en.wikipedia.org/wiki/L%25C3%25A9on:_The_Professional

Wrong.

ldo@theon:unredirect> ./unredirect --unquote 'https://www.google.com/url?q=https://en.wikipedia.org/wiki/L%25C3%25A9on:_The_Professional&sa=U&ved=2ahUKEwi'
https://en.wikipedia.org/wiki/L%C3%A9on:_The_Professional

Right.

On Wed, 28 Nov 2024, Computer Nerd Kev wrote:

> D <nospam@example.net> wrote:
>> On Tue, 27 Nov 2024, Computer Nerd Kev wrote:
>>> D <nospam@example.net> wrote:
>>>> On Tue, 26 Nov 2024, yeti wrote:
>>>>> D <nospam@example.net> wrote:
>>>>>> I have been thinking about moving the reading part of web browsing
>>>>>> into the terminal as well, but haven't found a browser I'm happy
>>>>>> with.
>>>>>
>>>>> I use Elinks, Emacs/EWW and W3m, but none of them can replace the scary
>>>>> fullfat browsers. They seem to just fit Smolweb stuff (FTP, Gemini,
>>>>> Gopher and similar).
>>>>
>>>> True.
>>>
>>> I like seeing useful images, so prefer Dillo and Links (the latter
>>> does support display via the framebuffer so you can run it
>>> graphically without X).
>>
>> For some reason, I never managed to get the framebuffer to work. Have no
>> idea why. =( I would like to get it to work though.
>
> I guess the framebuffer is working for the console, otherwise it
> will probably be a low-res BIOS character display like in DOS. So
> either a permissions problem or do you know that you need to start
> Links with the "-g" option?

Ahh... ok, that might explain it. If it is console only, then it might not
work in my terminal emulator, and -g just opens a window in X.

I would have liked for it to shows images in the terminal, but maybe I
need to find another terminal emulator for that to work? I think I use the
default one that comes with xfce.

>> Dillo was a good tip!
>> I did play with it for a bit, but then forgot about it. Maybe the reason
>> was a lack of tabs or buffers. I think links or maybe it was elinks, had a
>> way for me to replicate tabs or vi buffers in the browser. It was super
>> convenient!
>
> Links doesn't do tabs, eLinks might but I haven't used it much.
> Dillo has tabs, but isn't great for managing huge numbers of them
> (although I avoid trying to do that anywhere).

Hmm, I should revisit that. I did manage to hack together something
similar to buffers, but don't remember at the moment what I did exactly.

On Thu, 28 Nov 2024, Mike Spencer wrote:

>
> D <nospam@example.net> writes:
>
>> Brilliant! You are a poet Mike!
>
> I'm doubtful that poetry can be done in Perl. Maybe free verse in
> Lisp.

Is it true that Lisp is the secret name of god?

>> Frogfind.com was a great start! I would love to have some kind of crowd
>> sourced html5->html1 - javascript - garbage script.
>
> Do note that Frogfind delivers URLs that send your click back to
> Frogfind to be proxied. I assume that's how you get de-enshitified
> pages in response to clicking a link returned from a search.

Yes, I noted that.

> Here's a curiosity:
>
> Google also sends all of your clicks on search results back through
> Google. I assume y'all knew that.

Haven't used google in a long time, I use ddg.gg or startpage.com instead.
As far as I can see based on a quick glance, they do no rewrites of the
urls.

> Isn't the weird?

I imagine it is done to record it and to help build your profile somehow, which
can then be sold to advertisers?

>> I also wondered if another approach might just be to take the top 500
>> sites and base it on that? Or even looking through my own history, take
>> the top 100.
>
> Now there's a project suitable for AI: train the NN to treat a response
> containing stuff you don't want ever to see as a failure. Grovel
> repetitively through terabytes of HTML and finally come up with a
> generalized filter solution.

Maybe. I would be afraid of it becoming conscious and developing a will of its
own! ;)

>> Due to the bad development of the net, it seems like a greater and
>> greater part of our browsing takes place on ever fewer numbers of
>> sites.
>
>

Retrograde <fungus@amongus.com.invalid> writes:

> Doing everything from the terminal just isn’t viable for me, mostly because I
> didn’t grow up with it.

I guess I was lucky, I was exposed to a bewildering variety of computers
as I grew up in the 80s. There was the myriad of home computers, a lot
of Commodores and Speccys but also Sharps and MSXs and whatever. Some
CP/M machines at school, there were also some early Windows PCs there,
then the GUIs like Atari ST and Amiga's Workbench, sometimes Macs.

90s, I went to the University. They had MS-DOS PCs and text terminals
connected to Unix machines. Some Sun and HP Unix workstations too but
those were for more advanced students only for which I got access
later. Funny contrast, in '91 I got a summer job in a university
department which was all Macs. Looking back, it seems so radical that I
had dual displays and a "huge" 17" monitor to work on way back
then. Even if the other display was the minimal one integrated to the
boxy Mac.

In the meantime, my home computing went from a Commodore 64 to MS-DOS
PC, then dual booting that with OS/2 and some Linux experiments. Games
went to Windows so that MS-DOS became Windows 98 and XP and 7 and
10. Late 90s Linux experiments became permanent when I learned of Debian
Stable. OS/2 disappeared when picking supported hardware for it got too
tiresome.

Work, started mid-90s with Sun Unix workstations until I was kicked to
Office land. That was an awful time and when I escaped, it's been much
the same, Windows PC on the desk, Unix and later Linux server
somewhere. Oh, one job actually provided a Linux workstation under the
desk in addition to a Windows laptop but that was one time.

But to the topic, text only in 2024? I don't think so. Web browsing and
email, just no. Sure I just used Lynx on a Linux server at work to check
the proxy settings are correct and I do use mutt to teach misses to my
spam filter but that's pretty much it. For me, the email I get is HTML
with pictures from commercial sources. Very little personal
correspondence over email these days and mailing lists I get via NNTP
and gmane.

D <nospam@example.net> wrote:
> On Wed, 28 Nov 2024, Computer Nerd Kev wrote:
>> D <nospam@example.net> wrote:
>>> On Tue, 27 Nov 2024, Computer Nerd Kev wrote:
>>>> D <nospam@example.net> wrote:
>>>>> On Tue, 26 Nov 2024, yeti wrote:
>>>>>> I use Elinks, Emacs/EWW and W3m, but none of them can replace the scary
>>>>>> fullfat browsers. They seem to just fit Smolweb stuff (FTP, Gemini,
>>>>>> Gopher and similar).
>>>>>
>>>>> True.
>>>>
>>>> I like seeing useful images, so prefer Dillo and Links (the latter
>>>> does support display via the framebuffer so you can run it
>>>> graphically without X).
>>>
>>> For some reason, I never managed to get the framebuffer to work. Have no
>>> idea why. =( I would like to get it to work though.
>>
>> I guess the framebuffer is working for the console, otherwise it
>> will probably be a low-res BIOS character display like in DOS. So
>> either a permissions problem or do you know that you need to start
>> Links with the "-g" option?
>
> Ahh... ok, that might explain it. If it is console only, then it might not
> work in my terminal emulator, and -g just opens a window in X.

Certainly, in X it'll always be in a separate window.

> I would have liked for it to shows images in the terminal, but maybe I
> need to find another terminal emulator for that to work? I think I use the
> default one that comes with xfce.

W3m displays images in XTerm and other terminal emulators, so that
might be what you want for a browser. I'm not sure if there's a
list of terminal emulators that support image display from it.
This page mentions that some require changes to the configuration:
https://wiki.archlinux.org/title/W3m

--
__ __
#_ < |\| |< _#

On Thu, 29 Nov 2024, Computer Nerd Kev wrote:

> D <nospam@example.net> wrote:
>> On Wed, 28 Nov 2024, Computer Nerd Kev wrote:
>>> D <nospam@example.net> wrote:
>>>> On Tue, 27 Nov 2024, Computer Nerd Kev wrote:
>>>>> D <nospam@example.net> wrote:
>>>>>> On Tue, 26 Nov 2024, yeti wrote:
>>>>>>> I use Elinks, Emacs/EWW and W3m, but none of them can replace the scary
>>>>>>> fullfat browsers. They seem to just fit Smolweb stuff (FTP, Gemini,
>>>>>>> Gopher and similar).
>>>>>>
>>>>>> True.
>>>>>
>>>>> I like seeing useful images, so prefer Dillo and Links (the latter
>>>>> does support display via the framebuffer so you can run it
>>>>> graphically without X).
>>>>
>>>> For some reason, I never managed to get the framebuffer to work. Have no
>>>> idea why. =( I would like to get it to work though.
>>>
>>> I guess the framebuffer is working for the console, otherwise it
>>> will probably be a low-res BIOS character display like in DOS. So
>>> either a permissions problem or do you know that you need to start
>>> Links with the "-g" option?
>>
>> Ahh... ok, that might explain it. If it is console only, then it might not
>> work in my terminal emulator, and -g just opens a window in X.
>
> Certainly, in X it'll always be in a separate window.
>
>> I would have liked for it to shows images in the terminal, but maybe I
>> need to find another terminal emulator for that to work? I think I use the
>> default one that comes with xfce.
>
> W3m displays images in XTerm and other terminal emulators, so that
> might be what you want for a browser. I'm not sure if there's a
> list of terminal emulators that support image display from it.
> This page mentions that some require changes to the configuration:
> https://wiki.archlinux.org/title/W3m

I did go back to play with elinks today, and it does seem like the text
based browser that gets absolutely closest to what I need with the ability
to auto save sessions.

I think that together wish frogfind.com I have found my temporary
solution for the terminal! It is also trivial to migrate my open "reading
tabs" from firefox to elinks by just doing a save all open tabs, and then
massaging the exported bookmarks file a bit and then just open all of the
sites from the command line. =)

not@telling.you.invalid (Computer Nerd Kev) wrote:

> W3m displays images in XTerm and other terminal emulators, so that
> might be what you want for a browser. I'm not sure if there's a
> list of terminal emulators that support image display from it.
> This page mentions that some require changes to the configuration:
> https://wiki.archlinux.org/title/W3m

I think W3M seems to put another window layer atop the terminal to
display images. It works, but my main use case for W3M is as man page
viewer W3MMAN (aliased to man), so I don't care much for it's image
capabilities.

Elinks has a `./configure` option to enable Sixels, which I did, and I
see the generated binary being linked to `libsixel`, found the run-time
option to enable Sixel graphics, but I never see any images displayed.

<https://github.com/rkd77/elinks>

If someone succeeds with this, please ping me.

--
Die Partei | Martin Sonneborn | Die Partei
Die Partei | Gespräch am Küchentisch, Teil II | Die Partei
Die Partei | <https://www.youtube.com/watch?v=2C21SJd5SVE> | Die Partei