There are systems and processes that we run on a 24x7 basis on equipment that was built when NT was current, for which XP has been the final upgrade. The company is unlikely to replace a 25 million dollar machine so that its controllers can be front-ended with Windows 7 or anything of the kind, given that it still does half a million dollars worth of work for us a day. Some of the specialized software to drive the components and controllers is still 16 bit, and nothing beyond XP supports it. I've heard all the well meaning advice, and the folks that betray their lack of experience and understanding by declaring that we should have made these changes ages ago - the costs of designing new controllers for systems that were designed and built in the late 80's is prohibitive and the expertise and understanding of the processes necessary to replicate is for the most part lost to the ravages of time. Maintaining the most stable alternative is the only choice many companies have. I don't see the exceptions as to running desktop configurations like the one described as essential- there are current alternatives and it is only personal preference that keep people using systems like that; the desktop environment has progressed and there is little reason to stay behind. The control and process environment however, will probably keep XP running well into the 30's just because there are no solid, universally supported alternatives to running 16 bit systems for essential processes.

As consumers, we pay for internet access to get the content we are interested in, not the content the ISP can make the most money delivering. If AT&T wants the content providers which are what drives consumers to subscribe to pay for the bandwidth it takes to provide than content, then AT&T should not be charging the consumer for delivering the content at the same time. It is quite simple, the telecom providers want to be paid twice for delivering the content; by the consumer and by the provider. It is purely greed and until the regulatory agencies are given the power to correct it, it will get worse for both provider and consumer.

Backers that provide fund for the production of the film expect to receive a share of the return on the investment in the form of a share of the earnings of the film. There should be a class action suit to establish the kickstarter contributors as essentially the same class of backers, and a share equivalent to the portion represented by the kickstarter funding should be divided among the participants, Make Warner Brothers treat the people that funded the film through kickstarter the same as any other investor.

Buy a basic PC chassis and a MB that has multiple SATA ports, with a raid bios. Add 5 3T or 4T drives in a simple raid5 config, and use a dedupe program and some basic backup / sync software to run an incremental backup. It will take a while to initially get it all into the baseline, but a job will pull whatever has changed (at the file level, but that isn't too bad for this) and any decent dedupe application should get the files to under 50% and leave plenty of space for the offline de-dupe to work. Given the deals on drives you could run this pretty reasonably for under $600 or so with a little careful shopping. Set up the machine bios with a wake time and power down time to minimize power demand, or just leave it running. Not free, but compared to the cost of replaying 20T of files, music and pictures, a lot better than a poke in the eye with a sharp stick.

The 80's called - they want their web technology back.

I have seen a massive number of comments from well meaning people telling the OP that giving the toddler a phone is wrong. Please consider this advice to ignore those well meaning but short sighted comments. We gave our daughter her first cell phone at age 8, 20 years ago. She had specific requirements: it was to be in her locker during the day at school, or if she forgot, she was to leave it with the teacher for the class and get it back at the end of class. It was to be on, but set to silent/vibrate only to avoid disturbing others. It was a voice phone- the smartphones are a bit more of a distraction. Calls at that time were always charged against airtime minutes, and 1 hour on the phone was as much as one horseback riding lesson an easy choice for her to make. If she went to an event and we would have to pick her up, she was to have the phone with her and answer it immediately when we called to see where she was so we could find her. She had our cell phone numbers programmed into it, and if she went on a school trip, the chaperone's number and anyone else "in charge" were added. Her mom traveled 3 - 4 days a week for work and I ran IT for a 7 x 24 company which sometimes meant staying late or being heavily in demand, and she knew she could always reach me, and always be reached. The "right" parenting is what works for you, not what everyone else tells you is the way to do it. You will need to manage the use of the phone the same as we did, and set the rules appropriate to their use, the same as we set rules appropriate for our time and our daughter. Interspersed with the "don't do it" comments have been a few with decent suggestions on what to use, and I would agree - Lock in a contacts list and allow calls from the list. Teach them how to call you and make it easy to find with an icon/smartkey on the screen. Lock down the "play store" or Itunes store to parental consent, and teach the child never to accept a call from someone they do not know, or that is not in their contacts list, with a picture on the contact so they can identify the caller. Handle the phone and set their understanding of how it is to be used with the same concern you do any of the other parenting tasks, and tailor it to the child's needs and your plan for what they will be allowed to do with it.

HP Laptops with the fingerprint scanner, and kronos timeclocks with similar scanners can be defeated with two pieces of play-doh and 2 minutes careful molding. Make a finger impression in the first piece, fill it with the second, and allow it to dry a but before lifting the newly molded "finger". I am sure a better material for making the "finger" could easily be found, but this works well enough to defeat the biometrics on both of these devices so far.

I can forsee a state where older drivers who can no longer safely drive themselves can maintain a portion of their independence by using these to be able to get around without requiring someone else to taxi them from place to place. Simple destinations such as family member's homes, stores, doctor and medical offices, and other common destinations could be pre-programmed into the vehicle's memory, with a simple menu to select a destination. A "specify your destination" feature could be used for those who retain the ability to decide where they wish to go, and either locked out or require an authoritative OK when the elder gets beyond being certain of being able to specify new destinations safely. Combine this with a search feature that would allow stores, restaurants and other destinations to provide their coordinates to the driverless car network, and it would go a long way to making the elder but still active population safer while still more independent.

There's a fundamental perception that Qualcomm is missing; Multicore processors are not x times as good at doing a task, unless that task can be threaded to multiple components, but most business and consumer computing devices at this point ar not doing one thing at a time. As long as the OS has the capability of dropping a task into a memory space and assigning that to a processor, the muti-core processors will always offer a benefit to the user with more than one thing at a time going on (which includes the OS itself, and all of the myriad of drivers, checkers, updaters and such we have running in the background while we do the "oe thing" on our desktop.

Considering that I built an altair 88 from a kit, a kim1 from the board and sourcing parts myself (anyone rememeber hamilton-avnet?) and both repaired and modified TRS-80 (article on putting the full 48k of RAM in the keyboard with a circuit I developed published in 80 Micro back then) I find the idea that stuff that was developed LONG after I started with these as antique tobe humorous as well, but since the definition as far as vehicles for "classic" is 20 years and "antique" is 25, it fits :)

