If you're based in the UK and interested in research software, you might want to look into 'The UK Community of Research Software Engineers'[1] and The Software Sustainability Institute[2]. From what I've seen, the latter in particular are exploring pragmatic ways to make software engineering more compatible with the expectations (e.g. citations) of academic employers.
I'm looking at something similar at the moment, but in agricultural areas where line-of-sight is inhibited only by foliage and terrain. For my purpose, it's OK to collect an SD card every so often, but I've toyed with the idea of an ESP8266 and a directional antenna to e.g. a mobile broadband router, probably again with an antenna upgrade.
Earlier today, I found [1] which - amongst other things which you might be interested in - calls out a venture [2] to establish a network of 'citizen scientist' type flood sensors across the UK. Their scheme looks to be a network of radio-to-Internet gateways which support a number of independently-deployed sensor nodes.
I am a hydrographer in the NT working out in very remote areas- Phone reception is rarely possible for such monitoring sites. Currently we use satellite Comms. to relay water data home, but this is very expensive and prone to failure.
I'm wondering if you, or anyone else, has some ideas on long range communication strategies for large areas (NT is 1.4 million km2).
The area we are required to cover generally means sites are chosen based on accessibility rather than operational importance — it would be great if we could expand the network with low maintenance loggers capable of communicating long distances.
Which operator are you using? We've found L-band to be very reliable and does not suffer from any of the attenuation issues found in Ku. And heavy spreading on the return path provides for an even more resilient link.
Disclosure: We'll be offering an L-band satellite gateway for IoT this summer.
We currently use Iridium. On Ku band I beleive. I'll look further into this and see what our options are for L-band.
Outernet looks like a great project. How small of a satellite can be used to achieve the connection? Any more info/documentation on the L-band gateway?
It's heavily dependent on river/climate conditions. During the dry most loggers will only need to be polled once every hour. However, during the buildup and wet, the stations would ideally be sending back every ~5 minutes.
The dataplan on some look very reasonable, like $1/MB/Month, but the hardware itself seems cost prohibitive.
I mean, the Dash costs $59 or the Electron at $39 just for the board to send over 2G? You can get a disposable cellphone for < $10 complete with LCD screen and that worm eating game!
I guess I'll just need to wait another year or two until economies of scale kicks in...
The published version has headings: Latitude, Latin name, Modern name and date of Roman foundation, Axis, Amplitude at solstice, Published research. Still no map, though.
Constraints on template types are useful outside of metaprogramming proper. For example, the standard library already specifies classes of iterators dependent on e.g. the direction(s) in which they may be advanced.
n.b. it's a double-pointer. The /called/ code probably allocates a dns_name_t itself, updating the /callee's/ pointer. If the callee's pointer isn't NULL, there's a chance overwriting it will cause a memory leak (as the caller may no longer have a reference to whatever it was pointing to). The comment acknowledges that it's perhaps unnecessarily strict.
Hrm, it was a worthwhile check imho. Without the check, the memory leak you've indicated would have allowed the same packet to cause an out-of-memory DOS.
I got a free copy of the lot back around 2003, but when I looked recently they've officially switched to printing on demand (priced at ~cost) via Lulu. I first got them for hobbyist operating system development - their residual utility there should remain high for a while. Plus, bookshelf cred!
From the paper[1], it sounds like the same linear motion with the film wrapping around to the top:
> The sphere is dipped with
> its north pole pointing downward. The maximum error on the
> northern hemisphere is within 2mm. However, near its south pole
> the error is much larger (about 5mm). This is because after the
> water surface passes the sphere’s equator, the film gets stretched
> largely, and near the south pole the relative angle between the
> water surface and the object surface approaches to 180◦, leading
> to an ill-posed boundary condition for our simulation (recall
> Equation (1), when θ ≈ 180◦).
You can see the potential for a similar wraparound even on e.g. the mask dips.
I have this kicking around from some experiments a month or two ago:
sudo apt-get update
sudo apt-get install build-essential linux-image-extra-virtual
sudo reboot
echo options nouveau modeset=0 | sudo tee -a /etc/modprobe.d/nouveau-kms.conf
cat > /etc/modprobe.d/blacklist-nouveau.conf
blacklist nouveau
blacklist lbm-nouveau
options nouveau modeset=0
alias nouveau off
alias lbm-nouveau off
<Ctrl+D>
sudo update-initramfs -u
sudo reboot
sudo apt-get install linux-headers-$(uname -r)
wget http://uk.download.nvidia.com/XFree86/Linux-x86_64/346.35/NVIDIA-Linux-x86_64-346.35.run
chmod +x NVIDIA-Linux-x86_64-346.35.run
sudo ./NVIDIA-Linux-x86_64-346.35.run
nvidia-smi -q | less
This is obviously not production-ready, and is heavily cribbed from online (I couldn't quickly re-find where) but is good enough if you just want to play.
