We had the internet at home from my mid-late teens, and I found it hard to find radios interesting when we have all this cool shit a few modem beeps away. When Skype came along any chance of playing radios went out of the window, it was obviously far superior. However, now in my mid-40s and in the middle of a career where I solve fun problems using web technologies, I do not want to sit at my desk and play with the same things when I am trying to relax at then end of the day. I also remember a time before we had the internet in our homes, let alone our pockets, and I would love to roll the clock back, but this is a topic for another day. So at this stage in life playing around with older technology actually sounds quite fun. I finally understand the appeal challenging myself to make contacts with people over long distances, preferably using gear that I have built myself.

One of the pivotal moments in my journey is discovering that CW (Morse Code) has recently become more popular, not less. This mode of communication, with its distinctive audible tones, requires a much narrower bandwidth than voice transmission. For someone like me, who faces challenges with auditory clarity, this is a game changer. The simplicity and clarity of CW signals mean that I can decode them much more easily than spoken words buried under the hiss of an RF signal.

Another aspect of Amateur Radio that interests me is portable operations. I love the great outdoors, and we holiday in the Lake District every year. It seems so obvious to combine these two interests at the same time. There are organised activities like Parks on the Air (POTA) and Summits on the Air (SOTA) which will help me get started. Again, it is particularly appealing that when we operate away from the hustle and bustle of civilization, we also minimise noise. The further we are from electrical interference, the less noisy the airwaves become, thus allowing me to (hopefully) better hear the signals when receiving.

The technical side of amateur radio is another area that interests me. This hobby aligns perfectly with my previous interests like building guitar distortion pedals. I find it peaceful to break out my soldering iron and assemble a kit project, similarly to those that find puzzles or sudoku relaxing. The long-term goal of designing and building a multi-band transceiver from scratch is an aspiration that feels both thrilling and, frankly, a bit ridiculous given my current lack of knowledge. I have a lot to learn, and this hobby is a continuous learning experience.

I am excited about where this journey will take me next.

I am bored by my smartphone. I have owned an iPhone of some variety for thirteen years now, and I need a change. Change is good. I hate how I feel knowing it is in my pocket. This is not the right analogy, and so for want of a better way of describing this: it just feels like a ball and chain and a deadweight on my consciousness. Our time on this planet is precious, and I no longer want to waste it by staring at a phone screen. It lacks the value that I once appreciated.

Ditching my iPhone is not the only way to solve these problems, I could change the way I use the phone: Get rid of apps that are a time sink; install apps that are more positive... but nostalgia tells me I am going to be happier without it.

I am not surprised that attempting this switch has turned out to be a multiple-attempt process. Because I thought this might be the case, I did not put too much effort into it. For now, I am going to call this attempt a success because I learned a bunch about the positives as well an encountering the unexpected pain points; and I now know what I need to adjust before my next attempt.

My ultimate goal is: To see if a life without a smartphone is possible for me, and whether I will be happier and more fulfilled not having one.

What was my plan?

If I am able to ditch a smartphone I need to figure out what I am going to replace the many features that we love.

• Telephone: I bought a 4G Nokia 105, which obviously replaces the calling and text messaging features.
• Camera: Carry around my Fuji X-T1 with the flattest lens I own, which happened to be Fuji's F2 18mm, to reduce its bulkiness. I would have liked to have one of Fuji's X100 series as they are highly compact whilst producing stunning photos.
• Maps: These are a convenience of modern life, but most the time I do not really need it. If I am in an unfamiliar city, I would just buy a paper map, even a tourist map might do, or if in London an A-Z. Our main car has a built-in sat-nav, even if the UX is a bit shit, it would do.
• Group messaging: I cannot get rid of these, but I do not need them on me all the time, everywhere I go. I propose checking group chats once every day either from my iPad or one of my computers.
• Something to read: This is the key, I want to replace doomscrolling, with a book. If I am short of space in my bag, then I would carry around something smaller than whatever the current fantasy tome I am working my way through is.
• Something to listen to, music, podcasts, audiobooks: My old 5.5 generation, 30gb, white iPod. I love this little thing, but more on it later.
• 2fa: Ugh. I do not have a great solution for this. But since my old iPhone is going in a drawer next to my desk, I continued to use that. If I needed to travel for work, I would probably pack my iPhone for emergency 2fa!
• Calendar, todos, general notes: A paper notebook.

