Tuesday May 9th, 2023 NCLUG Meeting

[Sean Reifschneider]

"Hey ChatGPT, the following text was scanned from a book and then run
through OCR, which introduced a number of OCR errors.  Can you fix them for
me?  [book page text]"

I wonder how well that'd work.

On Tue, May 9, 2023 at 7:41 PM Bob Proulx <bob at proulx.com> wrote:

> j dewitt wrote:
> > What: Tuesday May 9th, 2023 NCLUG Meeting
>
> We had several new faces in the group tonight.  AWESOME!  If you have
> been contemplating meeting up then there is no time like the present.
> Come on down!
>
> Stephen started things off with an interesting tidbit about DHCP.
>
>     watch ip addr show dev wlan0
>
>     2: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue
> state UP group default qlen 1
>         link/ether 20:1e:88:78:61:94 brd ff:ff:ff:ff:ff:ff
>         inet 10.1.10.17/24 brd 10.1.10.255 scope global dynamic wlan0
>            valid_lft 6387sec preferred_lft 6387sec
>         inet6 fe80::221e:88ff:fe78:6194/64 scope link
>            valid_lft forever preferred_lft forever
>
> With the interesting bit being the valid_lft valid time left for the
> DHCP leas.
>
>            valid_lft 6387sec
>
> That does seem to be new in my recollection.  This feature apparently
> originated with Red Hat but then by popular demand was pulled into
> other distros subsequently.  (The RFC this is defined in is for IPv6
> not IPv4 but hey why not?  Extra can be okay.  I would rely upon it
> for IPv6 and be cautious about IPv4. --rwp)
>
> Stephen's second item was an X Window debugging tool "xtrace" to
> display the communication between X clients and the X server.
> Effectively xtrace is a proxy server which sits in the middle printing
> out what the X client is doing as it talks to the actual X server.
>
> The reason for this need was because Stephen was experiencing a
> slowdown for some reason.  A particular VMWare client application was
> tremendously slow.  Not every program.  Just that one program.  Every
> time focus shifted the system was going out and probing everything to
> determine the number of displays, the size, the display depth, and all
> of the rest of the things that are important at start.  But probably
> not each and every time focus changes.
>
> To hack around this slowdown problem Stephen grabbed the source code
> and hacked in a filter for these particular messages.  Filtered out
> the slow egregious and slow commands.  GetScreenResources.  And
> immediately the speed was much faster.  Problem worked around.  Maybe
> the offending program can be fixed but that's a vmware program.
>
> Alex and Sy then took the floor to talk about their Firefox
> adventures.  It turns out that compiling Firefox from source takes a
> while.  It takes a while on a fairly high performance machine.  This
> adventure was because Firefox is the new OS and there are some
> customizations which are possible by modifying the source but not
> (yet) exposed to the user.  (Personally I would like to see my
> keybindings uniformly applied.  I hate it when I have a textarea being
> edited and I forget and hit Control-N a couple of times and it opens
> up several new window frames.  Drat!  --rwp)
>
> This was a fun discussion of several interesting points of the
> internal data flow through Firefox.  Makes me want to get my source
> compile going again.  I just haven't been playing with the source
> enough lately.  Because that is where things can be truly customized.
> Check out the 2023-04-05 blog posting for it!  Cool stuff!
>
>     https://i330.dev/posts/
>
> Bob then gave an update on his NAS disk array recovery.  The TL:DR; of
> it is that never give up if you think the data is still there.  The
> problem looked like too many disk failures but the problem was my disk
> controller which seems to have flaked out.  In the end figuring out
> that it was the disk controller and replacing it allowed 100% of the
> array to be recovered.  Whew!
>
> Sy is doing some personal book archiving using a camera and software
> to do OCR to convert the photo over to plain text.  Says that the
> conversion is in the high 90's % of accuracy.  Which though not
> perfect is quite good.
>
>     https://en.wikipedia.org/wiki/Tesseract_(software)
>
> It was fun!  Come and show off your project next tim!  See ya!
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.nclug.org/pipermail/nclug/attachments/20230510/590c45ad/attachment.htm>