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