How did it go?

Mostly OK. I managed a little under 3 weeks. But I was ill for most of this, and I did not leave the house much as I might usually. So this was not an entirely fair test. However, I learnt enough from it to have a new perspective.

The Nokia 105 4G, I chose because it was cheap, and I can tether a laptop/iPad to it. I would have preferred to have a Punkt mp02 4G, but I cannot drop £300 on an experiment. The main issue with the Nokia is that the audio quality on this thing is awful in comparison to a smartphone. At this price (£20), I am not surprised. But I had hoped using wired earbuds (with a mic) would have been better. They were for me, but not for the person at the other end. I need to repeat this test with some other headphones I have. If the mic in the headphones I used are to blame, then I can easily replace those and hold of buying another phone for the next attempt.

I loved having a proper camera on me when I was out and about. I took more photos, better photos, and I enjoyed the process more. Just throwing my camera in my daily bag felt rather dangerous, I am very precious about camera gear. I think that next time I will grab a small soft camera cube insert for my daily bag so that I can protect it from whatever other junk I keep on me, e.g. keys!

Other features like maps, group messaging, I did not miss when away from my computer. I enjoyed carrying a book around, and the notebook worked well to replace my calendar, todos, etc.

Overall this was a positive process.

How did I get on with the iPod...

This is where I got stuck, and eventually switched back to the iPhone about 3 weeks in...

I loved the audio quality and after a little research it seems that this particular iPod has a highly sought after DAC chip in it. I do not miss bluetooth one bit.

Surprisingly, I did not mind having to sync podcasts over once a day. I did not miss needing the latest podcasts injected into my device at supersonic speeds. I also found that not having the latest podcasts changed how I listen to podcasts: I prioritized them differently, and I explored others that I have subscribed to, but don't usually listen to.

My setup for syncing was, very awkward, and not a great long term solution. I use Linux on my laptop and desktop, no longer using a Mac makes syncing the iPod difficult. I tried gtkpod (which failed to build), and Rhythmbox (could not sync audiobooks or podcasts properly).

An aside... My research seems to indicate that most people are happy just copying files over to the ipod and listening to them like you would listen to music. But podcasts and audiobooks are different. Unlike music, you want to pause them, listen to something else and resume them later. Podcasts you want to be automatically removed once you have listened to them. The way the 5.5G iPod does this is by maintaining a proprietary database which is not on the hard-drive, but on a chip on the board. I believe that communicating with this has not been reverse engineered, and so open source software like Rhythmbox cannot sync podcasts and audiobooks properly.

In order to sync music, audiobooks, and podcasts properly, I installed Windows XP on VirtuaBox, and then installed iTunes 9. Ugh!

Then I discovered that despite patching WinXP, it seems that iTunes had its own SSL implementation and thus could not subscribe to any HTTPS podcasts, which they all are now. So I wrote a podcast mirror served over HTTP on my local network. This allows me to mirror the podcasts locally then pass these on to iTunes over HTTP rather than HTTPS.

