Dick Hustvedt was born on this day in 1946; an architect of RSX-11 and VMS, he
also had a weird sense of humour which he demonstrated by enshrining the
"microfortnight" into VMS in order to make admins RTFM.
Sadly, we lost him in a car accident in 2008.
-- Dave
Almost forgot...
Born on this day in 1934, he pretty much invented ALGOL (and algorithmic
languages in general; the running joke was that you could call him by
name or by value)... From Clem Cole: "The actual joke was Europeans
called him by name ("ni-klaus vurt") and Americans by value ("nickel-less
worth").
-- Dave
On Thu, 14 Feb 2019, Thomas Kellar wrote:
> I am learning from the discussion. I disagree with the binary
> argument. Women and men both have personalities and brains that range
> over a huge spectrum of differences. It is society that tries to force
> them into particular molds.
Hi Thomas.
FWIW, the mainstream on both sides of this argument agree that men and
women overlap in characteristics. The question is what causes the
differences.
Many human characteristics are bimodal with most people clustering around
one of two points, and those points correlating with biological gender.
Opponents of inate gender differences argue that the observed differences
are socialised. They point out that neuroplasticity means that even
differences in brain structure between genders *could* be socialised.
This is why I find studies on infants so interesting. There are plenty of
examples but I've linked a study below that monitored the behaviour of
infants that are around 24 hours old. Statistically significant
differences in behaviour were observed between boys and girls. This is
far too early for any socialisation to have occured.
https://www.math.kth.se/matstat/gru/5b1501/F/sex.pdf
When I was a young man I believed that gender differences (beyond obvious
morphological differences) were socialised. But the evidence grew, and
has continued to grow, that to a large degree this isn't so.
A really fascinating area is "greater male variability" (GMV) which really
explains a lot about the world. I wrote an article on that for a well
known blog a few years ago. While researching the article I discovered
that men vary more than women in personality. That is to say that on
average women are more similar to each other in personality than men are.
I admit that one really surprised me.
Some people claim GMV has been discredited. It hasn't. People claiming
GMV has been discredited usually cite a handful of counter examples as
evidence of this. GMV was never claimed to be univerally true, only true
for most characteristics.. I suspect there is at least one case where
females, not males, exhibit greater variability but this still doesn't
discredit GMV.
Getting back to employment, there have been many studies on employment
patterns and gender by researchers and governments. They consistently
show that men and women make a myriad of different choices in employment.
In particular they show that men will tend to prioritise earning potential
over many other characteristics of employment while women tend to do the
reverse. The largest study on this topic anywhere is probably the
CONSAD Report, commissioned by the US Dept of Labor. The CONSAD Report is
actually on the gender earnings gap but it's still relevant to a
discussion on different choices men and women make in employment.
Here's a tiny URL to the CONSAD Report:
https://tinyurl.com/y6vvzm4v
Cheers,
Rob
<SNIP>
Is this thread really a good place for TUHS discussion? Maybe COFF would
be better suited for it.
And maybe the explanation why there are more men in IT is simpler than some
folks who forcefully try to create elaborate sociological theories think.
In nature males are just wired differently from females. And that is why
they ARE different, like 1 and 0. Otherwise they would be just one sex.
And as we know nothing can come from just one number...
--Andy
Seeing as how this is diverging from TUHS, I'd encourage replies to the
COFF copy that I'm CCing.
On 02/06/2019 01:47 PM, Kevin Bowling wrote:
> There were protocols that fit better in the era like DeltaT with a
> simpler state machine and connection handling. Then there was a mad
> dash of protocol development in the mid to late ‘80s that were measured
> by various metrics to outperform TCP in practical and theoretical
> space. Some of these seemed quite nice like XTP and are still in use in
> niche defense applications.
$ReadingList++
> Positive, rather than negative acknowledgement has aged well as
> computers got more powerful (the sender can pretty well predict loss
> when it hasn't gotten an ACK back and opportunistically retransmit).
> But RF people do weird things that violate end to end principle on cable
> modems and radios to try and minimize transmissions.
Would you care to elaborate?
> One thing I think that is missing in my contemporary modern software
> developers is a willingness to dig down and solve problems at the right
> level. People do clownish things like write overlay filesystems in
> garbage collected languages. Google's QUIC is a fine example of
> foolishness. I am mortified that is genuinely being considered for the
> HTTP 3 standard. But I guess we've entered the era where enough people
> have retired that the lower layers are approached with mysticism and
> deemed unable and unsuitable to change. So the layering will continue
> until eventually things topple over like the garbage pile in the movie
> Idiocracy.
I thought one of the reasons that QUIC was UDP based instead of it's own
transport protocol was because history has shown that the possibility
and openness of networking is not sufficient to encourage the adoption
of newer technologies. Specifically the long tail of history / legacy
has hindered the introduction of a new transport protocol. I thought I
remembered hearing that Google wanted to do a new transport protocol,
but they thought that too many things would block it thus slowing down
it's deployment. Conversely putting QUIC on top of UDP was a minor
compromise that allowed the benefits to be adopted sooner.
Perhaps I'm misremembering. I did a quick 45 second search and couldn't
find any supporting evidence.
The only thing that comes to mind is IPsec's ESP(50) and AH(51) which—as
I understand it—are filtered too frequently because they aren't ICMP(1),
TCP(6), or UDP(17). Too many firewalls interfere to the point that they
are unreliable.
> Since the discussion meandered to the distinction of path
> selection/routing.. for provider level networks, label switching to this
> day makes a lot more sense IMO.. figure out a path virtual circuit that
> can cut through each hop with a small flow table instead of trying to
> coagulate, propagate routes from a massive address space that has to fit
> in an expensive CAM and buffer and forward packets at each hop.
I think label switching has it's advantages. I think it also has some
complications.
I feel like ATM, Frame Relay, and MPLS are all forms of label switching.
Conceptually they all operate based on a per-programed path.
--
Grant. . . .
unix || die
We lost computer pioneer John von Neumann on this day in 1957; the "von
Neumann" architecture (stored program etc) is the basis of all modern
computers, and he almost certainly borrowed it from Charles Babbage.
-- Dave
It looks like Kevin's response didn't make the COFF mailing list. So
I'm including it and my email that it's in response to below.
Kevin, are you subscribed to the COFF mailing list?
On 2/7/19 5:16 PM, Kevin Bowling wrote:
> On Thu, Feb 7, 2019 at 11:08 AM Grant Taylor via TUHS
> <tuhs(a)minnie.tuhs.org> wrote:
>> Seeing as how this is diverging from TUHS, I'd encourage replies to the
>> COFF copy that I'm CCing.
>
> My thesis was that the specific vector of TCP becoming dominant is "UH"
>
>> $ReadingList++
>
> Pick up ISBN-13: 978-0201563511 if you work on transport protos.
>
>> Would you care to elaborate?
>
> Only briefly for this list -- certain common devices will intercept
> TCP streams and cause what are called stretch ACKs from a host because
> transmission is expensive in some vector -- shared collision domain
> like the air or a coaxial bus, battery power to key up the radio etc.
> This means the sender has to accommodate that behavior and know how to
> react if it is modeling the connection.
Intriguing.
It seems that the more answers that I get end up resulting in even more
questions and things I want to learn about.
Thank you Kevin.
>> I thought one of the reasons that QUIC was UDP based instead of it's own
>> transport protocol was because history has shown that the possibility
>> and openness of networking is not sufficient to encourage the adoption
>> of newer technologies. Specifically the long tail of history / legacy
>> has hindered the introduction of a new transport protocol. I thought I
>> remembered hearing that Google wanted to do a new transport protocol,
>> but they thought that too many things would block it thus slowing down
>> it's deployment. Conversely putting QUIC on top of UDP was a minor
>> compromise that allowed the benefits to be adopted sooner.
>>
>> Perhaps I'm misremembering. I did a quick 45 second search and couldn't
>> find any supporting evidence.
>
> G and Facebook also admit it uses 200% more CPU to do the same
> throughput. All for basically avoiding HOL-blocking, which can be
> worked around in most common scenarios, especially when you control
> the most popular browser :facepalm:. Both companies together could
> pull networking in any direction they want. I see QUIC as yet another
> unfortunate direction.
Okay.
>> The only thing that comes to mind is IPsec's ESP(50) and AH(51) which—as
>> I understand it—are filtered too frequently because they aren't ICMP(1),
>> TCP(6), or UDP(17). Too many firewalls interfere to the point that they
>> are unreliable.
>>
>>
>> I think label switching has it's advantages. I think it also has some
>> complications.
>>
>> I feel like ATM, Frame Relay, and MPLS are all forms of label switching.
>> Conceptually they all operate based on a per-programed path.
>
> By provider networks I mean tier 1 and 2 and core infrastructure like
> CDNs. MPLS is good. ATM got a couple things right and a lot of
> things less right.
I think one thing that MPLS, ATM, FR do / did is to transparently carry
other protocols without modification to their operation. I think such
transparency allows them to do things that would be considerably more
difficult if the switching / routing logic of the transport network was
trying to interpret network addressing and / or protocol information of
the payloads they were carrying.
I don't know how flexible MPLS, et al, are without the support of other
associated protocols. How well can a MPLS cloud with redundant
connections find an alternate path if a link goes down. That's arguably
something that IP is exceedingly capable of doing, even if it's not the
most efficient at it.
--
Grant. . . .
unix || die
