The list above is not exhaustive but it's enough to illustrate the point. All of the equipment built by GE uses a multitude of sensors and Industrial Control Systems and GE Digital is invested in building PaaS solutions on open source software to help bring data from those sensors into the cloud and run analytics that improve reduce cost and improve efficiency. In fact, GE has been doing this for many years the only thing that's changed is that now there is an organization, GE Digital, dedicated to standardizing the hardware, firmware, software, and security of these systems. You don't get more IoT than that.
The problem is one of perception, because we take things like power generation, water purification, air travel, healthcare for granted. We don't realize that there's a massive amount of software, data, and analytics needed to run these things and tremendous room for efficiency gains with the right software. We're so obsessed with smart phones, smart watches, fitness devices, and companies building consumer products we forget the foundation on which these things rely on.
As far as the security in the IoT space is concerned, GE made an investment to buy Wurldtech (http://techcrunch.com/2014/05/09/ge-buys-wurldtech-to-beef-up-internet-of-things-industrial-infrastructure-security), a company that specializes in securing ICS. They build systems designed to both passively, and actively mitigate against threats. In addition to that, it's probably worth noting that GE has several divisions dedicated to both IT security and cyber security research. Finally, I can state that GE is contributing to open source projects that provide software security capabilities (e.g. authentication services) by both writing code and performing ongoing penetration testing. Also keep in mind that many of these systems are deployed on private clouds and some which service critical infrastructure are not directly connected to the internet (think on-site cloud computing).
I've been reading Slashdot for a while and I know there's a sort of cynical anti-establishment attitude around here. Honestly, it's what drew me to this forum in the first place. It's funny though, being on the other side, seeing how much vitriol gets thrown around that's terribly ill-informed. It definitely gives me some perspective.
It's disheartening to see people with entrenched positions lash out the minute something new threatens their illusory bubble of safety. The reactions are visceral yet I wonder how many have actually tried pair programming?
It's really this simple: if you think peer review has value then pair programming is simply just-in-time peer review. Furthermore, by virtue of the fact that it is just-in-time, it has one big advantage over traditional code review: the reviewer is immediately invested in the process. In other words, they can't relegate their code review to the background.
Here's how it works: two people sit at a pairing station which has a monitor, keyboard, and mouse for each developer connected to the same workstation. The programmers take turns "at the wheel". The programmer that is not "driving" is reading the other programmers code, catching typos before they turn into hours of debugging, acting as a sounding board for design decisions, providing a second opinion or consensus when making tough decisions. Pairs rotate at intervals.
Yes, your team will write less code overall, but 1) the quality and the maintainability of the code improves significantly 2) the confidence in the code increases 3) the team benefits from shared knowledge.
Pair programming is not about how you feel it's about better teamwork. Yeah, a senior developer will feel that pairing with a junior developer slows them down, but those justifications are selfish. If I see a programmer making a mistake or tediously performing the same repetitive task shouldn't I teach them a better way?
Leave your ego at the door and accept that 1) you don't know everything; therefore, you will learn new things working with others 2) sharing your knowledge takes time but is a force multiplier 3) sometimes trying something different can have a positive effect 4) working in a closet with your headphones blasting "Dual Core" without team interaction may be heaven for you but its likely detrimental to others.
Grow up people.
"The eleventh commandment was `Thou Shalt Compute' or `Thou Shalt Not Compute' -- I forget which." -- Epigrams in Programming, ACM SIGPLAN Sept. 1982