parados · HackerTrans

2 か月前議論

Second this. Canonical is currently winning the race to the bottom for tech interviews (I'm speaking with a couple of decades of experience on both sides of the table). They use lots of AI on their side (of course, none allowed on your side). A strange focus on your school years. Dark patterns in technical questions with no opportunity to get clarity. Ghosting afterwards. Interviews always involve some asymmetry but Canonical exploits that to the maximum.

parados

5 か月前議論

A professional pilots discussion on this accident [1] reorganised by subject matter [2].

[1] https://www.pprune.org/accidents-close-calls/663888-aa5342-d...

[2] https://paulross.github.io/pprune-threads/gh-pages/AA5342_DC...

parados

6 か月前議論

I think that you are confusing ACARS messages (those transmitted from the aircraft via airband radio or satellite) with ECAM messages (those that are displayed to the pilots). The former are mainly for operational reasons, for example so that ground engineers get forewarning of a failing component. ECAM messages are flight safety critical messages requiring pilot action and they are organised by priority.

ECAM messages are recorded by the DFDR/CVR but are not normally transmitted via ACARS. Pilots were not normally aware of ACARS messages (see MH370).

Your point is a fair one though. In the case of AF447 the crew, against their training, made no attempt at all to work their way through the multiple ECAM messages with the appropriate checklist so they died. The final report on QF32 shows what a high workload this can be.

Since AF447 was lost for nearly two years the ACARS messages were all that the investigators had to go on until they found the wreckage and the DFDR and CVR. Incidentally, one problem with those ACARS messages was that they are only timestamped to the minute and may arrive out of order which makes the interpretation of them more difficult.

parados

6 か月前議論

> they documented what they thought should happen instead of what actually happened.

The other way around. For example the Python C documentation is full of errors and omissions where engineers described what they thought should happen. There is a documentation project that describes what actually happens (look in the index for "Documentation Lacunae"): https://pythonextensionpatterns.readthedocs.io/en/latest/ind...

parados

7 か月前議論

For sure, it is on my TODO list. It takes a lot of work to explore each new Python C API and I'll get around to it when I can.

parados

7 か月前議論

Hey, thank you so much for all your hard work on psutil, it is my goto import! And this looks like a really interesting development you have created to add to the available tools for detecting those tricky memory leaks.

I have done some work in this space as well such as how to write a Python C extension without leaks in the first place [0]. This also contains a section on memory leaks, using tools like your psutil [1] This also shows where the Python documentation for C extensions contains errors, omissions or is misleading. These errors can trap the unwary.

Also I developed a Python memory tracer, pymemtrace, that uses a variety of techniques (including using your psutil!) to track memory usage at different costs and levels of granularity [2].

Now psutil 7.2.0 is out I'll update both those projects.

Thanks again for all your hard work.

[0] Project: https://github.com/paulross/PythonExtensionPatterns Docs: https://pythonextensionpatterns.readthedocs.io/en/latest/ind...

[1] https://pythonextensionpatterns.readthedocs.io/en/latest/mem...

[2] Project: https://github.com/paulross/pymemtrace Docs: https://pymemtrace.readthedocs.io/

parados

8 か月前議論

True, and I agree, but from their report they do seem to be doing Root Cause Analysis (RCA) even if they don't call it that.

RCA is a really bad way of investigating a failure. Simply put; if you show me your RCA I know exactly where you couldn't be bothered to look any further.

I think most software engineers using RCA confuse the "cause" ("Why did this happen") with the solution ("We have changed this line of code and it's fixed"). These are quite different problem domains.

Using RCA to determine "Why did this happen" is only useful for explaining the last stages of an accident. It focuses on cause->effect relationships and tells a relatively simple story but one that is easy to communicate - Hi there managers and media! But RCA only encourages simple countermeasures which will probably be ineffective and will be easily outrun by the complexity of real systems

However one thing RCA is really good at is allocating blame. If your organisation is using RCA then, what ever you pretend, your organisation has a culture of blame. With a blame culture (rather than a reporting culture) your organisation is much more likely to fail again. You will lack operational resilience.

parados

8 か月前議論

Got it. Thanks.

parados

8 か月前議論

> and my recent hyper-fixation (seems to spark up again every few years), the sinking of the Titanic.

But the rest of your comment reveals nothing novel other than anyone would find after watching James Cameron's movie multiple times.

I suggest you go to the original inquiries (congressional in the US, Board of trade in the UK). There is a wealth of subtle lessons there.

Hint: Look at the Admiralty Manual of Seamanship that was current at that time and their recommendations when faced with an iceberg.

Hint: Look at the Board of Trade (UK) experiments with the turning behaviour of the sister ship. In particular of interest is the engine layout of the Titanic and the attempt by the crew, inexperienced with the ship, to avoid the iceberg. This was critical to the outcome.

Hint: Look at the behaviour of Captain Rostron. Lots of lessons there.

parados

8 か月前議論

Former UK manufacturing engineer here (1980s onwards).

The manufacturing industry in the UK at that time suffered from three serious problems:

- Low productivity workforce. There was a huge pool of skilled, low wage, workers that had little incentive (or will) to up-skill. There were few apprenticeship schemes or other education programs to train them for the modern world.

- Poor quality management. "Working in trade" had a low social status compared to working in, say, the Civil Service. So the best and the brightest were not interested in manufacturing.

- Lack of access to capital. Banks were very reluctant to lend to that sector which made modernisation really difficult. With the ever present threat of nationalization it was hard to raise capital from shareholders. Why invest in technology when you could be nationalised on a whim?

I don't believe that these were significantly contributory, from experience:

- Margret Thatcher: whilst I'm no fan of her, at most she just administered the needle to a sector that was already on end-of-life support.

- The unions: I worked for a large engineering company (fully unionised) that had not had a strike for 30 years. We also introduced modern automation without resistence. The reason? Good management.

UK manufacturing is what long term decline looks like. Apart from a few small examples the UK has not been a world beater in manufacturing for fifty years or more.

On the other hand the UK is particularly good at Finance, Insurance etc.

parados

8 か月前議論

A C preprocessor implemented in Python: https://github.com/paulross/cpip

parados

9 か月前議論

Sort-of agree, but then I saw this code in the Visualiser[0]

    try:
        import matplotlib.pyplot as plt
    except Exception:
        plt = None
    
    class Visualizer:
    
        def animate_combined(
            # Stuff...
        ):
            # Stuff...
            try:
                import numpy as np
            except Exception:
                print("numpy is required for animation")
                return
            if plt is None:
                print("matplotlib not available - cannot animate")
                return

Is AI really that bad? Or has it been written by a human?

[0] https://github.com/sql-hkr/tiny8/blob/main/src/tiny8/visuali...

parados

10 か月前議論

Got it. Thanks.

parados

10 か月前議論

Those are your principles?

parados

10 か月前議論

Would you care to share those principles?

コメント