On the sixteenth of March 2014, the Sydney Morning Herald had an editorial calling for Government control of pornography on the Internet. You can read the editorial at the link below. This post is my response.
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.
Now for something completely different! Here in the country, some people have chooks. We have chooks (well, my daughter does) and she was stricken to see that a decent chook-feeder was going to cost her 30-odd dollars of her hard-earned pocket money. So we went home and made one ourselves! It only took about fifteen minutes.
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…
In this article about privacy, civil liberties and the way the “war on terror” has become a war on all of us, John Pilger asks “What are you going to do about it?”
Well, here’s my question, John: What can I do about it?
Continue reading
A discussion started on a network operators list I frequent, about a case where an apparently innocent party, Melbourne Free University, had had its website blocked. Aside from a terse “yes it’s blocked” from one provider concerned, no further information was forthcoming. Here’s one report about it. Continue reading
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.
After much time thinking about it, I have kicked off a new business venture – Into6. The new venture specialises in IPv6 – training, analysis, consultancy, technical support, you name it. If you are interested in IPv6, do check out the Into6 website, because that is where I will be doing all my future blogging about IPv6. Over time I will move or copy the IPv6-related blog entries from this site to the Into6 site, too.
As part of starting up Into6, I’ve also set up a Twitter account (@intosix) and you are cordially invited to become a follower by clicking on the button below 🙂 The Facebook page is pretty much a placeholder for now.
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”.