Putting cables (electrical, coax, fibre – whatever) on existing poles, or even putting up new poles to carry a new service, seems like such an obviously cheaper and easier way to go. But is it really? Let’s look at some of the reasons why underground is almost always better than overhead – even though overhead looks cheaper.
Recently, I was directed to an article in the Sydney Morning Herald of 2 May 2013, touting in uncritical fashion the supposed benefits of VDSL – Vectoring DSL.
Let me take issue…
Just read this article on the ABC website, about securing your enterprise against malware. They gave great advice – “detect and block at the perimeter and inside the network”, “assess and protect endpoints”, “analyse threats through context”, “eradicate malware and prevent reinfection”, “remediate attacks with retrospective security” and “be sure to implement integrated rules on the perimeter security gateway”. But one important bit of advice was missing.
On a mailing list that I frequent, someone recently posted a set of statements which gave me pause for thought. I thought about the millions (billions?) of personal details stored in private collections of personal details, also known as contact lists. And I thought about how little care we take about how we treat that information.
I will summarise the statements as follows:
Which led me wonder what details the writer might have collected about his numerous contacts. Name, address, phone, email, birthday…? And without asking all these people whether it’s OK with them, the writer is wanting and planning to dump their details (automatically if possible) into multiple privacy-hostile service providers’ databases. For the sake of convenience.
Given the state of privacy laws in Australia and their near-total lack of meaningful enforcement, no-one can stop this person doing whatever they like with whatever data they collect.
But if you are like this person, and think that my personal details are yours to do as you please with, and specifically yours to share with large commercial third parties whose avowed intention is to collect all the data in the Universe, I do have a request.
Please – forget me. Before you make me unforgettable.
I was trying to make a copy of a bootable USB stick. In spite of both sticks (source and destination) being allegedly the same size, the destination stick was in fact slightly smaller than the source stick, so a simple blockwise copy using dd did not work – “no space left on device”.
Someone on a mailing list asked recently “What’s the best practice for IPv6 addressing?” The question got me thinking, and I thought I’d share some useful guidelines.
So you have an application. It was written (as far as you know) without IPv6 in mind, and now it has to work with IPv6. How hard is that going to be? Well, it depends on the application. Most of the following is not really Java specific (but some of it is).
I’ve just spent an hour struggling with (I thought) IPv6 on Windows 7. IPv6 is enabled by default on Windows 7. I was seeing autoconfigured addresses on the ethernet interface, but there was no IPv6 connectivity beyond that. Looking at it with Wireshark, I could see neighbor discovery packets leaving, but answer came there none. No firewall rules were blocking ICMPv6; in desperation I turned the firewalls OFF on both source and destination test machines – still nothing. What the…?
IPv6 destination address selection is the process of deciding which IPv6 address a connection should be made to. This is the flip side of IPv6 source address selection, which has been the subject of several earlier articles (start here). Destination address selection is described in the same RFC as source address selection – RFC 6724 (which obsoletes RFC 3484).
If you read the doco (like “man gai.conf”) you would be forgiven for thinking that the contents of /etc/gai.conf controlled source and destination address selection in IPv6. You would be wrong.