My new current model samsung washer lasted 2 years and couldn't be repaired for any cost because parts are on 'permanent backorder'.

We got one of their top of the line app-connected fancy front loaders ($1400) 2 years ago. The firmware is absolute crap, for example you can only use a 32 character WPA password (I had to set up another SSID, "Samsung Sucks", with a shorter password just for this thing). They value engineered the processor such that response on the touchscreen controls are laughably slow.

The connected features are 100% marketing fluff, you have to go to the machine and tell it to make a connection to your phone so you can see how long is left in the cycle (but of course you're standing there so you can just look at the machine at that point). As soon as you leave the app (or the phone goes to sleep) you then have to go back and re-authorize the connection on the front panel. 100% worthless as a feature.

The washing part did well until it broke with a cryptic error code that according to the service company means "main motor is toast". Samsung does not stock replacement parts (they are on "permanent backorder") so after 2 years we had to buy another washer. The factory authorized service tech told me there are no spare parts available because these can't be repaired reliably in the field even with the parts, something about how they are assembled in the factory is a one way process that is not reproducible in the field.

The matching dryer fails to boot every 2nd or 3rd time we turn it on so I'm guessing there will be a new one of those in our near term future as well.

Amazingly enough my review of this POS washer on their website was rejected as 'not meeting review guidlines' -- which meant not a 5 star review. That was really just done for a grin, I didn't expect a critical review to make it through their marketing dept interns.

tldr: Samsung sucks. A 2 year old machine is completely unrepairable and is now scrap metal due to lack of parts and value engineering, firmware is crap.

I don't really care if an online identity is provably linkable to a physical identity, just that its secure and when (for example) 'LadyBigMac' posts its trustable that its the same entity that posted with that identity (per service obviously) in the past. Having additional identity tie ins to help prevent identity theft seems good but shouldn't be required. You'll never know if something someone posted was posted under duress or not anyway, its as useful as security by obscurity when it comes to determining someone's motive/reasoning behind a given communication.

In a current embedded product that is mostly C++ based I'm working on I had the same issue. I wrote a command line interpreter that talks to a telnet client; it works fine, but it was getting painful writing ascii 'reports' for complex classes that were readable. Writing the output via html and letting the browser deal with layout (using nested tables for instance) is close to trivial and makes formatting almost a non task (a little CSS can even dress up an otherwise plain pages).

As to how to do the introspection, there is a library called BFD (part of gnu binutils) that understands how to plug through the debug symbol tables, and in a previous product we did use it for this sort of thing, but IMO its way too painful and not really intended for this sort of use. It ended up being a giant rathole, although we got what we wanted in the end (ability to do a formatted system dump on a saved raw system image using compiler metadata to find the interesting stuff and print it out nicely, think the old unix 'crash' command).

The current product has a few hundred classes that are worth looking at in a running system, I've used the convention that operator<<(std::ostream&, class) will serialize out the class ("programmer visible introspection?") in an easily parsable format, specifically TCL style lists of key/value pairs for each (interesting) field in the object. For aggregated objects (or optionally referenced objects) you output the name of the object in parent class then call operator<< on the child object (... elephants all the way down). Its relatively easy to write these serializers, example:

std::ostream&
SomeClass::put(std::ostream& s) const
{
s << "this " << this
<< " field1 " << field1_
<< " aggField2 {" << aggField2_
<< "} field3 {" << field3_
<< "} field4 {" << field4_
<< "} colids {";
util::printcollSpec<std::vector<jint>, util::PrintWsList, util::Direct>(s, *colids_);
... etc ...
return s;
}

Boost also has a serialization library that may automate some of this (its fairly new and I haven't looked into it yet).

If you have threads available (we do) and don't mind linking with the TCL library the tclhttpd server is a fairly comprehensive embedded web server that can run in its own thread (using blocking I/O and not getting in the way of any system wide epoll/event loop). TCL scripts are triggered by various urls (it also has an asp/jsp like thing which hasn't been useful in our environment), these TCL scripts suck the serialized version of the object to look at into a TCL associate array ("array set t [xyzStatus]") and then a small hunk of code generates the HTML from stuff in the array. For most classes I just use a short generic routine that makes a table from a TCL array (couple of lines), and understands about sublists, creating a sub-table when it detects an aggregated object. Putting all the generation of HTML in TCL script makes it pretty easy to whip up a page in short order.

There's a fair TCL library that deals with some of the arcana of form generation (which isn't that hard), package html; it has thin but barely adequate docs (if you don't mind reading the code sometimes). Posts are easy to deal with to change debug settings. You can push javascript that talks to the DOM out to the browser to get more dynamic and interactive displays ("AJAX").

On a prior project I had a go at doing this client/server as some have suggested, the overhead of writing RPC for the various classes was somewhat higher than the simple serialization stuff above. The main issue was that changes to displays require a redeployment of the client app on several platforms. While some random developer would be happy to stick some support code in his class and maybe write some TCL scripting to make a web page to talk to it, almost no one was willing to be the last one to have 'released' the client app with changes and no one wanted to keep updating their client app. It ended up being very good at a few popular displays/control screens and that was it. On that project we also did a curses version which was about as much work as the HTTP thing up to the point you had to start laying out the screens and making them look good; just like writing text reports that was a lot of layout/UI style drudge work that kept most people from adding support for their classes unless they *really* needed it. The UI guys were busy writing actual customer visible UI (revenue generating) so we couldn't use them to help with the technical RAS stuff.

If you can't run tclhttpd for whatever reason its not that hard to answer the interesting subset of HTTP requests in an event driven system (there are likely http parser libraries to help with that, I have not looked).

To summarize the ramble: having tried (over the last 3 embedded products) command line style (serial and telnet), client/server (over TCP), curses (serial and telnet), and http server (in C++ as described above and in java using jetty) the http server method seems to be the best so far in terms of ease of adding new displays, simple implementation of the framework, and maintaining all the code in 1 place. I think the weakness of this approach is it requires some fluency in a broad range of technologies (TCL C glue, TCL scripting, HTML, javascript, css) -- this has been the largest barrier to getting random developers to make displays when they want them (though its rare to run across someone these days who can't emit simple html markup).

Ask again in a couple of years and I might have a better answer :)