June 2009

Opening a can of worms

Telemarketers are a pet hate of mine. I’ve made my point about them before, so I won’t repeat it.

Tonight we had a different class of telemarketing. That is… a company that you do have dealings with, contacting you to advertise another service. In this instance, it was Telstra offering us a discounted internet service. We currently have our telephone services (a landline and two mobiles) with them.

My disagreement with this sort of marketing is one of principle. We pay you to provide us a service, we do not pay you to pay telemarketers to harass us via the aforementioned service. I’ve also had SMS messages on my phone from Telstra, thankfully this is rare.

Now… they’ve unwittingly called us thinking we’re the typical non-technical household. Okay, fine, they weren’t to know that. However, one would think the telemarketers would know something about the product they’re selling. I initially answered the phone, and of course, when the woman at the other end asked for my father (who holds the account) I naturally transferred her.

A few points:

  • She did not seem to understand the limitations of what was being sold… yes, Cable internet is theoretically faster than ADSL… especially 512/128kbps ADSL (which is what we have). But cable is a shared medium, ADSL isn’t.
  • My father immediately asked about getting a static IP address. She had no clue what this was. Tsk tsk tsk… Internetworking 101 people.

The plan offered was only discounted (half price) for 12 months, after which, the price would double, resulting in a monthly rate only marginally less than that offered by our current ISP, who we’ve had a service with since 1996 and have been quite happy with.

Should an ISP be thinking of offering their services… first and foremost, don’t contact us with your offers… if we were looking to change, we’ll contact you. However, since Telstra have come to us, I guess that gives us the right to dictate what we expect… Our expectations:

  • Static IP is a must. (At last check, Telstra only offer this on ADSL for an extra $10/month… not sure if this has changed)
  • IPv6 native is highly preferred, but a tunnel is livable (currently we have one via AARNet)
  • We must be able to run our own server with any arbitrary service we choose including but not limited to:
    • HTTP and HTTPS
    • DNS
    • SMTP (both directions)
    • IMAP/IMAPS
    • NTP
    • XMPP
    • SSH
    • OpenVPN tunnels
    • IRC
    • VoIP services (including Skype, EchoLink and Ekiga… not ruling out D-Star, IRLP or other systems in future either)
  • We must be permitted to maintain, reconfigure and replace any and all network infrastructure components within our property boundary at our discretion… This includes choice of hardware and software!
  • In the event of a problem, I expect to talk to a competent tech support person who at least understands basic networking principles such as the TCP/IP model (or the OSI model which it is frequently compared to)
  • Related to the above, when contacting tech support, I expect that any findings I report are taken on board, and that appropriate troubleshooting techniques are used. I did not go to university studying IT and EE for 6.5 years for nothing!

Some of this is due to frustrations I’ve had with ISPs, particularly Telstra when troubleshooting issues on others’ behalf, and hitting this exact problem of being treated like a dummy because the other end is only reading a script. iTel haven’t given us any issue thus far… it’d be nice if they offered native IPv6, but that’s about my only nit I have with them… they’ve provided a very reliable service and haven’t gotten in our way. Whenever there has been a problem, it has been quickly identified and rectified. Thus, we have no reason to change… finance alone is not going to cut it.

Specific to Telstra… it’d be nice if they fixed the broken DNS server that fails to resolve yi.org domains. (If you have trouble viewing my site directly, but can see my post on Planet Gentoo… try changing your DNS server settings over to an alternate one such as OpenDNS, then please contact your ISP about it.)

The telemarketer tonight had to end the call prematurely while she found out from her employer whether static IP addresses were possible with the plan they were about to try and sell us. She’s apparently going to call back tomorrow evening. All I can say is watch out for low-flying aircraft.

Extending the RPN calculator: HanoiCalc

One thing that I’ve noticed is how inefficient most calculator apps on the desktop computer are. Not just from a computational point of view, but from a user interface point of view.

It seems the vast majority of them are more of an exercise in UI element layout than in producing a practical computation application. This got me thinking about my needs, as an engineering student (soon to be full fledged graduate engineer, if everything goes to plan this month).

Python, Octave (or Matlab) and the calculator applet in KDE’s Kicker, are probably the most useful as far as practical calculators in my experience. There are probably others… these mostly use the keyboard for input and have a minimal interface. I find KDE’s kicker applet works well for quick calculations, with Python or Octave taking up the slack for more complex stuff. I’ve experimented with x48… the HP48 is indeed an awesome piece of kit… but why should an app limit itself to the confines of a real-world device?

I did some thinking about this… and coding. RPN calculators are conceptually very easy. All the values are placed on a stack, operations pop off operands from this stack, then place the result back on the stack. They’re also very easy to code, especially in a high-level language like Perl. I set to work coding up a RPN calculator.

RPN calculators in my experience take a bit of getting used to, but often are more convenient in the end, than a regular calculator. The limitation though is one can easily get themselves tied in knots with the stack… you find that you didn’t push the elements on in the right order, and so you find yourself popping it all off to have another go.

Thus, with my app, I decided to experiment with a multi-stack concept. In addition, sometimes it’s nice to copy a calculation made into a temporary space where it won’t get buried in the stack… so each stack has an associative array for the storage of variables.

RPNCalc is a first stab at this calculator concept. It has a few limitations, but works reasonably well. Its biggest limitation is complex math, or rather, the lack of it. I thought I had done well until I encountered a problem that needed it.

The code is also a monolithic mess… so I’ve began re-writing it in an effort to produce a workable project for public release. HanoiCalc is the current working title for this new calculator app. At the moment, it’s little more than two Perl modules, one which provides the stack, the other providing all the operations… but it should serve as a basis for a workable RPN calculator. It uses complex maths by default (most calculations will just use the real part, ignoring the imaginary component).

I’ve held off implementing scripting… which could be done providing more power… but that’s beyond the scope of what I want to achieve at this point. I’ve tossed the code I’ve got presently into a git repository for now… you can either browse it via gitweb or clone git://git.longlandclan.yi.org/hanoicalc.git for yourself to play with.

I plan to add a user interface over the coming week. The API is simple enough, so GUI interfaces (even ones that pretend to be real calculators) are possible.