Until last week, if you’d asked me what the longest-lasting computer I’d owned was, I would have said the laptop I had at university (lasted six years). It turns out I was wrong. It’s this:
This has been my always-on home “server” since about 2012, and it’s been pretty solid. It must have eaten an SD card or two, but that’s par for the course.
I finally pensioned it off because the CPU isn’t up to running rdiff-backup (one doesn’t think of such things as CPU-intensive, but to a computer which is roughly equivalent to a Pentium II, it certainly is). So it’s finally been replaced by a Pi 4 – let’s see if that lasts to a full decade, though the difference in running temperature is pretty significant.
If you have a less-technical relative and you’d like to sort out video chat capabilities for them, then this is for you.
You will need:
A spare smartphone. It doesn’t have to be a powerhouse – in my case, I dug a Nexus 4 that goes back about five years out of my desk; you can get good-enough Android phones for this purpose for £100-ish these days, or even a bit less.
The target friend or relative’s mobile phone number and WiFi details (network name and password)
Step 1 is to factory reset the phone and configure it up. I tend to just make a new Google account in cases like this, on behalf of my target user (assuming you’re setting up an old Android device – you’re on your own with old iPhones). Naturally, that Google account should be set to forward all e-mails to the target user’s real e-mail address, and make sure you lock it down with two factor auth.
Step 2, install WhatsApp. When prompted for a phone number, give it the target user’s mobile phone number. You’ll now need them to tell you the six digit code it will text to them. Once you have this you can activate WhatsApp on their mobile number. Add the contacts you want them to be able to speak to (presumably including yourself!) and do a bit of testing (be clear that you’re messaging on behalf of the target and will be shipping the device to them shortly).
Once you’ve activated WhatsApp with the code, they can use it on this phone forever, and they don’t need to move their SIM card in if they don’t want to. In my case the user already has an old Nokia that only needs charging once a fortnight, and they’re happy to stick with that for calls and SMS.
Step 3, secure the phone. Put an unlock PIN on it which you can tell the target user on the phone (or otherwise out of band), and tell the phone to encrypt itself (you had to do that explicitly in older versions of Android – remember?)
Step 4, optionally, install any other apps you might be glad for the target user to have (e.g.: Microsoft Teams, Signal Messenger, …)
Step 5 is optional, but preferred. If the target user won’t be putting a SIM card in the device, then it will need to be joined to their WiFi network. To save talking them through this over the phone (and, indeed, talking them through finding out what their WiFi details are), you need to:
Find out their WiFi details. In my case, I had a Windows laptop in front of me which had been connected to their WiFi in the past. To fish out the credentials, run ‘netsh wlan show profiles’ from the command prompt, followed by ‘netsh wlan show profile name=”Their Network Name” key=clear’ to print out the network password
Now you need to configure the phone with these details. I’m not sure if there is a way to add a network to Android without connecting to it – I went for the maximum reassurance option of connecting to it.
But wait, the target user and their network are 150 miles away – how did I do that, I hear you ask? Well, I temporarily updated the guest WiFi network on my own router to have the same network name and password as the target. Messy, but gives the greatest reassurance that this will work out of the box when I ship the phone.
Actually, if you really want all the gory details, I added an extra guest network to my Mikrotik router with the target details – but many routers won’t support that option.
Step 6, get the phone to the target user. I’ve arranged for mine to be picked up by a courier and overnighted to the target user. Assuming the courier doesn’t lose it, I’ll update this post and confirm if it all worked.
Oddly enough, that’s a question I’ve been asked a few times in the past few weeks.
There are many choices for this kind of thing. Zoom has a few privacy concerns attached (even if the Prime Minister doesn’t accidentally tweet your meeting ID). Microsoft Teams is pretty decent if you happen to know someone with an account via work (and an employer who doesn’t mind it being used for non-work stuff). HouseParty sucks up battery life like it’s going out of fashion.
My answer, at least for various church things, has been Jitsi Meet – it appears to Just Work and is really simple, since all people have to do is follow the link to the meeting you set up (and enter the password if you set one). It also provides a UK phone number for users to dial in if they don’t have a computer with a camera on it.
Or, “why I’m not giving Dropbox money, and you might not want to either”.
Particularly since going paperless, I’ve been pondering where to store my digital files. The days of keeping everything on a PC under the desk in the corner are long over – I have multiple different devices including my smartphone, and I want at least some subset of my working files on all of them. Then there’s backup, sharing selectively with others, encryption, …
I’ve used Dropbox for quite a few years now – it has widespread adoption and various voluntary groups I’m part of use it as a handy way to share files. One might not be thrilled by placing data in the hands of a US mega-corporation, but at least it gives some hope of central management, rather than e-mailing stuff around which is doomed to remain on people’s machines long after they have no further need for it.
However, understandably, Dropbox want people to move from their free tier to paying them money. And if you’re on the free tier, every folder which other people share with you counts towards your quota – not just the quota of the person sharing it.
Before giving in and paying them their pound of flesh, though, I did some maths on the back of an envelope:
Even factoring in the cost of buying the hardware, and the electricity to run it, hosting some Network Attached Storage (NAS) at home looks like an option worth exploring – as long as the kit lasts more than five years, it should be cheaper than Dropbox. And there’s something to be said for having private and personal data hosted at home on hardware under my control.
Look out for part 2 of this series, in which I’ll explain why I went for the Synology and my initial findings from setting it up.
Note to my biographer and any future historians researching my life: this post was written on the night Prime Minister Boris Johnson announced a UK-wide lockdown to limit the spread of COVID-19. At the time, I was holed up in my flat in Oxfordshire and working from home.
I’ve been running these for a week now. They work, and they’re very helpful to those like me who live alone.
With everyone in the UK who possibly can working from home, now seems like a good time to share what wisdom I can on bandwidth. You might well be looking at your home internet and wondering if it’s up to snuff, after the first couple of days working from home – did your video/audio conferences break up? Did screen sharing work?
As it happens, I use an ISP who provide me some handy graphs, so here’s the past 24 hours on my VDSL / Fibre To the Cabinet link at home:
What can we deduce from this (apart from “David watches too much TV”)? The first thing to note is that the graph is on a non-linear scale – 1mbps (megabit per second) is the same distance from zero as 10mbps is from 1, and as 100mbps is from 10.
The black line near the top denotes the maximum theoretical speed of my line, which is close to 80mbps – about the best you can do on this type of service. But do I need it? Or could I be managing quite well with the 11mbps ADSL I used to have?
The green line denotes data I’m downloading, and the red denotes data I’m uploading (i.e. sending somewhere else as opposed to fetching).
Well, here are some notes – the plural of anecdote is not data, but these might be of use to you:
Non-work stuff (Netflix and Amazon) peaks at more (17mbps) than work stuff, which never exceeded 10mbps
As you might expect, video and audio conferencing requires meaningful upload bandwidth as well as download – the MS Teams calls I was on from 0930 to 1045 and 1530 to 1630 use an equal(ish) amount in both directions. This kinda makes sense as I was sending video and audio outbound as well as receiving it.
Audio-only conferences, even with screen sharing, are less bandwidth-hungry – see for example 1330 to 1450. Presumably there would have been more outbound bandwidth if I’d been the one sharing my screen, rather than viewing someone else’s.
As well as having a lower average and peak throughput in each direction, the work stuff clocked up a total of less than 2GB sent and 4GB received. Contrast that with 14GB downloaded on Tuesday (when I was at work all day) by Netflix alone.
Bottom line, if your broadband can cope with streaming video without interruptions and stuttering, it can probably cope very well with a normal working day. The only time my FTTC service is actually coming into its own is streaming 4k video – everything else, especially the business applications, is extremely well optimized to use as little bandwidth as possible .
However, it’s worth noting that my ADSL had just under 1mbps of upstream capacity (the A stands for asymmetric) – so some of those audio/video conferences would have really struggled there. Having 20mbps upstream on FTTC makes a big difference for that sort of application.
I must admit the results were something of a surprise to me – the 18-way MS Teams call peaking at 5mbps in particular – but if you think that every 5mbps at the user end adds up to that much needed at Microsoft’s end, you can see why they’re keen to keep it efficient.
Of course, it helps to have an ISP which works hard to avoid any congestion at their end, giving your traffic the clearest possible path to the wider internet. Thanks to AAISP – not the cheapest, but the best – I can be confident that the handful of audio/video issues today were “the other end” and not me – the graph shows a complete lack of packet loss and a nice low latency throughout.
This one goes back a few years, but still has something to teach us all…
Back when I was church treasurer, the desktop software we used was fine, but clunky. I grafted multi-user capabilities onto the single-user package by checking the software into SVN and launching it from a script which grabbed a lock before updating and launching. Then at the end, it would commit with a progress bar.
This all seemed a bit hateful (and yet is still in use and working well, nine years later), so I looked around for something modern. The ideal solution would be web-based, so it could be used by multiple people from different systems, and not tied to a single OS (i.e. Windows).
Paxton Charities Accounting is “the other one” in this nice market, and we tried moving to it. Their website notes that both their desktop software and their “online” version have exactly the same features, with seamless migration between them – no small achievement, and one I was professionally curious about…
It only became apparent to me once we’d signed up for it how they achieve this – and the stench of genius almost made my eyes water.
Their “online version” is the desktop software, but you launch it over remote desktop from a Windows server at their end!
I’m still torn over whether this is very clever or very nasty – it certainly killed my hopes of being able to use this stuff on Linux* or mobile clients, though in the end it was the rather clunky 1990s feel to the software, a significant step backwards from what we already had, that made us decide not to go with Paxton. The robust quarterly costs were noticeable too (presumably quite a lot of it going to Microsoft for the terminal server per-client licensing).
*Yes, there are remote desktop clients for Linux, but I never found one which coped with the SSL used by this particular application.
This one is mostly thanks to Paul Ockenden’s PC Pro column. The magazine has survived the changing IT landscape well and a subscription is good value for money, IMO.
As mentioned a couple of months back, one annoyance about my new smart watch is Samsung Pay, which Monzo do not support. Given their client base, and given also that such “legacy” banks as Nationwide and the Co-Op (neither famed for their IT) have managed to support it, a conspiracy theorist would wonder if Monzo are deliberately taking a stand against fragmentation of payment services. But it’s probably a good old-fashioned lack of developers.
Either way, an “aggregator card” like Curve – which supports Samsung Pay et al – is a neat way round this. It simply “forwards” transactions to the underlying card, which can be any MasterCard or Visa (switch between them in the Curve app). As well as fixing lack of support for Samsung Pay on Monzo, this could also be useful to anyone with a “work” credit/purchasing card, since none of the banks seem in any hurry to add even basic Google Pay support to these.
Naturally, having another layer involved in the transaction should make you a bit nervous in cases of large purchases or anything where a refund might need to be requested – especially since your finance team at work might not be too keen on finding out you’re using a third party card “in front” of your company issue one.
However, the solution to this seems simple – use Curve for the small(er) stuff when out and about, e.g. travel and subsistence. It’s things like paying for the tube which is so much easier with phone/watch than digging the right card out of your pocket – and for the big ticket items, you’re probably sitting at your desk with plenty of time to fish out the actual card and use it directly.
Downsides? Well, the items appearing on the underlying card statement are all prefixed with “CRV*” – you do still get the original merchant details after that, but it makes it a bit harder to follow and makes a slight hash of logos and stats on Monzo.
Also, activating the Curve card on Google Pay and Samsung Pay requires confirmation text messages, which failed to arrive for me until I phoned Curve and they fixed something at their end.
All that sorted though, I should finally be able to use Google Pay when travelling for work, and use my watch to pay via Monzo in places which don’t support American Express.
In a final postscript to my new internet … now that my landline number is on VoIP, it diverts straight to my mobile. But that leaves me with a couple of analogue handsets which no longer do anything.
(Actually, they play an amusing message saying “this is a broadband-only line, please don’t disconnect it”).
For myself, I’d probably bin them and leave it at that, but there are a couple of reasons to want to keep them working on VoIP – first, most “old fashioned” phone handsets are much easier to hold next to your face for an hour that a smartphone which gets annoyingly warm and is quite heavy.
Secondly, when relatives stay with me (the same relatives who still use landlines to call me), they expect the old phone handsets to work.
I had a Zoom 5801 in my electronics box (goes all the way back to 2011), but although I got it working against the A&A VOIP service for incoming calls, outgoing calls got a busy tone. In the end I got fed up of poking its hateful configuration interface, threw it away, and ordered a Grandstream HT801 from Amazon.
So, have things got better in ten years? Well, sort of. On the downside, the Grandstream needs rebooting after some settings changes and takes forever to come back; on the upside, after a certain amount of prodding, I have it working both ways and it even supports IPv6! I’ve got it set to IPv6 only, which means no NAT to get in the way of VOIP traffic, and it works well.
I have it connected to the analogue phone extension ring in my flat, and it manages to ring line-powered handsets as well as a cordless phone. The AAISP support site links to the UK/BT settings; it’s a boring amount of copy/paste to fill them in, but once done, it has the right ring and dial tones, and even manages to display the caller ID.
Of course, as you can see in the picture, they clearly should have printed “Grandstream” on it the other way up to make it wall mount with the ports on the bottom.
P.S.: The automatic firmware update URL is for an IPv4 only hostname. I changed to s3.dualstack.eu-west-1.amazonaws.com/gs-firmware – no idea whether it will work yet, but seems better than a setting which I know won’t!
P.P.S.: There is no encryption on AAISP’s VoIP service at the time of writing, so you don’t want to use it away from trusted networks – VPN up first. Last time I asked I got told that calls on the PSTN aren’t encrypted anyway, which is true as far as it goes but not the leg of the call I’m most worried about. May be time to ask again. To be fair, they are not alone in this decision – most other VoIP providers are the same.
Update, mid-March – first incoming call Just Worked. Quality exactly the same as before, but of course the other party was still on a copper landline.