Re: Win11 explorer bug?

On Fri, 13 Dec 2024 06:18:54 -0700, Don Y
<blockedofcourse@foo.invalid> wrote:

On 12/13/2024 2:55 AM, Martin Brown wrote:

On 12/12/2024 21:09, john larkin wrote:

On Thu, 12 Dec 2024 04:00:23 -0700, Don Y
<blockedofcourse@foo.invalid> wrote:
>

On 12/12/2024 2:59 AM, Martin Brown wrote:

Probably because it is *so* bug.
(typo for big but Freudian slip seems OK)

>
Once something becomes "complex" (i.e., too large to fit in a
single brain), it becomes difficult to understand the repercussions
of specific design decisions -- because you can't remember
EVERYTHING with which they interact.

>
Engineers design giant systrems - cars, airplanes, bridges, buildings
- with lots of parts, and nobody understands all the parts. And they
work first time.

>
In my lifetime (or of sufficiently common "lore"):
  Hindenberg explosion
  Tacoma Narrows Bridge collapse
  Chernobyl reactor
  Hyatt Regency walkway collapse
  Apollo 1 fire
  Apollo 13 O2 tank explosion
  Space Shuttle Challenger
  Space Shuttle Columbia
  Skylab
  Fukishima nuclear plant
  Deepwater Horizon fire/"spill"
  Doors falling out of airplanes
  Titanic
  BIG! chinese dam failure (no idea of name)
  World Trade Center towers
  Concorde
  De Gaulle airport collapse
  DC-10 engine falling off
  Titan submersible implosion
All, obviously, software problems??
>

There are hundreds of years experience building large physical objects and
customers can more or less understand engineering diagrams and now virtual 3D
renderings of their new building made possible by software.

>
<https://en.wikipedia.org/wiki/List_of_aircraft_structural_failures>
<https://en.wikipedia.org/wiki/List_of_building_and_structure_collapses>
<https://en.wikipedia.org/wiki/List_of_bridge_failures>
<https://en.wikipedia.org/wiki/Dam_failure#List_of_major_dam_failures>
<https://en.wikipedia.org/wiki/List_of_hydroelectric_power_station_failures>
<https://en.wikipedia.org/wiki/List_of_thermal_power_station_failures>
<https://en.wikipedia.org/wiki/List_of_catastrophic_collapses_of_broadcast_masts_and_towers>
>
Bias?  Or sheer Ignorance?

What fraction of airplanes or bridges or buildings collapse? Estimate
that in PPMs.

>

It didn't stop someone during build phase connecting a high pressure steam pipe
to a stairway handrail on one plant that I know of. Big engineering diagrams
can also be confusing when loads of similar diameter pipes (and non-pipes) go
through a partition.

>
Or, misplumb the bedside O2 supply at the hospital where SWMBO worked.
>
And, we won't discuss why notes were never taken at the M&M meetings
she attended.  "Something wrong?  On OUR part?  No....."
>

Software is still in the medieval cathedral building era but without the make
walls thicker just in case strategy. It is still a good heuristic that if it is
still standing after 5 years then it was a good 'un.

>
And, unlike EVERYTHING physical, it doesn't wear out!  Annoying that folks
can't seem to design hardware that performs the same 30 - 50 years later.
Must just be shitty designs that "fail"?
>

Ely cathedral on the fens and the crooked spire at Chesterfield are examples
that didn't quite fall down but don't quite look as designed.
 
https://www.elycathedral.org
 
https://en.wikipedia.org/wiki/Church_of_St_Mary_and_All_Saints,_Chesterfield
 

Software is different, and it never works first time. Most programs
don't even compile first try.

>
Says the Programmer.  I guess an admission of a lack of skill.
>

It is better if they don't compile at all until they are nearly correct. The
more faults that are found at compile time the better. Static code analysis has
done a lot to improve software quality in the past decade.

>
Lack of education is a big problem.  Too easy to be a "programmer" without
having any real skillset -- beyond "Look, Ma, it (almost) works!"  Kinda
like having a soldering iron and claiming to be an EE!
>
We quiz job applicants with really simple, disarming questions:  How
do you sort a list?  Then, watch to see HOW they reply.  If they don't
*immediately* ask to better define the problem space but throw up
the name of a sort algorithm, we're pretty sure they're just
a programmer.  So, we coax as much of that superficial knowledge from
them:  how many sort algorithms can you name?  how do they differ?
write the pseudocode for <pick_one>?  Great, now write <another>?
Which is faster?  (trick question) Why?
>
If they haven't mentioned any trees, we're SURE they're a programmer.
>
How would you use this algorithm to sort a list of integers?  Based on
the third digit?  Will the sort be stable?  (do you even know what
that means?)  variable length strings?  A list with 1,000,000 entries?
1,000,000,000,000?  What if you only have 25KB of working store?
>
How long will that take?  How would you make it twice as fast?  TEN
times faster?  Programmers quickly fall by the wayside when you get
past the superficial knowledge needed to write X in language Y.
>
[And, if 'Y' is the language du jour, they're almost certainly a
programmer!]
>
Ask a programmer how much stack his code needs.  Or, how big it is
(based solely on what he's committed to paper).  "We need to know how
much memory to put in the device; installing a disk drive would be
foolhardy just to give you peace of mind with your estimate.  We
need to order the parts NOW so manufacturing can start building product
and YOU can install your software as they are headed out the door..."

I often ask programmers how long some chunk of code will take to
execute, or how often I can run some ISR. Not as a trick interview
question, but because it matters to a product design. They usually
don't know and typically guess runtimes at least 10x slower that a
reasonable estimate. I buy them an oscilloscope and make them measure
it.

Using an oscilloscope actually radically improves their code.

What's interesting is that FPGA code is usually much more reliable,
bug-free, compared to procedural code.

I think that's because logic design is centered on state machines, and
procedutal programmers usually don't know what a state machine is.
Software bugs or often the equivalent of logic races or metastability.