Tuesday April 11th, 2023 NCLUG Meeting

[Tom Propst]

I use this alias on all my development machines to give a graph view of git
branches similar to `tig --all`. You can replace all the options after
`--graph` with `--all` to see everything.

alias gl='git log --oneline --graph \
           --tags \

 --remotes={"origin/tom/*","origin/develop*","origin/main*","origin/master*"}
\
           --branches={"tom/*","develop*","main*","master*"}'

My branches are typically prefixed `tom/`. This shows my branches in
relation to the organization's primary branches.

On Tue, Apr 11, 2023 at 7:50 PM Bob Proulx <bob at proulx.com> wrote:

> j dewitt wrote:
> > What: Tuesday April 11th, 2023 NCLUG Meeting
>
> It was so nice of weather that I road my bicycle to the meeting for
> the first time this year.  Yay!  The usual hobknobbing at the start of
> the meeting occurred.  Sy's and Alex's graphics extraction project was
> a hot topic of that time.
>
> There was a discussion of how to run RHEL/CentOS software on an Ubuntu
> system.  How do you do this?  The idea was to run the odd-one out
> software in a chroot.  Which was being called a jail but a jail really
> implies more namespacing than just the chroot which namespaces the
> file system only.
>
> A little discussion about cameras and manufacturing overseas.  How do
> you prevent piracy?  Split the design into parts.  Have the different
> parts manufactured by different vendors and then assemble the parts
> along with the firmware at the last step.
>
> Robert reported his mountain was stolen from his back yard from a
> fenced in area!  Plus a dog.  Dog failed to deter.  It was suggested
> that thieves apparently are working areas with an enclosed truck,
> grabbing as many bikes as possible, and then taking them either out of
> state or across state.
>
> Aaron is always doing fun stuff and has a dual ISP network
> configuration going now.  That's a tricky thing!  So of course I
> prodded him to say more.  On goes the projector and we get a
> demonstration of the configuration.
>
> Linux Policy Routing.  Two WAN connections.  Comcast along with Allo
> fiber.  Bought a "multi-gig" dual NIC network card.  Multi-gig is the
> new-ish standard of 2.5 Gig or 5 Gig rated protocols that is now
> becoming available.  Has both public IP addresses connected to the
> public DNS name.  Review one of the problems.  The outbound must come
> back from the IP address that makes sense.  Can't exit a default route
> out on Allo for Comcast addresses, and not the reverse either.  Enter
> Linux Policy Routing.  Both modems being in bridge mode so the default
> routes are the ISP routers.  A little diversion down the Comcast
> support rants which we have all experienced ourselves too.
>
> Enter HAProxy. It is running on the same system with the dual NICs.
> Usually HAProxy would be used for one network in and multiple networks
> on the LAN side.  In this case it has multiple WAN networks.  But
> HAProxy has some advantages of being in the middle either way.  And
> Aaron has multiple LAN backends too.
>
>     https://www.haproxy.org/
>
> To get the network packets that came in back out to the correct WAN
> port some magic is occurring.  I only partially followed this but
> there are multiple routing tables.  There was some glue that is
> extracting the default route from the DHCP and inserting that into
> each particular individual route table.
>
> Enter Linux Network Bonding.  That's a technique where Linux
> networking will bond or "trunk" two network devices together.  There
> are various bandwidth sharing and fallover modes.
>
> Honestly I think there is some magic happening in there somewhere.
> But we had the demonstration that showed the redundant link operating!
> Can't argue with the results!
>
> Stephen took over and talked a little bit about his development
> environment.  Demonstrated "gitk" which is a graphical browsing
> interface to git.  Which works perfectly if you have a local clone of
> the git repository.  Which your company might not want you to be doing
> and might instead want you to be working across the planet in a remote
> data center on a remote VM in which case it does not work very speedy
> at all.  Enter Visual Studio Code.  It has capability to run local and
> then connect to the remote files.  This can work very much like gitk
> but over a remote explorer.
>
> Additionally there is tig (git spelled backwards) which is a curses
> based git repository browser.  And tig can run inside vscode.  That
> combination makes working on a remote system over the WAN half way
> around the planet workable without a lot of latency.  (Bob: It's funny
> that we have come back to the beginning.  In 1980 there was huge
> serial port use.  In 1990 everything became graphical.  In 2020
> everything became remote and remote graphics is frustratingly slow so
> there is a return to serial interfaces such as curses in order to have
> acceptable interactive performance.)  Working with remote mode in
> vscode makes working remotely acceptable again.
>
> Kyle mentioned sshfs which can also work well when working remotely.
> For example I can play a video over sshfs no problem.  But sshfs still
> has the latency round trip when stat(2) is called to get the timestamp
> of a file.  Many things do a lot of stat() calls and sshfs will be
> latency bottlenecked in the presence of a lot of stat()s.  sshfs works
> through bastion hosts excellently though because ssh does.  Mosh on
> the other hand does not work through bastion hosts without a custom
> UDP proxy solution.  Mosh is another tool for high latency WAN
> situations.  Works great for interactive stuff.  But does not work at
> all for the rest of the things we need remotely.
>
> Sy has an old iMac that is now long out of Apple support and has been
> trying to get it to boot a Linux kernel.  Then at least the machine
> would have a second life.  This machine has a 64-bit CPU but a 32-bit
> bootloader.  Endlessly problematic.  Only supports 32-bit EFI booting.
> But has a 64-bit CPU.  Obviously booting a 32-bit kernel has problems
> with newer operating systems has problems because for example Ubuntu
> no longer supports 32-bit systems.  Was able to get Debian's 32-bit
> i386 system booted.  And that was able to drive the AMD GPU okay.
> After much hassle Sy was able to bodge the 32-bit EFI to boot a 64-bit
> Linux kernel.  Woot!  But the 64-bit system is not currently able to
> drive the AMD GPU so no graphics at this moment.  That's the current
> snag.  It's booting a 64-bit Linux kernel but the AMD GPU is not
> working yet for graphics.  But the character vt virtual terminal
> console works so that is something.  On to figure out the graphics.
> If it isn't one thing it is another thing!
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.nclug.org/pipermail/nclug/attachments/20230411/e8dbdaa9/attachment.htm>