Migration is not always a simple matter when you are talking multi-million dollar installations which would require months of redesign, wiring, programming and timing to replace the PLC hardware with newer versions. I am talking equipment with multiple feeder stations on a manufacturing chain that include as many as 500 conditions and timings based on conditions both up and down the line each, which were purchased as much as 20 years ago for some of them. If you're interested in the actual devices, they are used to select and assemble multiple groups of pages to build catalogs, from as many as 32 different "pockets" based on criterion for each individual catalog at a rate of about 250 books per minute (different page groups, covers, wraps and inserts for different versions of the catalog, as many as 20 or 30 different combinations in a single run. The techs need to be able to access and adjust embedded plcs to keep the lines running accurately,

some of the plcs I need to support are no longer supported by the allen-bradley software, and some never were, In some cases, the software the techs are using is the very last version of whatever was developed to manage the plcs, and we're talking 3-4 million dollar systems that would require months of redesign, wiring and tuning to handle a newer PLC so the options are limited.

I use toughbooks now, and the used ones and refurbs are possible, but they have specific issues with XP SP3 and serial hardware, and difficulty with some direct hardware access to the serial port. Some of this controller management software dates back to dos/win95 and is at best touchy on the toughbooks. Used hardware is often a grab-bag and has a lot of variations in port availability too.

Tools have their limits in some things, and what they do, they may do well but hit the wall on some specifics, and their code may not be optimized for performance. That being said, hand coding is VERY limited, for several reasons. First, self taught people tend to have gaps in the knowledge and practices of the areas they have studied, no matter how talented. There will be things that any hand-coder will try to do a specific way that is familiar to them, where better, if more complex, options exist through the tools. The most important thing about hand-coding is this: it is virtually unsustainable over time. I know that is a very broad statement, and will raise the hackles of some excellent and talented coders, but anyone that has done any long term support will tell you than out of the hands of the original coder, hand-coded systems fail in one important area - no one else can go in and fix them when they break, and even the original programmer will find it difficult to support a site he hasn't touched in a year or more. If he wants to hand code, teach him to comment everything, period. External documentation, commented code, clear process identification and threading are as essential to the success of a hand coded site as the code itself, but most coders will admit that this is something they do as an afterthought at best, and they consider a nuisance and a distraction from the project. The simple truth is this; if you cannot explain it on paper well enough that someone with no access to you or your thought processes can see what you have done and make the necessary changes or repairs, what you have built is, in the long run, a throwaway. Talent means a lot in creating a good site, with or without the tools. Tools provide a level of "documentation by process" that enables someone using that tool to look at a site and understand its internal processes. Very few hand coders, in my 30+ years of experience, can or do provide the same level of sustainability and the problem of the essential application or process that the developer has long since moved on from is an axiom in the IT world. It is not that tools or hand coding are either one better than the other in the end; the result is much more than the page view, and that needs to be addressed, either by using the tool, or doing the documentation the hard way. Without that, great work becomes great problems over time.