Blog de Joe Freeman

Verify that your container can communicate with the GPU and the type of  NVidia GPUs your docker containers can access using one of NVIDIA's container images. docker run --rm --runtime=nvidia --gpus all ubuntu nvidia-smi  Sample Output The containers on this server have access to a single Titan RTX card Source This came from  Nvidia getting started with large language models Revision  Created 2024/07 

NVidia AI Workbench runs inside a containerized environment and I wanted an environment check that verifies the container has access and that docker/podman, the NVidia driver and Workbench are all on compatible versions.   Containerization has no effect on performance. The CUDA code is pretty much a direct pass-through to the card. Environment NVidia AI Workbench One local GPU Windows 11  Docker Desktop Program running in a container built by the Workbench based on the PyTorch/Cuda image Program I access the containerized environment via a Jupyter Notebook visible to the browser on the Windows machine. This is a snapshot of the Jupyter Notebook. numpy_cupy_sort.ipynb Gist It found a problem The program demonstrated that there was a container adapter (or something) mismatch that recently happened.  cupy returned that it had access to the GPU but it turns out that it really didn't and that a Docker Desktop upgrade was needed to fix something driver-related.  The error message was &qu

We try to prevent or catch failures in all kinds of everyday tasks.  The cat escapes. The dog eats the socks.  Someone leaves the garage door up at night. Failure mode analysis (FMEA) works for all kinds of problems.  We can apply a version of FMEA to the garage door problem and use it as an example that everyone understands and potentially solves an everyday problem. The talk I'm finally getting around to posting the content to this 2022 talk:  Working through all the ways to fix the problem that I don't always close the garage door Talk content These are the contents of the Keynote presentation used in the talk.  See the talk for an explanation. Related This was part of a series of FMEA talks  Blog Articles Throwing down failures  http://joe.blog.freemansoft.com/2021/01/failure-mode-analysis-ste-one-throwing.html Detection and remediation  https://joe.blog.freemansoft.com/2021/02/failure-mode-analysis-step-two.html Videos Step 1: Throwing down failures  https://youtu.be/R

Rating system for meetings, team reviews, code reviews and, disaster war rooms. Bullshit - not true Dogshit - terrible Horseshit - nonsense Apeshit - angry Batshit - crazy The shit - the best Well Shit - disbelief Deep Shit - big trouble Additional meaning in other situations No shit - you don't say? Aint shit - deadbeat Good shit - this is awesome Most of these were pulled from an @threads thread. Revision History  Created 2024/04

Communication between Flutter modules and Mobile Native code happens over platform channels.  The docs are all over the place so I created this cheat sheet for the different channel types and their class documentation. YouTube walkthrough video Mobile Native Communication Communication between the Mobile native code and Flutter happens over platform channels. Web communication happens via window messaging. Flutter Channel types There are three native platform channel types. V1 of this application uses the  Message Channel Channel type and Flutter class Description Flutter Native Native Flutter Supports Return Method Invoke method on the other side Yes Yes Via result Message Sends a message to a remote listener Yes Yes Via reply Event Streams and sinks. Events can flow in both directions Yes Yes N/A Channel Implementation Classes Dart/Flutter, Android, and iOS have corresponding `channel` classes for each channel type. The three platform channel implementatio