Tuesday April 11th, 2023 NCLUG Meeting
Tom Propst
tom.propst at gmail.com
Wed Apr 12 04:04:57 UTC 2023
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>
More information about the NCLUG
mailing list