Then I found that audiobooks over a certain length did not play properly. In fact when I discovered this, I was instantly taken back to the late 2000s when I remember buying an audiobook on iTunes and discovered these were split up to combat this issue. I was curious why they were split up, and never found out until now, but now I know. I now need to figure out if I want to write a script to split all of my recently backed up (de-DRM'd) audiobooks so they are iPod compatible. Ugh.

During all of this I did consider installing the Rockbox firmware on it. I may still take that route, but I think I want to see if I can set up a development version of Rockbox via a simulator or similar... I want to see what the experience of syncing from Rythmbox to Rockbox is before committing to this approach.

Conclusion

So the reason to stop the experiment was because I needed to take some important phone calls, and the audio quality of the Nokia was not reliable.

I think I could have switched back and found solutions to the Nokia audio issues in good time, but I found the syncing issues with the iPod too painful and time-consuming to solve, so for now, I just gave up!

My todo list is as follows:

1. Test some other headphone mics with the Nokia to see if the call quality can be improved.
2. Setup Rockbox in a dev environment to test syncing with a Linux based audio app like Rythmbox.
3. If the above works, and if I still need to after using Rockbox, find/write a script to split audiobooks so that they are under a certain length, and are split on chapters.

I have tweaked the design here though! Yellow usually looks awful on screens, but I quite like this shade combined with pink link highlights.

Whilst the papers complain about all our sports being mildly interrupted by Just Stop Oil, are the protesters the only sane people left on this planet?

In 2021, a survey found that three-quarters of adults in Great Britain worry about climate change, but the politicians do nothing?

What is the only sane response to all this inaction, insanity?

What should I do? What should WE do?

Should we march in the streets?

Should we disobey?

How should I vote? I hear no policies or political will to practically fix our broken planet.

How do I teach my Daughter to live in this crazy, crazy world? This world I love so much. With these crazy people who did nothing.

I did something though, I wrote a blog post, and that made all the difference.

We have one planet, there is no plan B.

Fuck.

Having admitted that, I think it is really hard to do. I have seen colleagues and clients struggle with this as well. They have a desired feature list, and nothing is going to stop them from insisting that every feature is needed to launch their amazing application. That is until they realise how much it's going to cost. Then it seems that some of the features are more nice-to-haves. But, enough about other people, I cannot seem to finish any of my projects, and I want to fix that.

I have a new project that I want to start, several actually, so to be successful by my standards I need to understand what is going on. I have brainstormed a few possible causes and improvements I can make, and it sort of boils down to two main things:

Be brutally minimalist

Remove all the features/desires that are not needed to publish the website, app, or codebase. There should be one goal/feature. Build that, and that only. This means:

• Treat every project like a hack-day. Have a limited timeframe with which to launch it. You can fix issues or add features later.
• For example, include no user sign-up. Most of the web apps I build as personal projects are for me, and whilst I may want authentication this can be achieved by slapping http basic auth in the nginx.conf. It takes 5 mins.
• No, or very basic design/CSS. Honestly, I am not a frontend dev, and just do not care. That can come later. e.g. pinboard.in has been very popular with only minimal CSS.
• No automated tests. Some devs will find it easy to get behind this principle, and some will not. It may be faster for you to adhere to proper TDD methodologies, but if you are building something small, just build it and stick it online. Add tests later, and save TDD for bugs and maintenance issues.
• Use a framework that allows you to move quickly and doesn't get in your way. For me, this would be Flask or Django. I love the one file Flask setup that allows me to set up a few routes quickly.
• Proudly built elsewhere. Use third party code to achieve your aims, but only if it will be quicker to learn someone else's tool than to build your own.

Be conscious about how productive you want to be

Everyone has a busy life, me included. I am not 20 anymore, and my carefree attitude to my time has gone and has been replaced by a family and house and a life that need my time. This means that every minute is sacred and must be spent wisely, so I should plan how I am going to spend my time so that my latest project gets completed and launched.

• Write down everything I need to do to complete and launch/finish the project.
• Remove every step that can be faked or added later, be brutally minimalist.
• If it can be completed in an afternoon/day, set aside time to do this, and crack on with it.
• If you cannot complete it in a day, then make time to work on the project for 20 minutes every day. Regularly touching the codebase or planning tools will keep the momentum going.

Final thoughts

Who knows if this approach will work. I will have to revisit this post to see what if any of these approaches helped.

As well as writing software, I wonder if I need a brutally minimalist approach to blogging. I want to write more here, this site is unloved.

Sources

• kubernetes.io/docs/tutorials/hello-minikube/
• someweb.github.io/devops/ingress-nodejs-app-kubernetes/

NodeJS app

A basic NodeJS app has been created, which on startup creates a unique ID and returns that ID on every subsequent http request. This will be used later for verifying that the pods are evenly load balanced.

The code for this is here: app/index.js

The container for this is on Docker Hub

Start Minikube

minikube start --vm=true --cpus 4 --memory 4098

Create a namespace for our project:

kubectl create namespace lb-test

K8s Deployment

Pods

Config file: deployment.yaml

To start with, a replica of two pods containing our NodeJS app have been configured. Having at least two pods is necessary to verify that the load balancer is balancing the traffic at a later step. The container port 3000 is exposed so that the app can receive connection from within the cluster.

Apply this configuration: kubectl apply -f deployment.yaml

Verify that these two pods have started:

$ kubectl get pods -n lb-test
NAME                                       READY   STATUS    RESTARTS   AGE
load-balancing-test-app-8468bd8785-sjtn8   1/1     Running   0          19s
load-balancing-test-app-8468bd8785-t62vh   1/1     Running   0          19s

Service (Load balancer)

Config file: service.yaml

This creates a new service, a load balancer, which balances traffic from port 80 to port 3000 of all pods labeled load-balancing-test-app.

Apply this configuration: kubectl apply -f service.yaml

Verify that this configuration has been applied:

$ kubectl get service -n lb-test
NAME                      TYPE           CLUSTER-IP     EXTERNAL-IP   PORT(S)        AGE
load-balancing-test-app   LoadBalancer   10.96.65.215   <pending>     80:30793/TCP   7s

At this point the external IP is pending and not available. This is because Minikube is being used to manage the cluster and assign the external IP. To expose the external IP, run: minikube tunnel. Leave this process running to maintain the external IP address.

$ kubectl get service -n lb-test
NAME                      TYPE           CLUSTER-IP     EXTERNAL-IP    PORT(S)        AGE
load-balancing-test-app   LoadBalancer   10.96.65.215   10.96.65.215   80:30793/TCP   88s

The external IP has now been resolved and curl can be used to connect to the application pods via the load balancer service.

$ curl 10.96.65.215
App id: 562704180445

Ingress

Config file: ingress.yaml

By creating the pods and a load balancer service, there are now enough components to complete this K8s build and verify the load balancer service works as expected. However, this can be improved by using an ingress so that the app can be accessed using a domain name rather than an IP address.

Apply this configuration: kubectl apply -f ingress.yaml

Enable the ingress addon for Minikube:

$ minikube addons enable ingress
🔎  Verifying ingress addon...
🌟  The 'ingress' addon is enabled

Verify that this configuration has been applied:

$ kubectl get ingress -n lb-test
NAME             CLASS    HOSTS         ADDRESS          PORTS   AGE
mynode-ingress   <none>   lb-test.dev   192.168.99.100   80      104m

Add the domain and IP address to the local /etc/hosts file:

192.168.99.100 lb-test.dev

Verify the connection to the NodeJS app container using this new domain:

$ curl lb-test.dev
App id: 562704180445

Verifying the Load Balancer works as expected

There are three different ways to verify that the load is being distributed over the different pods, as expected:

• Verifying the service is correctly configured
• Verifying the pods are returning different IDs in their responses
• Verifying the pods are logging different IDs

Verifying the service is correctly configured

Verify that the K8s Load Balancer service is set up and configured using the kubectl describe command:

$ kubectl describe service load-balancing-test-app -n lb-test
Name:                     load-balancing-test-app
Namespace:                lb-test
Labels:                   <none>
Annotations:              <none>
Selector:                 app=load-balancing-test-app
Type:                     LoadBalancer
IP Families:              <none>
IP:                       10.96.65.215
IPs:                      10.96.65.215
LoadBalancer Ingress:     10.96.65.215
Port:                     <unset>  80/TCP
TargetPort:               3000/TCP
NodePort:                 <unset>  30793/TCP
Endpoints:                172.17.0.3:3000,172.17.0.4:3000
Session Affinity:         None
External Traffic Policy:  Cluster
Events:                   <none>

There are a few important lines in this output that demonstrate that the service is set up correctly.

Type:                     LoadBalancer
Port:                     <unset>  80/TCP
TargetPort:               3000/TCP
Endpoints:                172.17.0.3:3000,172.17.0.4:3000
External Traffic Policy:  Cluster

These lines could be described in English as: There is a load balancer service, listening on the default http port, and evenly distributing all traffic to the two application pods on port 3000.

The line External Traffic Policy: Cluster is interesting because this describes the traffic as being evenly distributed between each endpoint within the cluster (default behavior).

Verifying the pods are returning different IDs in their responses

You will remember that each application pod returns a unique ID when that page is requested over http. Curl can be run in a loop to verify that the traffic is being evenly distributed.

$ for i in {1..20}; do echo "$(curl -s lb-test.dev)"; done
App id: 368797613483
App id: 767595446753
App id: 368797613483
App id: 767595446753
App id: 767595446753
App id: 767595446753
App id: 767595446753
App id: 368797613483
App id: 767595446753
App id: 368797613483
App id: 368797613483
App id: 368797613483
App id: 767595446753
App id: 368797613483
App id: 767595446753
App id: 767595446753
App id: 368797613483
App id: 767595446753
App id: 767595446753
App id: 368797613483

Verifying the pods are logging different IDs

There should also be IDs logged after each http request:

$ kubectl logs -l app=load-balancing-test-app -n lb-test

listening on 3000, app id: 368797613483
App id: 368797613483
App id: 368797613483
App id: 368797613483
App id: 368797613483
App id: 368797613483
App id: 368797613483
App id: 368797613483
App id: 368797613483
App id: 368797613483
listening on 3000, app id: 767595446753
App id: 767595446753
App id: 767595446753
App id: 767595446753
App id: 767595446753
App id: 767595446753
App id: 767595446753
App id: 767595446753
App id: 767595446753
App id: 767595446753
App id: 767595446753
App id: 767595446753

Verifying these checks still apply when scaling up

Kubernetes is a valuable tool because it is often necessary to scale up/down resources to meet changing demands. By adding another pod and re-running these verifications it is possible to verify that the load balancer continues to spread the traffic over all all of it's pods. To do this, first modify deployment.yaml so that spec.replicas is changed from 2 to 3, and re-apply the config:

$ kubectl apply -f deployment.yaml
deployment.apps/load-balancing-test-app configured

Verify that the third pod is up and running:

$ kubectl get pods -n lb-test
NAME                                       READY   STATUS    RESTARTS   AGE
load-balancing-test-app-8468bd8785-sjtn8   1/1     Running   0          32m
load-balancing-test-app-8468bd8785-t62vh   1/1     Running   0          32m
load-balancing-test-app-8468bd8785-vlklz   1/1     Running   0          6s

Verify that the third pod is included in the load balancer service:

$ kubectl describe service load-balancing-test-app -n lb-test
Name:                     load-balancing-test-app
Namespace:                lb-test
Labels:                   <none>
Annotations:              <none>
Selector:                 app=load-balancing-test-app
Type:                     LoadBalancer
IP Families:              <none>
IP:                       10.96.65.215
IPs:                      10.96.65.215
LoadBalancer Ingress:     10.96.65.215
Port:                     <unset>  80/TCP
TargetPort:               3000/TCP
NodePort:                 <unset>  30793/TCP
Endpoints:                172.17.0.3:3000,172.17.0.4:3000,172.17.0.6:3000
Session Affinity:         None
External Traffic Policy:  Cluster
Events:                   <none>

Verify that the curl loop now returns three different app ids, rather than just two:

$ for i in {1..20}; do echo "$(curl -s lb-test.dev)"; done
App id: 767595446753
App id: 767595446753
App id: 368797613483
App id: 245752426860
App id: 368797613483
App id: 368797613483
App id: 767595446753
App id: 368797613483
App id: 245752426860
App id: 245752426860
App id: 767595446753
App id: 245752426860
App id: 368797613483
App id: 245752426860
App id: 767595446753
App id: 368797613483
App id: 767595446753
App id: 767595446753
App id: 368797613483
App id: 368797613483

And that the logs show three different IDs:

$ kubectl logs -l app=load-balancing-test-app -n lb-test

App id: 767595446753
App id: 767595446753
App id: 767595446753
App id: 767595446753
App id: 767595446753
App id: 767595446753
App id: 767595446753
App id: 767595446753
App id: 767595446753
App id: 767595446753
App id: 368797613483
App id: 368797613483
App id: 368797613483
App id: 368797613483
App id: 368797613483
App id: 368797613483
App id: 368797613483
App id: 368797613483
App id: 368797613483
App id: 368797613483
App id: 245752426860
App id: 245752426860
App id: 245752426860
App id: 245752426860
App id: 245752426860
App id: 245752426860
App id: 245752426860
App id: 245752426860
App id: 245752426860
App id: 245752426860

Now that we seem to have a vaccine on the horizon I feel confident enough to allow myself to start thinking about what my first steps out into the real world might look like.

In no particular order:

• Start a band.
• Go to a gig. Must be guitar-based, preferably with loud amps, optionally a genre I love.
• Go on a 'dinner & movie' date with my wife.
• See a football match. Oxford United will do, try to get tickets for Arsenal for some time in 2021.
• Start going to Oxford tech meetups again. I stopped going a couple of years ago. I do not know why, it just tailed off.
• I have missed seeing a lot of family and friends, get some weekends away sorted to visit and invite them to stay.

I'll likely update this if I think of much else.

This has happened to me over the last few weeks. Today I have been considering what the lesson learnt is.

I have been building a guitar pedal from a kit, it is not my first, I have built several, but it is the first that I planned to give to someone else. So I wanted this one to look professional, or at the very least neat and tidy. In all of my previous builds I have used at predrilled enclosure; however, with this build, I wanted to use a larger enclosure than the kit recommended so that I could fit a battery in as well. This meant that I could not buy the pre-drilled enclosure, but I have a drill, so that’s fine. How hard could it be? I also wanted to label the controls. Etching looked like it would be tricky, but would look beautiful. A sharpie would be much easier, but not look as nice. So I thought I would try metal stamping the enclosure, and filling the stamped impression with enamel paint.

I am now a man with a plan.

The first enclosure started ok, except I was missing a drill bit that I had to order online, which took a while to be delivered. Once I had all of the drill bits I successfully drilled out all of the holes without any problems. I started stamping the case with labels, but it was difficult. If you didn’t stamp it correctly the first time, lining the stamp up perfectly for a second attempt was pretty much impossible. The result of re-stamping to make a better impression resulted in it looking like two letters typed on top of each other. I decided that I needed a bigger hammer so that I could make a solid impression with the first blow, but I did not have one. By now some of the hardware stores had reopened, I waited a few days before picking up a 1kg hammer. This first attempt did not look great, it would have been better to just use a sharpie.

The following weekend, I practised stamping on the old case with the new hammer. The impressions were much better, not great mind you, but I was improving with practice. A second case had turned up as well, so I was able to get started again. But disaster struck almost immediately. I had rotated the case 180 degrees to better clamp it into the vice but instead of drilling one of the holes at 8mm, I drilled it at 12mm. By now the deadline for completing this case had been and gone, this gift was going to have to be late. So I soldiered on, I used a larger washer to allow that potentiometer to sit neatly. After completion, I had to admit I was not satisfied in presenting this to my friend as a gift. The larger washer was visible beneath the knob from all angles. So I ordered another new case and had to wait another week for it to be delivered.

Last weekend I completed the drilling, stamping, and assembly, and I am happy with the result. So what did I learn from this?

1. If you are attempting a new technique, make sure you have adequate time and spare materials to practice and experience the process thoroughly before you try it for real. If you make mistakes when it matters then it might be costly.

2. Know your tools well, practice with them, and discard tools that do not work well for you. If you do this you will become more efficient, and be happier.

3. Rushing to meet a deadline when you are unfamiliar with your tools and techniques makes everything worse.

These learnings apply to so many things, but I have also been thinking about this in the context of my day job as a software developer. We learn new tools and techniques all the time, but do we spend the time to get to know them properly? I probably know only a fraction of the capabilities of my IDE, yet I am frustrated with it regularly. I think I need to set aside some time to identify the parts of my tool kit that I need to get to know better.

I love that he thinks he is being trolled at the start, and the slow reveal that it is actually solveable. What a lovely chap.

(via my friend Garrett, via Metafilter)

All software developers have a responsibility to protect their users' data, audio, and video leaking from systems they have designed. They also have a responsibility to ensure that the systems that they run on are not open to being attacked or compromised. Zoom have repeatedly shown that they do not care about doing this. I do not really understand why though, other than the privacy/security issues, they have usable and popular software. They could be very, very successful in the long term. I suspect, but have no evidence, that management team or product owners are not listening to the development team; or possibly, the development team is incompetent. Either way, something is very wrong at Zoom.

Here are a few examples of their behaviour:

• Last summer - a security researcher pointed out that malicious websites could activate the user's webcam without the user's permission. Zoom would not agree that this was a security issue, instead claiming it was required to improve usability. Essentially, saying that usability is more important than security. Eventually, Apple had to step in an fix the vulnerability themselves.
• After pointing out the above issue, the security researcher had to decline the bug bounty payout because they wanted him to sign an NDA.
• This month - a security researcher has disclosed that Macs are vulnerable to webcam and mic takeover again.
• Zoom has been sending users activity to Facebook without their knowledge, whether they have a Facebook account, or not. This feature/bug has now been removed, but not before the New York AG has started an investigation.
• When installing Zoom on a Mac Zoom circumvents the standard installation process to install their software. I believe that this is a flaw in the Apple installation system, and not really Zoom's responsibility; however, they choose to bypass it when they do not need to. Apple does need to take a look at this, they should be able to prevent Zoom from doing this.
• If you Windows users thought that only Macs were vulnerable to Zooms half-arsed approach to security, then you should be aware that the Zoom Windows client is vulnerable to UNC path injection.

I would love to go into the many issues with Zoom in more detail, but since I do not have time today, I think I'll leave you a list of other articles I have been reading on Zoom.

These are in no particular order ...

• Jonathan Leitschuh - Zoom Zero Day: 4+ Million Webcams & maybe an RCE? Just get them to visit your website!
• John Gruber - Regarding Zoom
• BBC News - Zoom is in everyone's living room - how safe is it?
• Engadget - There's another macOS update to fix Zoom security exploits
• Wired - Zoom Will Fix the Flaw That Let Hackers Hijack Webcams
• Doc Searls - Zoom needs to clean up its privacy act
• Business Insider - 'Alcohol is soooo good': Trolls are breaking into AA meetings held on Zoom video calls and harassing recovering alcoholics
• twitter.com/DanAmodio - zoomAutenticationTool will run whatever script you give it
• Hacker News - Zoom truncates passwords to 32 chars
• 9to5mac.com - Ex-NSA hacker finds new Zoom flaws to takeover Macs again, including webcam, mic, and root access
• objective-see.com - The 'S' in Zoom, Stands for Security
• theintercept.com - Zoom meetings aren’t end-to-end encrypted, despite misleading marketing
• An example of Boris Johnson using Zoom with the cabinet
• twitter.com/c1truz_ - Hacky installation scripts