bringing master to gh-pages

Gemfile

@@ -34,6 +34,9 @@ gem "wdm", "~> 0.1.1", :platforms => [:mingw, :x64_mingw, :mswin]
 # do not have a Java counterpart.
 gem "http_parser.rb", "~> 0.6.0", :platforms => [:jruby]
 
-gem "webrick", "~> 1.7"
+#gem "webrick", "~> 1.7"
+#gem "webrick", ">=2.2.8"
 
 gem "jekyll", "~> 3.9"
+
+gem "webrick", "~> 1.8"

Gemfile.lock

@@ -1,35 +1,46 @@
 GEM
   remote: https://rubygems.org/
   specs:
-    activesupport (6.0.6)
+    activesupport (6.0.6.1)
       concurrent-ruby (~> 1.0, >= 1.0.2)
       i18n (>= 0.7, < 2)
       minitest (~> 5.1)
       tzinfo (~> 1.1)
       zeitwerk (~> 2.2, >= 2.2.2)
-    addressable (2.8.1)
-      public_suffix (>= 2.0.2, < 6.0)
+    addressable (2.8.7)
+      public_suffix (>= 2.0.2, < 7.0)
     coffee-script (2.4.1)
       coffee-script-source
       execjs
     coffee-script-source (1.11.1)
     colorator (1.1.0)
-    commonmarker (0.23.6)
-    concurrent-ruby (1.1.10)
-    dnsruby (1.61.9)
-      simpleidn (~> 0.1)
+    commonmarker (0.23.10)
+    concurrent-ruby (1.3.4)
+    dnsruby (1.72.2)
+      simpleidn (~> 0.2.1)
     em-websocket (0.5.3)
       eventmachine (>= 0.12.9)
       http_parser.rb (~> 0)
     ethon (0.16.0)
       ffi (>= 1.15.0)
     eventmachine (1.2.7)
-    execjs (2.8.1)
-    faraday (2.7.1)
-      faraday-net_http (>= 2.0, < 3.1)
-      ruby2_keywords (>= 0.0.4)
-    faraday-net_http (3.0.2)
-    ffi (1.15.5)
+    execjs (2.9.1)
+    faraday (2.12.0)
+      faraday-net_http (>= 2.0, < 3.4)
+      json
+      logger
+    faraday-net_http (3.3.0)
+      net-http
+    ffi (1.17.0-aarch64-linux-gnu)
+    ffi (1.17.0-aarch64-linux-musl)
+    ffi (1.17.0-arm-linux-gnu)
+    ffi (1.17.0-arm-linux-musl)
+    ffi (1.17.0-arm64-darwin)
+    ffi (1.17.0-x86-linux-gnu)
+    ffi (1.17.0-x86-linux-musl)
+    ffi (1.17.0-x86_64-darwin)
+    ffi (1.17.0-x86_64-linux-gnu)
+    ffi (1.17.0-x86_64-linux-musl)
     forwardable-extended (2.6.0)
     gemoji (3.0.1)
     github-pages (227)
@@ -197,35 +208,48 @@ GEM
       gemoji (~> 3.0)
       html-pipeline (~> 2.2)
       jekyll (>= 3.0, < 5.0)
+    json (2.7.2)
     kramdown (2.3.2)
       rexml
     kramdown-parser-gfm (1.1.0)
       kramdown (~> 2.0)
     liquid (4.0.3)
-    listen (3.7.1)
+    listen (3.9.0)
       rb-fsevent (~> 0.10, >= 0.10.3)
       rb-inotify (~> 0.9, >= 0.9.10)
+    logger (1.6.1)
     mercenary (0.3.6)
     minima (2.5.1)
       jekyll (>= 3.5, < 5.0)
       jekyll-feed (~> 0.9)
       jekyll-seo-tag (~> 2.1)
-    minitest (5.16.3)
-    nokogiri (1.13.9-x86_64-darwin)
+    minitest (5.25.1)
+    net-http (0.4.1)
+      uri
+    nokogiri (1.16.7-aarch64-linux)
+      racc (~> 1.4)
+    nokogiri (1.16.7-arm-linux)
+      racc (~> 1.4)
+    nokogiri (1.16.7-arm64-darwin)
+      racc (~> 1.4)
+    nokogiri (1.16.7-x86-linux)
+      racc (~> 1.4)
+    nokogiri (1.16.7-x86_64-darwin)
+      racc (~> 1.4)
+    nokogiri (1.16.7-x86_64-linux)
       racc (~> 1.4)
     octokit (4.25.1)
       faraday (>= 1, < 3)
       sawyer (~> 0.9)
     pathutil (0.16.2)
       forwardable-extended (~> 2.6)
     public_suffix (4.0.7)
