Gentoo Archives: gentoo-user

From: Caveman Al Toraboran <toraboracaveman@××××××××××.com>
To: "gentoo-user@l.g.o" <gentoo-user@l.g.o>
Subject: Re: [gentoo-user] tuning desktop appearance for legibility
Date: Sat, 05 Sep 2020 22:41:03
Message-Id: DEVaU51Gkg6UsBdCjTCQzXDFommdy5Nz0sqNHCieiFyzBhBT_g47X5itZ-_J1FR88UIMUNOlkL6IV6bu74Z0Elzlyuf1Om-ZYeOYbAxIuJU=@protonmail.com
In Reply to: Re: [gentoo-user] tuning desktop appearance for legibility by Wols Lists
1 ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
2 On Saturday, September 5, 2020 1:09 PM, Wols Lists <antlists@××××××××××××.uk> wrote:
3
4 > Isn't that how the web originally WAS designed? That the web-site sent
5 > content and the browser determined how it was displayed?
6
7 sort of. it was not very clear and they could've
8 gone either direction. so they had to answer the
9 question: where to go? they thought a bit and
10 concluded:
11
12 "let's go turing-complete with built-in drm
13 and enough fluff to make viewing a 2D page
14 (e.g. cnn.com) take almost twice as much RAM
15 as that of a 3D game (e.g. quake-iii) [1].
16 but remove marquee!"
17
18 even though i dislike how the web ended up being,
19 there is one side effect that i like:
20
21 - making the web turing-complete served as an
22 experiment to explore what humans want. if
23 web devs didn't have the power to freely do
24 things, we wouldn't have known what do they
25 want, and which idea is good/bad.
26
27 of course, the web also morphed into other messy
28 things that didn't have any good side effects.
29 such as the drm, and the many information leakages
30 that are so ridiculous they effectively render
31 "authentication" sort of redundant; google may
32 identify us by our browsers' fingerprints and call
33 it a day. as if not enough, goog also graciously
34 give us x-client-data for free [2].
35
36 that said, i think the decades old experiment is
37 over, and i think we've seen enough to conclude a
38 few things from this experiment. i suggest that
39 we must deprecate http/js/css/etc, and split the
40 web into two components:
41
42 (1) page content definition format (PCDF): an
43 efficient binary format that only defines
44 content, with no presentation information.
45
46 imo this is very doable because, while the
47 content in the web varies drastically, their
48 _type_ is pretty finite (e.g. nav bar,
49 copyright notice, related topics, body, etc).
50 i think if we survey websites, it is easy to
51 see that there is only a small number of
52 content types.
53
54 the client obtains PCDF documents via https
55 then presents them based on user's viewing
56 preference which is purely defined locally in
57 his computer (the server has no business in
58 knowing any of it). this way navigation
59 bars, copy right notices, etc are placed in a
60 standardized manner for every user based on
61 what he cares most about.
62
63 this way, we won't need to mess up with user
64 style sheet hacks per website. plus page
65 size will become extremely small, and
66 ridiculously efficient to render thanks to
67 the binary format, and much ore responsive.
68 it would be so fast you'd feel that the page
69 has loaded even before you clicked on the
70 link.
71
72 (2) application containers: this is the part why
73 the web has javascript support, and this is
74 still a part where is not clear to me if we
75 actually need it.
76
77 i think this is also very redundant with many
78 alternatives doing basically the same thing,
79 such as docker.
80
81 maybe this is just "package manager in a
82 glorified chroot"?
83
84 this side is still unclear to me, and i don't
85 know where it is going.
86
87 ---
88 [1] https://www.networkworld.com/article/3175605
89 [2] https://www.theregister.com/2020/03/11/google_personally_identifiable_info/