On 2023-07-25 12:19:30 +0000, Simon Clubley said:

> On 2023-07-24, Stephen Hoffman <seaohveh@hoffmanlabs.invalid> wrote:
>>
>> But these discussions all go back decades. Arguably, X is an RPC with
>> graphics support bolted on, for instance.
>>
>
> And unlike its replacement, this means it 1) actually works, and 2) can
> be efficiently used across the network to display GUI applications
> running on another server.

From a decade or so ago, a presentation by Daniel Stone on some of the
issues with X11: https://www.youtube.com/watch?v=RIctzAQOe44

--
Pure Personal Opinion | HoffmanLabs LLC

Den 2023-07-26 kl. 02:30, skrev Arne Vajhøj:
> On 7/25/2023 6:24 PM, Johnny Billquist wrote:
>> On 2023-07-25 02:06, Arne Vajhøj wrote:
>>> On 7/24/2023 7:53 PM, Scott Dorsey wrote:
>>>>                    Not to mention the added overhead from all those
>>>> layers.
>>>
>>> Are those layers that bad?
>>>
>>> Sure SSL handshake takes time, but that is not due to the layers
>>> but due to the nature of the key exchange.
>>
>> Let me put a question for you? Are there any number of layers, in your
>> opinion, where it becomes a problem?
>>
>> 1 layer? 10? 100? 1000? At which point does it become a problem, and why?
>> And if you say 100, for example. Why is 99 not a problem, but 100 is then?
>
> Good question. And we all know how it is with answers to good
> questions.  :-)
>
> It is in many ways similar to "how many software layers in an
> application are too much?" and "how few lines per
> routine/function/method is too much splitting up?".
>
> There is not a single provable correct answer. Based on
> some industry experience most have a feeling for when
> a good thing becomes too much.

Correct. As I have understood this discussion, it has mainly been around
layers specficially in the communication stacks.

I have seen a lot of issues where there are "too many" layers in the
application architecture also. Most often in "modern" solutions using
some fancy framework where the developer comes longer and longer from the
core system for each new version of these frameworks.

We have an old VMS solution where the Cobol codes mostly talks directly to
equipment (like barcode scanners, label printers and PLC in machines) and
our response times are in 10s of ms. Another (commersial and highly
"modern") similar system takes up to 1 min for a simple label printout.

There have also been some public projects that have failed due to what I
see as a failure to understand the whole application architecture...

>
> application protocol (the web service API's - not what is called
> application layer in typical network stack pictures)
> HTTP
> TLS
> TCP
> IP
> the more physical stuff
>
> does not seem to be too much. It get used. And the number of
> layers is not a frequent complaint.
>
> The (in)famous OSI model was considered to be too much. Not only
> because of the number of layers, but still.
>
> So it seems to me that experience shows around 7-8 being too
> much.
>
>> And if everything is depending on TLS to provide security, then it means
>> if SSL is compromised, you have no security anywhere suddenly. That's the
>> "all eggs in one basket" point.
>>
>> The fact that TLS supports multiple cryptos does not suddenly make it
>> several different baskets.
>> TLS have a common framework, which is one single piece, and it's also
>> always a negotiation between the two sides on cryptos. So if you identify
>> a problem with a crypto, it's basically an open exploit everywhere where
>> you can negotiate that crypto. Which then would mean pretty much
>> everywhere, until that crypto is removed, which will certainly take some
>> time for a lot of places.
>
> TLS has a single point of failure in itself (unless one
> consider 1.2 and 1.3 to be sufficient different to provide
> some redundancy) but some redundancy in the algorithms.
>
> Redundancy in algorithms is I believe a design goal in itself.
> SHA-3 was not created because SHA-2 was considered weak - it
> was create to have two alternatives.
>
> It does not take that long time to disable old algorithms and
> enable new ones. In case of emergency it could happen very
> quickly. Servers get patched and people have to update their
> browsers if they want to access the servers.
>
> It takes extremely long time to create and check new
> algorithms. Which is why it makes sense to have more than
> one algorithm in a given category on the shelf.
>
> I have no idea about how long time it takes to create
> a new TLS version. If it takes years then having an
> alternative on the shelf may make sense. 1.4A and 1.4B
> that are sufficiently different to not be vulnerable to
> same problem.
>
>> Yes, if someone else is also using that crypto, even without TLS, then
>> yes, that is just as vulnerable. But if they had used TLS, they would not
>> have been any less vulnerable. But if they have some other crypto, or if
>> the problem found would be in the TLS code itself, then you likely dodged
>> that bullet.
>
> Algorithm ABC used in TLS and algorithm ABC used in XXX are
> obviously the same.
>
> But unless XXX would a standard with huge industry support, then
> XXX would be more risky than TLS.
>
> The effort that goes into checking TLS is huge. It would cost
> thousands maybe tens of thousands of man years to check
> XXX to the same level as TLS.
>
> Arne
>
>

