On their site you could choose what currenty to pay in - the conversion to Australian $ added around 40% to the price. What stung was at the time the Australian dollar was stronger than the US$, so in theory the price should have dropped.

I actually phoned up and queried why - the lady at the other end told me that it was due to the exchange rates when they set the price and not the rate at that point in time. However that would only have been the case if they had set the price several years previously.

Now they have fixed the problem by not letting you chose the currency - they force you to pay their inflated Australian prices, even though all you are buying is a license key.

It sure makes those US hosted proxy services look attractive.

If you pay in US$, they want $189.00

Currently AU$1.00 buys US$1.03 according to the TV, making that approximately AU$183.00

Click on the pull down option on th VMware store to convert the pricing to AU$, it becomes AU$277.00 - a markup of AU$94.00 or approximately 50%.

I've rung and asked them why the difference - and got some bulls**t about there being annual price adjustments based on the current currency conversion. The only problem is the last time that AU$ was low enough for that was back in the 1980's.

US companies regularly rip off Australians.

This is a product that they will be able to order from right out of the catalog, and at better prices than people are talking about here.

There are certainly many cheaper products out there (my favorite right now is the 'ET-STM32 Stamp') but if I was looking to build up an embedded computing curriculum for a school, these gadgets are well worth a look.

Are they collecting data on what apps their users use ?

Are they sending it back to Motorola for analysis ?

Does it mention anything about this in the customer documentation?

10 million cipher-text objects with plaintext customer details is an interesting target for cryptoanalysis.

If you know the card details of some of the people whose cards you have encrypted copies on, you have both plaintext and ciphertext to work on. And to make it even better credit card numbers have a checksum algorithm built into the number, so you have a method of testing the resulting decrypts for validity.

Why do I think that someone is probably running some GPU assisted EC2 machines at Amazon on these now ?

The only 'secret' protecting those cards is how the numbers are encrypted.

Powned

It's main claim to fame was that you could take your existing CP/M code, and with a few changes make it run on their new product.

Of course all it did was suck programmers across to this new platform where people just stopped writing the old stuff.

Has someone reopened the old play book ? Hello, Bill - is that you back again :-)

Why would anyone think this is a viable idea for the open source community ?

Maybe if someone like AMD got behind it ?

Without a long term commitment from a reliable manufacturer to supply these at a competitive rate for 5+ years there is a large risk that people investing in designs using this chip will be left high and dry. They would be far better to look at some of the ARM derivatives where at least you are not locked into a boutique supplier. The only thing that could make this a useful idea would be the availability of FPGA chips at the same price point - not holding my breath there.

For a business it's a case of looking at upcoming purchases, and to either require that new purchases are capable of IPV6 out of the box, or otherwise have business units accept the lack of conformance and prepared to write the equipment off sooner.

Once vendors start seeing requests for IPV6 compatible equipment, they will either need to supply it, or watch business go to their competitors.

As far as 'board level governance goes', for the moment it's simply having a strategic plan that leads the organisation towards IPV6, an indicative date to aim for (say 5 years from now - little to fear now), and a statement that the detailed technical work needs to wait until there is enough technology and expertise on site to plan and implement the cutover. Unlike Y2K there's plenty of time to do this without too much shock or fear - but ample time to get infrastructure and skills.

Sonys electronic dice keeps coming up 4 :-)

The vendor who built this system should have used an encoded PIN to tie the SIM to the embedded system it was built into. That way the SIM on it's own is fairly useless without the rest of the electronics.

They also should have had a 'phone home' facility so that whoever is monitoring the system would have noticed when the systems were compromised.

Fitting tamper switches to the enclosure (door opened, removed from pole, etc would have been smart.

Checking the bills on the cards to see where they are calling, how much has been spent, etc would have been smart

That would of course require someone to be routinely monitoring the system (it's not like traffic lights are there to save lives is it) so that things like this are not a surprise.

This really sounds like a system built by the cheapest tenderer - not unusual for a government organisation.

I've purchased GSM SIM cards on plans with no ongoing costs - you only pay for the data transmitted.

If the devices are not reporting frequently, and only need to send short messages indicating faults or general device stats (eg a daily 'all is well' SMS) then the transmission costs are quite low.

Embedded GSM modems are not particularly expensive either. You can buy a SMT GSM module from Sparkfun for under $50, and they are even cheaper wholesale.

The other technologies all need the deployment of a complementary data network. Given that most modern cities have some form of cellular network that is maintained by someone else, cellular is very cost effective.

Isn't it possible that the thieves worked this out, and only targeted the lights with the antennas ?

Have someone perform a risk assessment on the system - and focus on the quantitative aspects (ie what the cost to the community will be if it fails). Make sure that the contract has compensatory and insurance options in excess of those amounts, so that it is in the vendors 'hip pocket' best interests to ensure it does not fail. And of course make sure that the contract has provisions for review, should the potential impacts change or the vendor changes company name, is bought out, etc :-) (yes - i've seen that happen)

You could also have someone do a thorough risk analysis of the system (google up the NIST SP800-30 document) as well as have them supply a complete inventory of hardware, software, and services they will be using to deliver the solution. Again, NIST have an online database where you can look up what vulnerabilities are known for some IT products.

Have the vendor perform a detailed risk analysis of the system - see what they think are problems, and what are not. Where you see gaps - ask them and see what color their faces turn.

Have a look around to see what failures or disasters you have seen in SCADA systems, refer those scenarios to the vendor, and ask them what technical measures they have taken to ensure that a similar act could not happen to them

You should also have your own people clarify and document their own roles and responsibilities with the system - don't assume that you have the resources on hand to manage your side of the situation responsibly - again a risk analysis will help out there.

And of course get it all in writing.