Everything you have said is true, so perhaps the warehouse example was a bad one, but not entirely. There are cases where the inventory is stable, or the task never changes, such as controlling a milling machine or something similar. These are the cases I was mainly referring to, or to point to a larger market, small businesses. They are the worlds worst about putting off upgrades as is because what they have is "Good Enough"

It is not an imposable task to design a device that can be stable in the long run for these tasks, and an infrastructure to maintain it for the long term. Perhaps it's time to start SBM (Small Business Machines).

This actually shows that in a way *we* in the IT field have the wrong idea. At least some of the time.

Computers *are* just equipment to the end users in say a warehousing operation. Why are we not designing systems with this in mind?

In the warehousing example much used above if you avoid the latest gee whiz features and give them exactly what is needed there is no reason why the VAX of yesteryear cannot keep doing it's job other than it can't be maintained anymore. That's a failing on IT's part though, why was the machine not designed with a 20 year lifecycle? It can be done, there is no reason it can't. Yes it will be slow at the end of it's lifecycle but it will still do it's job perfectly well. Data? We have open and well documented means of storing data now, take your pick of method, so store the data in an open standards format and do the magic inside the program.

I can see where companies would not like building and selling to the maket like this, they are killing future revenues, but speciality machine manufactures have been existing like this forever, so why aren't we doing this?

It's rare on home devices, but if it's an option it could slow him down more.

I am not aware of what attacks are out there for it though, I may have to look into that later.

I may have to put up a test copy then. I suspect there are few real world test cases being run, but an RC is far enough along
for me to justify spending some cycles at work on it. There are more samba 3 + LDAP setups out there than people may realise
and all of them stand to benefit from Samba 4.

I also commented above, Samba 4 *is* intended to be a full AD server implementation. It is using the documents Microsoft was forced to release
as a result of an EU lawsuit.

How complete an implementation it ends up being and how well it works will have to wait to be seen once it exits Alpha status and gets a few
beta releases under it's belt.

It's a whole new samba in the end.

Samba 4 *is* intended to be a full AD implementation. Currently it has a built in LDAP and Kerberos server set in the same daemon. That is a problem
for some, like myself, that use Samba 3 + LDAP for shared auth. When complete is *should* be a fairly complete implementation of the AD specs, all
of them. I have no idea how long this will take, or just how complete it is, but those are the design goals. All of this is a result of Microsoft releasing the
full spec due to the European Union lawsuit.

Samba 4 is in it's Alpha release stage and is not recommended for production. That said it's a remains to be seen thing if it will be.
It also depends a great deal on how and what you use AD for. For simple authentication you can use samba 3 + LDAP for that now.
For programs that require AD not so much with either.

Next time on MythBusters, were cannons really less accurate then rifled artillery? We put it to test... Oops!!!

Even in HAN deployments the utility doesn't poll that frequently, the in home display can, the utility? once a day just as they do on their non-HAN meters. No sane utility company would even *want* that much data, the volume after a month would be staggering.

I finally got to the article, and reporting in every 2 seconds? That's way, way more frequently then most meters are read, once a day is the norm, once
and hour is the extreme. In fact the only devices I have seen that can read the meters I work with that frequently are in home display units, certainly not
the utilities putting the meters out there, they simply don't want that volume of data.

I can negate the need for the tinfoil hat with a small amount of authority, my current company builds smart meters, mostly for the US market and the software
to run many of them (not naming names but if you really want to know look up cell based meters, should find us) and the simple fact is that with that type
of meter the power profile lacks the resolution for such snooping, the most often I have seen the usage profile read is once an hour, and that (probably) is
not enough info to do what they are doing. (H-online is down for me as I write this, I will try again later to read it) In the type of meter's I see such detailed
information is just that, too detailed. A 2mb a month data plan is the typical provisioning and the meters generally use half that in a given month.

Note wireless mesh meters may be another story, at least in some deployments, however the only such network like that I have any direct experience with
uses a cell based relay station to phone home with and again doesn't seem to send enough data for such evil observations to be made.

End result? You could do it, but real life smart meter systems have one giant consideration that stops this from working, cost effectiveness, power companies
don't want to pay for data, that just want to know how much of your money to take.