-    racc (1.6.0)
+    racc (1.8.1)
     rb-fsevent (0.11.2)
-    rb-inotify (0.10.1)
+    rb-inotify (0.11.1)
       ffi (~> 1.0)
-    rexml (3.2.5)
+    rexml (3.3.7)
     rouge (3.26.0)
-    ruby2_keywords (0.0.5)
     rubyzip (2.3.2)
     safe_yaml (1.0.5)
     sass (3.7.4)
@@ -236,24 +260,33 @@ GEM
     sawyer (0.9.2)
       addressable (>= 2.3.5)
       faraday (>= 0.17.3, < 3)
-    simpleidn (0.2.1)
-      unf (~> 0.1.4)
+    simpleidn (0.2.3)
     terminal-table (1.8.0)
       unicode-display_width (~> 1.1, >= 1.1.1)
     thread_safe (0.3.6)
-    typhoeus (1.4.0)
+    typhoeus (1.4.1)
       ethon (>= 0.9.0)
-    tzinfo (1.2.10)
+    tzinfo (1.2.11)
       thread_safe (~> 0.1)
-    unf (0.1.4)
-      unf_ext
-    unf_ext (0.0.8.2)
     unicode-display_width (1.8.0)
-    webrick (1.7.0)
-    zeitwerk (2.6.6)
+    uri (0.13.1)
+    webrick (1.8.1)
+    zeitwerk (2.6.18)
 
 PLATFORMS
-  x86_64-darwin-18
+  aarch64-linux
+  aarch64-linux-gnu
+  aarch64-linux-musl
+  arm-linux
+  arm-linux-gnu
+  arm-linux-musl
+  arm64-darwin
+  x86-linux
+  x86-linux-gnu
+  x86-linux-musl
+  x86_64-darwin
+  x86_64-linux-gnu
+  x86_64-linux-musl
 
 DEPENDENCIES
   github-pages (~> 227)
@@ -265,7 +298,7 @@ DEPENDENCIES
   tzinfo (>= 1, < 3)
   tzinfo-data
   wdm (~> 0.1.1)
-  webrick (~> 1.7)
+  webrick (~> 1.8)
 
 BUNDLED WITH
-   2.3.26
+   2.5.16

_layouts/post.html

@@ -1,6 +1,7 @@
 ---
 layout: default
 ---
+<script src="{{ "/assets/mermaid-9.3.0/mermaid.js" | relative_url }}"></script>
 <article class="post h-entry" itemscope itemtype="http://schema.org/BlogPosting">
 
   <header class="post-header">

_posts/2022-12-15-dircmp.py-improvements.markdown