On 7/26/2023 6:47 AM, Jan-Erik Söderholm wrote:
> Den 2023-07-26 kl. 02:30, skrev Arne Vajhøj:
>> On 7/25/2023 6:24 PM, Johnny Billquist wrote:
>>> On 2023-07-25 02:06, Arne Vajhøj wrote:
>>>> On 7/24/2023 7:53 PM, Scott Dorsey wrote:
>>>>> Not to mention the added overhead from all those layers.
>>>>
>>>> Are those layers that bad?
>>>>
>>>> Sure SSL handshake takes time, but that is not due to the layers
>>>> but due to the nature of the key exchange.
>>>
>>> Let me put a question for you? Are there any number of layers, in your
>>> opinion, where it becomes a problem?
>>>
>>> 1 layer? 10? 100? 1000? At which point does it become a problem, and why? And
>>> if you say 100, for example. Why is 99 not a problem, but 100 is then?
>>
>> Good question. And we all know how it is with answers to good
>> questions. :-)
>>
>> It is in many ways similar to "how many software layers in an
>> application are too much?" and "how few lines per
>> routine/function/method is too much splitting up?".
>>
>> There is not a single provable correct answer. Based on
>> some industry experience most have a feeling for when
>> a good thing becomes too much.
>
>
> Correct. As I have understood this discussion, it has mainly been around layers
> specficially in the communication stacks.
>
> I have seen a lot of issues where there are "too many" layers in the application
> architecture also. Most often in "modern" solutions using
> some fancy framework where the developer comes longer and longer from the core
> system for each new version of these frameworks.
>
> We have an old VMS solution where the Cobol codes mostly talks directly to
> equipment (like barcode scanners, label printers and PLC in machines) and our
> response times are in 10s of ms. Another (commersial and highly "modern")
> similar system takes up to 1 min for a simple label printout.
>
> There have also been some public projects that have failed due to what I see as
> a failure to understand the whole application architecture...

An example.

Consolidated cannot continue to guarantee (as if there is such a thing) service
to the customers. The application has been offered to the customers. They
"don't want to be in the software business", even though every user of computers
is in the software business in some way. Anyway, the are looking for new solutions.

All the new solutions being considered are "in the cloud". Microsoft and other
vendors are involved. When the prospective vendors consider the customer's
volume, they have stated "we cannot handle that volume". That's your "modern
cloud solutions".

Most of the customers are determined to make the new systems work. Sadly, we're
predicting some craters. Too bad, but we are way over any "retirement age".
(Yesterday was 77.)

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

=?UTF-8?Q?Arne_Vajh=c3=b8j?= <arne@vajhoej.dk> wrote:
>On 7/24/2023 7:53 PM, Scott Dorsey wrote:
>> Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
>>> On 2023-07-23, Scott Dorsey <kludge@panix.com> wrote:
>>>> Andy Burns <usenet@andyburns.uk> wrote:
>>>>> Scott Dorsey wrote:
>>>>>> This is culturally very different than modern systems where everything
>>>>>> is running IP and only what is on top of TCP or UDP is different.
>>>>>
>>>>> We're pretty close to the next stage where everything is running on top
>>>>> of HTTPS, aren't we?
>>>
>>> Good.
>>>
>>>> Please don't remind me. It's a horrible idea to contemplate, isn't it?
>>>
>>> From a security point of view, it (or something similar) is a really
>>> good idea.
>>
>> Are you sure about that? It sure seems like putting all your eggs into
>> one basket to me.
>
>I will assume you are really talking about SSL.

No, I am talking about SSL-over-HTTP.

>Tt is only the TLS protocol itself that is all eggs in one
>basket.

Yes.

>> Not to mention the added overhead from all those layers.
>
>Are those layers that bad?
>
>Sure SSL handshake takes time, but that is not due to the layers
>but due to the nature of the key exchange.

The http overhead too of course.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."

[Please do not mail me a copy of your followup]

Stephen Hoffman <seaohveh@hoffmanlabs.invalid> spake the secret code
<u9prkf$18q1m$1@dont-email.me> thusly:

>On 2023-07-25 12:19:30 +0000, Simon Clubley said:
>
>> On 2023-07-24, Stephen Hoffman <seaohveh@hoffmanlabs.invalid> wrote:
>>>
>>> But these discussions all go back decades. Arguably, X is an RPC with
>>> graphics support bolted on, for instance.
>>>
>>
>> And unlike its replacement, this means it 1) actually works, and 2) can
>> be efficiently used across the network to display GUI applications
>> running on another server.
>
>From a decade or so ago, a presentation by Daniel Stone on some of the
>issues with X11: https://www.youtube.com/watch?v=RIctzAQOe44

I haven't watched the video, but if I recall the main argument is that
the UI loop invovles network round trips:

1. the "server" generates a mouse event from a locally attached device
2. the mouse event is transmitted across the network to the application
3. the application recognizes that the mouse event means "display a menu"
4. the application issues the commands to draw the menu
5. the application waits for another event, causing the local transmit
buffer to be flushed (Xlib) and the drawing commands are
transmitted across the network to the server which draws the menu.

If network latency is significant, the constant round trip of
event/response for common UI elements like popup-menus and
highlighting of the menu item that would be selected upon release of
the mouse button results in very sluggish interaction.

NeWS attempted to address this by letting the application upload
code into the server to handle location UI interaction. The point of
this uploaded code was to perform the visual manipulation of the UI
and only transmit back to the application when some non-UI related
work needed to be performed, e.g. you selected a menu item or clicked
on a button.

Since the window manager is just another client in X, even moving the
windows around on the screen could be very sluggish if there was
significant round-trip delay between the server and the machine runing
the window manager.

While the NeWS approach has some elegance to it, in practice it was a
giant pain in the butt. Debugging that uploaded code running in the
server was extremely tedious and difficult. At least that was my
experience circa 1989 when using NeWS on an SGI workstation.

So, programmers being the lazy creatures we all know and love stuck
with traditional debugging and programming techniques like dbx and C
instead of learning PostScript and struggling to put their UI into the
server.
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Terminals Wiki <http://terminals-wiki.org>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>