[Lynx-dev] invidio access to youtube content
Youtube recently began blocking lynx. A poster pointed me to this url for an alternative access to youtube content: https://invidio.us/ That url is going away september 1. However, there are multiple url's which have the same web homepage format for invidio, it is an open source project. Here is a list of them from which to choose a replacement: https://instances.invidio.us/ -- XR ___ Lynx-dev mailing list Lynx-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/lynx-dev
[Lynx-dev] SOCKS5_PROXY (was Re: the sun, the sun)
Turns out you do not even need a magic value. You tried a
premature optimisation, but Lynx calls LYGetEnv for the
other *_proxy variables each time as well, so dropping the
premature optimisation and switching to LYGetEnv and fixing
a bug in the man(7)page results in:
--- a/WWW/Library/Implementation/HTTCP.c
+++ b/WWW/Library/Implementation/HTTCP.c
@@ -1848,6 +1848,8 @@ int HTDoConnect(const char *url,
*s = -1; /* nothing is open yet */
/* In case of a present SOCKS5 proxy, marshal */
+if (socks5_proxy == NULL)
+ socks5_proxy = LYGetEnv("SOCKS5_PROXY");
if ((socks5_orig_url = socks5_proxy) != NULL) {
int xport;
--- a/lynx.man
+++ b/lynx.man
@@ -805,9 +805,16 @@ If enabled the transfer rate is shown in bytes/second.
If disabled, no transfer rate is shown.
Use lynx.cfg or the options menu to select KB/second and/or ETA.
.TP
-.B \-socks5\-proxy=URL
-(Via which) SOCKS5 proxy to connect.
-This controls the builtin SOCKS5 support, and is therefore unrelated to
+.B \-socks5_proxy=URL
+(Via which) SOCKS5 proxy to connect: any network traffic, including all
+DNS resolutions but the one for URL itself, will be redirected through
+the SOCKS5 proxy.
+URL may be given as \*(``proxy.example.com\*('',
+\*(``proxy.example.com:1080\*('', \*(``192.168.0.1\*('', or
+\*(``192.168.0.1:1080\*('' (and IPv6 notation if so supported).
+A SOCKS5 proxy may also be specified via the environment variable
+.B SOCKS5_PROXY.
+This option controls the builtin SOCKS5 support, which is unrelated to
the option \fB\-nosocks\fP.
.TP
.B \-soft_dquotes
@@ -1139,6 +1146,11 @@ wais_proxy
.IP
See \fBLynx Users Guide\fR for additional details and examples.
.TP
+.B SOCKS5_PROXY
+Is inspected if
+.B \-socks5_proxy
+has not been used (for the same content).
+.TP
.B SSL_CERT_DIR
Set to the directory containing trusted certificates.
.TP
--- a/src/LYMain.c
+++ b/src/LYMain.c
@@ -3916,7 +3916,7 @@ saves session to that file on exit"
),
#endif
PARSE_STR(
- "socks5-proxy", 2|NEED_LYSTRING_ARG,socks5_proxy,
+ "socks5_proxy", 2|NEED_LYSTRING_ARG,socks5_proxy,
"=URL\n(via which) SOCKS5 proxy to connect (unrelated to -nosocks!)"
),
PARSE_SET(
bye,
//mirabilos
___
Lynx-dev mailing list
Lynx-dev@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lynx-dev
Re: [Lynx-dev] the sun, the sun
David Woolley dixit: > I can't find the original for this thread, but days are not 86400 > seconds, which are currently defined in terms of a quantum transition > frequency. The actual length of a day is less stable than this. Leap > seconds are introduced into UTC to correct for this. The general idea is to keep the following definitions… UT1: universal time, based on days of 86400 UT1-seconds of variable (observed, not predictable) length UTC: coordinated universal time; basis for human timekeeping (struct tm), uses SI seconds; days are 86400 or 86401 constant-length seconds TAI: international atomic time; uses SI seconds; should be basis for Unix timekeeping (SI seconds since the epoch) but people seem to use it with 86400-second days (which is wrong) … and invariants: • n = UTC - TAI, n ∈ ℤ (though ℕ really) • abs((DUT1 = UT1 - UTC)) < 0.9 s That is, UTC is managed by starting with TAI and inserting as many leap seconds as necessary to ensure the difference to UT1 is less than 0.9 s either way; leap seconds are generally inserted at the end of the year or Q2 (at an UTC day’s end), and the previously re‐ served concepts of adding two leap seconds at once or having negative leap seconds are abandoned, given celestial movement won’t need them. Incidentally, POSIX demands that time_t is UTC-without-leap-seconds (not the same as TAI due to a numerical offset/bias), but German law demands that leap seconds are counted, so time_t on MirBSD is UTC with leap seconds. (But struct tm is correct, and the user gets functions to convert, and even a posixtz.so LD_PRELOADable library, and utilities like rsync that transmit time_t get patched to convert on boundary.) Anyway, standards suck, and not honouring them sucks either, and conflicting standards suck more, and self-inconsistent standards *cough*ACPI*cough* suck the most. Back to topic. It’s trivial to use (here ) as flag value instead of (char *)-1 which is fragile. If you don’t want to do that, either use a separate boolean (uint8_t to save space) flag value, or restructure the code so it doesn’t need a flag. bye, //mirabilos -- 22:20⎜ The crazy that persists in his craziness becomes a master 22:21⎜ And the distance between the craziness and geniality is only measured by the success 18:35⎜ "Psychotics are consistently inconsistent. The essence of sanity is to be inconsistently inconsistent ___ Lynx-dev mailing list Lynx-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/lynx-dev
Re: [Lynx-dev] the sun, the sun
On 08/08/2020 23:29, Halaasz Saandor via Lynx-dev wrote: I suspect that it is time to detach the physical second, that physicists use, from the second that is one 86400th of a day, and find a definition of "day" that depends on our experience of sunlight. The last definition that I found makes a day 86400 seconds. I can't find the original for this thread, but days are not 86400 seconds, which are currently defined in terms of a quantum transition frequency. The actual length of a day is less stable than this. Leap seconds are introduced into UTC to correct for this. (Also, a solar day is not constant throughout the year, because the earth's orbit round the sun is elliptical.) ___ Lynx-dev mailing list Lynx-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/lynx-dev