@@ -0,0 +1,146 @@
+---
+layout: post
+title:  "dircmp.py - a plan to improve and extend"
+categories: unix python
+---
+
+## dircmp.py
+
+### A plan to improve and extend
+
+This note pertains to [dircmp.py](https://github.com/decuser/decuser_python_playground/blob/master/dircmp/dircmp.py) a program that I wrote to give me information about two directories for the purpose of deciding what to keep and what to remove and to learn about python. The note is a draft note and as such it's not very refined and it may lack in many ways, but I thought it might be interesting to put it out there and let anyone see it. Email me if you have comments or suggestions.
+
+<!--more-->
+
+#### Caveats
+
+The comparisons here are between simple folders and files (including hidden files). By simple, I don't mean small - I use the program to compare very large directories. However, the tool was developed for comparing directories containing user files and not as a system maintenance tool. I haven't done much investigating of hard / soft symlinks or exotic setups.
+
+#### Random Observation
+
+When originally creating the program, I had the thought that git's organization would provide an ideal filesystem for keeping changes and being able to see those changes easily. Just keep file contents in blobs, their digests, names, and locations elsewhere. Files with identical contents would share the blob and digests, but the names and locations could differ. When saving a new file, do a digest, check the registry, link to the blob, etc. Sure, it'd be slow, but integral. A little above my paygrade, but percolating in the back of my mind. 
+
+#### Features under consideration
+
+* Synchronization Planning
+* Synchronization Execution with Undo and potentially segregation
+
+#### Other potential enhancements
+
+* Historical comparisons (save results and use for future compares)
+
+#### Future research
+
+* symlinks and exotic setups :)
+
+#### Background
+Currently, the program does a great job of identifying differences and matches between two directory trees. However, it does not do a good job of providing the user with plans to synchronize those trees or the ability to synchronize directories.
+
+When I started this project, my goal was to identify, not address, so the program met its objectives. Now, I want to have the program generate plans to synchronize and perform the synchroniztion.
+
+#### Current functionality
+
+Looking at the program as a whole and as a black box, it takes a directory or pair of directories and compiles a set of results...
+
+##### Results
+
+Pair Results Report
+
+* duplicate files found in either directory
+* exact matches found in both directories
+* files that only exist in one of the directories
+* files that have the same names but different digests
+* files that have different names but same digest
+
+Single Results Report
+
+* duplicate files found in directory
+
+##### Method of Operation
+
+The comparisons are done using a calculated digest for every file that exists within the scope of the comparison, either a single level, or recursive.
+
+##### Options
+
+The program supports the following options for controlling its behavior:
+
+* -h, --help - show a help message and exit
+* -b, --brief - Brief mode - suppress file lists
+* -a, --all - Include hidden files in comparisons
+* -r, --recurse - Recurse subdirectories
+* -f, --fast - Perform shallow digests (super fast, but necessarily less accurate)
+* -d, --debug - Debug mode
+* -c, --compact - Compact mode
+* -s, --single - Single directory mode
+* -v, --version - show program's version number and exit
+
+#### Discussion
+
+All in all, it works great. I've used it a lot. It's fast and accurate. However, in using it, it has become apparent that what I really want it to do is tell me how to get two directories to synchronize.
+
+I have used rsync (prolly best of breed) and tried many, many other programs to quickly and easily sync directories, and I haven't liked any of them, in the end. Usually, I wind up losing files that I don't want to lose, sometimes through unintentional misuse of the tool, especially with rsync's arcane syntax, but usually through an inability to figure out what the tool actually does (not how it does what it does, but what the results are) and thinking two directories are synced after running the tool only to find out later that they weren't ... not exactly.
+
+At least with dirsync.py as it exists today, I know exactly what it is doing. The results are detailed and precise. It lives to tell me, in detail, what differences exist between two directories. With this information in hand, it is possible to determine a finite plan to synchronize them.
+
+Interestingly, synchronization can be accomplished with several distinct outcomes, as follows.
+
+#### Synchronize how?
+
+In the following discussions, I will use left and right to differentiate the two directories being discussed and will only discuss synchronizing two directories.
+
+##### One Way Synchronizations
+
+* Left to Right - *right directory is made to exactly match the left directory*
+* Right to Left - *left directory is made to exactly match the right directory*
+
+Conflicts arising in one way synchronizations are resolved by order definition - files and directories from one side are chosen whenever there is a mismatch.
+
+##### Two Way Sychronizations
+
+Whenever two way synchronizations are performed, there is a likelihood of conflicts and it is important to consider strategies to resolve those conflicts. This is where synchronization gets tricky.
+
+Here are the possible strategies
+
+* Preserve None - *remove conflicts from left and right (neither win)*
+* Preserve Left - *merge left into right (left wins)*
+* Preserve Right - *merge right into left (right wins)*
+* Preserve Both (versioning) *merge both ways (both win) and create versions when there is a conflict*
+
+
+##### Thoughts before diving into the details
+
+I think that inline with providing undo, it may be useful to preserve conflicts for the user... as in, when there's a conflict, move the loser (one side, or both) into a separate area (preserving prior location information) for the user to decide what to do with. Given a robust enough functionality, this may be moot, but I remember doing this sorta thing before and it being useful.
+
+#### Rough sketch strategy
+
+* Analyze directories to determine what needs to change
+* Report status
+* Stage changes
+* Make changes (as economically and safely as possible)
+ * Stage a modification
+ * Save recovery information
+ * Make the modification
+* Report changes
+
+#### Thoughts related to the economics
+
+The expenses in this program are the costs of computing digests, comparing those digests, and copying files. Deletions are cheap, as are moves. So, the program should only compute digests as requested. When fast mode is active, the algorithm only reads a portion of the file, rather than the entirety, so this must be taken into account. Comparisons of the digest are mandatory. Copying files is expensive and should be minimized.
+
+Interestingly, when I started looking at this part of the code, I figured out that my fast digest approach probably needs to be improved. My premise, when I wrote it was that big files tend not to change in small ways over time - movies, images, and such. So, files over 10MB were considered candidates for an optimization of the digest process... This has proved to be a good intuition, but there are certainly some exceptions that could cause problems with the simple approach currently in the code (read the file size in bytes, read the first 1MB and the last 1MB and use these for the digest). I remember coming up with a strategy more along the lines of 100MB being the threshold and taking 100MB of random samples from the file. I don't remember why I changed it, but it was prolly just a matter of it taking too long and/or being somewhat more complicated to implement for the time I set aside to do the work... either way, the current code is quite basic, but fast... and it's worked fine because the only large files that I've used it on have been normal user files that simply don't change much in the middle. Still, this is definitely an area to optimize. The easiest example of a file that would be problematic that I can think of is a VM drive file... When in doubt, don't use fast mode :). 
+
+#### Stuff to think about
+
+* Fast digest - what's a better approach that's still fast (sampling is slow, but is it necessary)?
+* I seem to remember counting being challenging - does the program count correctly or does it need a fix?
+* Symlinks are weird, but are they a problem?
+* How to develop a changeset - linear, in a single pass, what?
+* How to handle the undo functionality
+* What to do about destructive changes - save the to be destroyed file somewhere
+* How to handle duplicate versioning - naming, save somewhere
+* Given past experience, what to do about voluminous reporting - definitely need better delineation of sections (very hard to differentiate in terminal)
+* Tkinter? I dunno, I prefer something like avalonia, but that's .net, still should this have a ui?
+* Order to do the coding - left to right and right to left first, then merges, which preservation strategies in what order?
+
+The playground has the latest code and branches [https://github.com/decuser/decuser_python_playground](https://github.com/decuser/decuser_python_playground)
+
+*post last updated 2022-12-15 17:53:00 -0600*

_posts/2022-12-15-usenix-flame-award-2022.markdown

@@ -0,0 +1,55 @@
+---
+layout: post
+title:  "Warren Toomey Awarded 2022 USENIX Flame"
+categories: unix
+---
+
+Warren Toomey, the founder and maintainer of all things related to The Unix Heritage Society (TUHS) [https://www.tuhs.org/](https://www.tuhs.org/) has been awarded the 2022 USENIX Lifetime Achievment Award ("The Flame").
+
+Without TUHS, it would hardly even be possible to enjoy retro unix explorations. This is a well earned accolade by an unassuming and very hard working individual. 
+
+Congratulations, Warren!
+
+![flame](https://www.tuhs.org/Images/flame.jpg){: width="480" }
+
+
+<!--more-->
+
+### About Warren Toomey
+
+Warren retired in 2021 after a three decade career of teaching Computer Science and IT in tertiary institutions including the University of New South Wales, Bond University and TAFE Queensland (a polytechnic/community college). His teaching was always systems focussed: computer architecture, operating systems, systems programming, networking and cybersecurity. Warren was first introduced to Unix at the end of 1982 at a Summer School at the University of Wollongong, but lost access to it when he started his undergraduate degree in 1984. This loss was the driving force behind his fascination with Unix and its history. Fortunately, Minix, 386BSD and FreeBSD came along at just the right time to slake Warren's thirst for Unix. He founded the Unix Heritage Society in 1994 (originally named the PDP-11 Unix Preservation Society) and has nurtured it since. Now retired, Warren's interests now include dressage riding, and he has become a competent groom for his wife Kaz, a professional 'Big Tour' rider.
+
+### Past recipients of the Flame
+
+* Chet Ramey (2020)
+* Margo Seltzer (2019)
+* Eddie Kohler (2018)
+* Tom Anderson (2014)
+* John Mashey (2012)
+* Dan Geer (2011)
+* Ward Cunningham (2010)
+* In Honor of Gerald J. Popek (2009)
+* Andrew S. Tanenbaum (2008)
+* Peter Honeyman (2007)
+* Radia Perlman (2006)
+* Michael Stonebraker (2005)
+* M. Douglas McIlroy (2004)
+* Rick Adams (2003)
+* James Gosling (2002)
+* The GNU Project and all its contributors (2001)
+* Richard Stevens (2000)
+* The X Window System Community at Large (1999)
+* Tim Berners-Lee (1998)
+* Brian W. Kernighan (1997)
+* The Software Tools Project (1996)
+* The Creation of USENET (1995)
+* Networking Technologies (1994)
+* Berkeley UNIX (1993)
+
+Read more about the award and its recipients at [https://www.usenix.org/about/awards/flame](https://www.usenix.org/about/awards/flame)
+
+Read more about why Warren started TUHS at [https://minnie.tuhs.org/Blog/2015_12_14_why_start_tuhs.html](https://minnie.tuhs.org/Blog/2015_12_14_why_start_tuhs.html)
+
+\- will 
+
+*post added 2022-12-15 17:52:00 -0600*