I think that the technology to solve is there, and has been there for ages. The problem is that it's not very cheap unless you'd manufacture in the millions. A prototype will run you a couple thousand dollars just for the A/D converters...
A cable box needs one wideband tuner and an SDR that can demodulate all the channels at once. There's obviously no need to do video decoding (decompression), just buffering of some subset of channels (say most often recently used). One QAM channel brings about 34.5 Mbit/s. A modern ASIC should have no problem easily dealing with demodulating and buffering twenty such channels (700 Mbit/s) when presented with a wideband IF output. The buffering only needs 90 Mbytes/s for 20 channels. That's not much if you ask me. Again: there's no need for 20 physical tuners. There's just one tuner that doesn't do much besides amplifying and prefiltering the signal, and then feeding it into an very fast A/D. The output of that A/D goes into the ASIC and there the individual QAM channels are demodulated and dumped to external RAM. When you switch channels, it's trivial to scan the buffered stream for a given channel to find the most recent keyframe and immediately feed it to the MPEG decoder, so that you get video output with minimal latency.
For implementation reasons, and due to economics, the cable spectrum may need to be split up in a couple subbands (say 4), and those would be individually digitized, so you end up with "4 tuners", but those tuners are somewhat simpler than a regular tuner: their heterodynes all run at fixed frequencies. The IF can be likely directly digitized for all of the subbands.
It is dangerous to depend on C#, so we need to discourage its use.
Whoosh. You're utterly confused. C# is no biggie, to put it mildly. It's but one of the languages for which an implementation exists that happens to target the CLR and the.net framework. It's the platform that's the big deal, not a single language.
It's not dangerous to depend on C#, if anything it may be dangerous to depend on CLR or on the.net framework.
Free C# implementations do not permit users to run C# programs on free platforms. A free C# implementation is a C#-to-bytecode compiler. To be functional, it needs the framework and a runtime.
Writing programs in C# by itself is not bad. You could arrange to have a C# compiler that targets JVM, with proper library support. The latter is where the devil sits since it needs to implement quite a bit of CLR functionality, but it can be done. Mainsoft offers a system like that; no I'm not related to them in any way (not even as a user).
I think that Apple may need time to work all the wrinkles out of whatever authoring setup they'll provide for BDs in OS X. This isn't something that you can do overnight. The hangup could be something as simple as poor support from drive vendors, demonstrated poor firmware quality, etc. Of course Apple has the momentum to pretty much get what they want. At the end of the day it's still engineering time, and in many cases you can't really throw more engineers at the problem just as throwing more mothers at pregnancy won't get your baby born any faster.
That's some BS. My residual tax rate has never been so low back in Europe as it is here in the U.S. After central/western European taxation, even Massachusets seems like a tax haven.
I'd think that the break-in was to a running system. In most cases that implies that the decryption key is in RAM. In plenty of cases it's even better, you can easily access the API that will give you all the data after decryption. Say if there's a process running that has an "authenticated" connection to the database, and holds a decryption key, you just attach a debugger to it, do a dump, then use the info from the dump to do something useful. You could perhaps authenticate a rogue process to siphon the data. Or you could monitor the original process to siphon the data as it accesses it, and somehow coerce that process into sequentially accessing all records. And so on, there's plenty of possibilities there. Even hardware encryption is of little help if there's a running process that you can control -- and if you're a superuser, you can control pretty much everything, and it's not merely theoretical.
I have had data breaches happen to my personal data multiple times at a big-ten school in the U.S., *and* at a big-ten school's medical center. There was always a press release, then a delay of a couple of days, then an personalized email with link & pin to start a year's worth of service with some credit protection service provider.
I wonder if some of those attacks aren't covertly orchestrated by the very credit protection companies. Here's how it typically goes:
1. security breach at company X 2. company X realizes they are in deep shit 3. company X's legal team informs them that it'd "help" to preemptively protect the customers 4. company X buys credit protection services for a year for all of its customers in a deal with company C 5. company X issues a press release disclosing the breach 6. company X's customers are soon individually emailed with the disclosure, worded in a worry-free tone, with a link and a password/PIN needed to start service with company C
Company C has plenty all the motive needed to instigate the whole thing.
What is utterly retarded is that they had to cancel my card and could not tell me which of the Virtual Credit Cards had been misused. If I'd known which card, I'd have known which online store had been leaked my info. CitiBank wouldn't tell me, and further they don't even know how their system works because they had to cancel my physical card number (again, which should have never been used).
You do know that you can list transactions done with each virtual credit card in the very flash applet you mention?
Anyway, I think that the fraudulent charges did not come from any of your virtual credit cards. In all likelihood it was your physical credit card's number that got used. It doesn't imply that someone had access to your card, merely that someone guessed the number. The way the numbers are doled out by the banks, it's no wonder fraudsters can have a good clue as to what number ranges are likely to contain mostly active account.
You mean like a virtual credit card number, available -- for example -- from citi in at least the U.S. market? That's precisely what it is: a credit card number generated on the fly, with an expiration date and spending limit that you select, that locks to the first merchant that will charge it. The latter is because it's generally impossible for a 3rd party to know how the merchant will identify themselves to the credit card processor.
When you're getting a PC-based PLC you're not getting "a base kit". You're getting, by my guesstimate, a software package that cost about $100M to develop over the years. That's where the difference is. I don't care about a C/C++ IDE, that's a commodity these days. When all you get is a bare Windows or Linux development platform, there's no way to have it talk to industrial hardware out of the box, and that's where the buck stops. You need a software development platform that can actually get your code to talk to hardware over various protocols and interfaces. Heck, you need various APIs just to have your code not end up an unmaintainable mess (read some of Miro Samek's articles to know why "the way it's typically done" is not the right way).
I've looked around and none of that functionality is available for Linux as an integrated, out-of-the-box package that I can just take and use. Moreover, you have to interoperate with available software that you don't really want to buy a separate piece of hardware to run on -- that's all the stuff that comes from third parties and runs on nothing but Windows. And that's where the real value of Windows is: it lets you leverage plenty of 3rd party software that doesn't exist for anything but Windows.
I am familiar with what is being done with embedded Linux, and I do use it in my projects, but only for HMI and as long as the platform the HMI runs on doesn't have to control any hardware but "merely" talk to other parts of the system via a network connection. For a cost-effective machine, you'll often run the HMI and control platform on the same PC, there's nothing wrong with that. But if you want to do so, it has to be Windows. Or else you'd have to potentially implement $10k+ worth of ISO/IEC standards -- I'm not talking about software development cost, just about how much it would cost to get the PDFs with the standards that you have to develop for. Probably another $1k would be spent on books that tech you how to navigate the standards. As for the development expense -- got a well-maintained jet somewhere and a buyer for it? Because that's the cash you'd need.
Now there are some commercial libraries that implement various standard industrial protocols, but there's no way you'd get anywhere near the functionality of even TwinCAT I/O for the same price. TwinCAT I/O is just the input/output part of the PLC -- it doesn't run any code, but gives you APIs to read and write to the process image. The process image is the memory that is automagically exchanged with various hardware of your machine (I/Os and drives). To get this costs about $200. That's a fucking bargain if you'd ask me -- it gives you access to pretty much every industrial bus out there (+ cost of the interface cards, if needed). For about $1.5k more you get the PLC functionality, so that you can run code that processes the process image in the real time. That's if you want to deploy on your own PC. If you get Beckhoff's hardware, you get a "discount" (read: the PLC comes pretty much for free).
What I'm saying here is that for a typical industrial application, a hardware platform with a C/C++/.net dev environment is pretty much useless if it's just by itself. It's other software that makes it useful, and -- as an end user or OEM -- you must get this software (the soft PLC) from a 3rd party, you're not going to reimplement it because it'd take ages and it's already been done and is available relatively cheap. At that point, if your supplier *and* the industry has standardized on Windows, there's no point going against that.
Of course there are machine control applications where you can roll-your-own, but you either pay to redo a lot of the stuff that's been done and is available for reuse in a soft-PLC, or you get software that has a lot of noob mistakes built-in. Once you're experienced enough to properly implement industrial-grade software, you realize that it costs so much to do properly that everything that you can reuse is almost always a financial win.
The OS licensing fees are noise when it comes to machine building, so I wouldn't worry about that. What counts is the functionality that you get with your OS, and there Windows is pretty much a winner. Beckhoff has leveraged the fact that the PC platform generally runs on Redmond-originating OSes. They were targeting the PC platform, and the mainstream OS was part of the platform, and pretty much stays so. The fact that they embraced the whole platform, not just its hardware, is the primary contributor to their success.
The fact that you can get a bog-standard, boring office PC and within a couple of minutes start prototyping a PLC program that can control a bunch of servo drives with shorter than 1ms update cycles, communicating via a bog-standard Intel network card, is not to be dismissed. Maybe you should try it one day for yourself.
I don't even know where to begin. If I buy a Sony TV, even if I were to built it in, I don't know, into a yacht (I'm an OEM, not end user), you think I'll be provided by Sony with any sort of an SDK? Or if I buy some music streaming box, will anyone give me an SDK for it? Haven't you been reading about the Roku brouhaha?
When I get a PC-based PLC I'm not getting any sort of a base platform in the sense of a SoC -- I'm getting something that has pretty much everything but my value added already on it. It's something that can talk to thousands (I kid you not) different pieces of hardware from a hundred vendors or so, communicating on up to a dozen incompatible network technologies, out-of-the-box. That is very different from what you get with a SoC + generic SDK.
As for Linux GUI: don't get me started about Athena. Of course I know about those legacy technologies. And truth be told, I'd much rather program to a bare winapi or to VCL from the times of Delphi 1 than to, say, XT or any other low-level C APIs from the X11 heyday. If you expect that machine builders would be keen on embracing Athena, OpenMotif or any such thing: they'd laugh you out of the room. It's too much work for too little benefit. It'd be almost easier to code the UI from scratch, given that machines have rather fixed-format UI where you don't often need movable windows and similar desktop commodities.
I am fully aware of various uses of Linux. Yet in the PLC, automation and even non-massive (forget LHC for a moment) research data acquisition/processing world, the only widely deployed non-proprietary OS that runs on ARM and ia32 platforms comes from Redmond. There's no way for a company like Beckhoff (or even National Instruments for that matter) to just dump everything and switch everyone to Linux -- it makes no economic sense for them. They and their customers have made huge investments in the Windows-based technology. And I just can't see what difference would it make if the underlying platform was Linux -- given that, at the end of the day, a kernel is a kernel -- assuming that somehow, by magic, Mono would reach parity with current.Net runtime.
Guess what, people don't develop on a bare kernel, and even high-level toolkits like Qt may not be enough. The customers would face big steps when they'd have to interoperate with any software not bundled with the PLC: if you buy a piece of a machine that requires custom software for maintenance/setup, that software runs (if poorly) on Windows and there the story ends. It may be a sad state of affairs, but there's nothing wrong with Beckhoff sticking with what's common in their market, and -- given their financial situation -- one can hardly disagree with them. Future-prospects-wise they are in a much better shape than Nokia.
Nobody cares that a streaming box or a Sony TV in my living room runs linux. It's a closed-box system. The end users and OEMs don't touch it and don't develop for it. At most they have access to a factory setup menu to tweak things. With PLCs, either your end user or the OEM needs to develop on your platform. And, due to legacy requirements, you need to support way more hardware than just a network card. There are various bus interface cards (for sercos II, profibus, canopen, etc), various HMI elements on the HMI itself (lcd displays, panels, buttons), etc.
The issue is that the industry is pretty much Windows centric. Nobody gets fired over buying MS and all that jazz -- this is especially true in the automation industry, where all the tools run on Windows (you're lucky if they run well) and nothing else. A typical "small" machine builder may get a control panel IPC from Beckhoff, run TwinCAT as the PLC platform, and do their own HMI in Visual Basic or.net. Whatever you say about it, it's only very recently that you have any sort of a semi-decent native, eat-my-own-dogfood development environment that runs on Linux: namely Qt creator. The only other alternative I can think of is to develop for JVM using Eclipse and use SWT for the GUI, but this comes with its own bag of problems.
I do of course agree that it'd be very nice if Beckhoff maintained their own realtime extension of the linux kernel, but they'd either have to keep it a binary blob and face deployment woes (compiled kernel-specific shims, separate distribution since it's non GPL-compliant) or, if they'd open-source it, they'd lose a lot of competitive advantage. Everyone and their dog is looking for a simple and cheap way to reliably develop and run IEC-61131 on standard PC hardware. There would be red ink flowing on their balance sheet if someone suddenly had an open-source replacement for TwinCAT (including support for all of the PC-attached hardware like bus interface cards etc).
The deal is that for Beckhoff, like for many other PC vendors, Windows is a way to sell their hardware (IPCs, I/O, drives, etc). I don't see MS taking over PC manufacturers, yet that's precisely what you imply here. It'd make just as much sense for MS to take over Beckhoff.
Now it's true that Beckhoff does sell their TwinCAT software, but if you get it with their IPC you get it for a 90% discount over a license for a "random" PC that you happen to have. So I don't think that for Beckhoff their own software sales are a huge part of the business. The software is a key enabler, but financially there's not all that much there directly. When you buy a low-end IPC from Beckhoff, about 10% of its price would ordinarily be TwinCAT, and likely no more than about 2.5% the Windows XP or CE OEM license. It's significantly less for higher-end IPCs (say 4% total). If MS wanted to get more money out of this market, they could simply increase the license fee they charge for their OEM licenses, and they have not much headroom there either. There's only so much that this market will bear.
Sigh. IPCs themselves are a big part of Beckhoff's business, and with few and between exceptions every single one they sell has a copy of Windows installed on it. MS could terminate OEM licensing agreements if they wanted to cut ties.
Pretty much their entire PLC business hinges on TwinCAT, and that's 100% dependent on Windows. If MS wanted to cut the ties or somehow curtail their access to the Windows platform, Beckhoff would be bankrupt in short order. Of course Beckhoff is no Nokia size wise -- with a USD 0.5E9 turnaround, about 1% of that of Nokia's.
Yet it's the same kind of dependence that Nokia will have with MS: a make-or-break type of a deal. If MS wanted to sink Nokia or Beckhoff, they could do so quite easily.
It's not foolishness. Everybody who does it otherwise (using linux, other realtime OSes, custom hardware) shows over and over that Beckhoff did the right thing. They are leveraging the virtually infinite OS R&D budget of Microsoft, and similarly huge R&D budgets of PC platform designers (CPU and chipset makers).
If you buy almost any other PLC platform, you're constrained by the hardware offered by the vendor. It used to be 8051 derivatives, and some still are offered like that, others went the DSP or ARM route. Yet, if you want a system that can talk to literally tens of thousands of I/O points and still offer stupidly fast cycle times, you just get a high-end PC, slap TwinCAT on it, and off you go. You don't even have to worry about partitioning the system. Due to the way Beckhoff designed their realtime Ethernet-based communication bus (EtherCAT), you can trivially have full redundancy at the network and PLC level. If you have a machine where all you need is a PLC and an operator panel, the cost proposition of going with a bog-standard OS that anyone can develop an HMI app for, then adding a software component to turn it into a PLC, cannot be beat.
As for MS "wanting" into that market: remember that a PLC still has to talk to the I/O, and that's where Beckhoff is also a leader. If MS released their own PLC software platform even today, they'd be at the mercy of everyone else as far as I/O goes. Beckhoff is vertically integrated in that respect: they offer their own IPCs, their own PLC platform, their own I/O that's based on standards and interfaces with almost every other legacy industrial bus out there, their own servo drives and actuators, and they are constantly expanding. Vertical integration has worked very well for them for the same reason it works very well for SpaceX. MS has a huge barrier to entry to become a vertically integrated PLC vendor, and it'd need to become one to really compete in this business. It's not like Boeing or Grumman can magically outdo SpaceX: in fact, they can't, because they lack integration.
Um, Beckhoff is a gold microsoft partner, and they are completely dependent on Microsoft technology: with leverage comes dependence and even vulnerability.
Again, it's all in how you play your cards. Beckhoff has bet big time on the PC platform and the Microsoft OS technology as a key component to that, and they came out on the top. Nokia is making pretty much an identical bet. If they come out on the bottom, I'd tend to think it's their own doing. Of course Elop at the helm makes things somewhat shaky: Beckhoff is a privately owned company, and I think their success is mainly because they owe nothing to nobody. I think that Trolltech's success was due to the same reason (private ownership), as soon as it became part of a publicly traded company things got somewhat uncertain.
I think it's all in how you play your cards. I know of one company that came out extremely well by innovating on MS platforms. It's all in the value you provide. Namely Beckhoff Automation. I have nothing to do with them, just a happy user. It's perhaps an unknown name in the software development world, but they are nevertheless top-notch innovators in the automation business. Their main claim to fame is in deciding about 2 decades ago that industrial controllers and PLCs must be built on the PC platform to stay competitive. So, while mostly everyone else was thinking there was value in doing stuff on custom hardware that was outdated pretty much the day it was released, they chose to go with a PC. These days they offer a line of 100% in-house designed Industrial PCs (IPC) -- and I mean they design their own motherboards, control the BIOS, assemble the darn things locally and not in China, etc. Their PLC software platform, called TwinCAT, runs side-by-side with bog-standard Windows and Windows CE, and offers hard-realtime performance (think of a 62.5us input-processing-output cycle on contemporary hardware). They ship their hardware with XP Embedded or CE preinstalled.
It's an interesting experience, to say the least, when you simply install TwinCAT (a practically unlimited trial is available -- try it out!) on a bog-standard clunker Dell with Windows XP and you can easily run a 500us PLC cycle, just like that.
Their newest push is to standardize their development environment. TwinCAT 2, the current shipping version, has one of those me-too IDEs for IEC 61131-3 programming languages. For TwinCAT 3 (entering a closed beta AFAIK), they went ahead with basing it on the Vistual Studio shell, and in addition to 61131-3 languages you can run C and C++ code in the realtime environment. They have pretty much leveraged the hell out of MS technology and they now ride the gravy train. I can't help but think that they must be doing it right, and everyone else who got burned by MS just didn't have a clue to begin with.
Maybe one has to admit that sometimes the reality is such that there's no way to get evidence. The presumption that one has to be, unconditionally, able to obtain evidence no matter what is silly. Sorry, civil liberties sometimes imply that some crimes have to go unpunished. It's the price of a free society. Nothing wrong with that.
Slashdot Mirror
I think that the technology to solve is there, and has been there for ages. The problem is that it's not very cheap unless you'd manufacture in the millions. A prototype will run you a couple thousand dollars just for the A/D converters...
A cable box needs one wideband tuner and an SDR that can demodulate all the channels at once. There's obviously no need to do video decoding (decompression), just buffering of some subset of channels (say most often recently used). One QAM channel brings about 34.5 Mbit/s. A modern ASIC should have no problem easily dealing with demodulating and buffering twenty such channels (700 Mbit/s) when presented with a wideband IF output. The buffering only needs 90 Mbytes/s for 20 channels. That's not much if you ask me. Again: there's no need for 20 physical tuners. There's just one tuner that doesn't do much besides amplifying and prefiltering the signal, and then feeding it into an very fast A/D. The output of that A/D goes into the ASIC and there the individual QAM channels are demodulated and dumped to external RAM. When you switch channels, it's trivial to scan the buffered stream for a given channel to find the most recent keyframe and immediately feed it to the MPEG decoder, so that you get video output with minimal latency.
For implementation reasons, and due to economics, the cable spectrum may need to be split up in a couple subbands (say 4), and those would be individually digitized, so you end up with "4 tuners", but those tuners are somewhat simpler than a regular tuner: their heterodynes all run at fixed frequencies. The IF can be likely directly digitized for all of the subbands.
It is dangerous to depend on C#, so we need to discourage its use.
Whoosh. You're utterly confused. C# is no biggie, to put it mildly. It's but one of the languages for which an implementation exists that happens to target the CLR and the .net framework. It's the platform that's the big deal, not a single language.
It's not dangerous to depend on C#, if anything it may be dangerous to depend on CLR or on the .net framework.
Free C# implementations do not permit users to run C# programs on free platforms. A free C# implementation is a C#-to-bytecode compiler. To be functional, it needs the framework and a runtime.
Writing programs in C# by itself is not bad. You could arrange to have a C# compiler that targets JVM, with proper library support. The latter is where the devil sits since it needs to implement quite a bit of CLR functionality, but it can be done. Mainsoft offers a system like that; no I'm not related to them in any way (not even as a user).
I think that Apple may need time to work all the wrinkles out of whatever authoring setup they'll provide for BDs in OS X. This isn't something that you can do overnight. The hangup could be something as simple as poor support from drive vendors, demonstrated poor firmware quality, etc. Of course Apple has the momentum to pretty much get what they want. At the end of the day it's still engineering time, and in many cases you can't really throw more engineers at the problem just as throwing more mothers at pregnancy won't get your baby born any faster.
That's some BS. My residual tax rate has never been so low back in Europe as it is here in the U.S. After central/western European taxation, even Massachusets seems like a tax haven.
What a waste of QNX :( It is an otherwise very good and lean hard-realtime OS.
I'd think that the break-in was to a running system. In most cases that implies that the decryption key is in RAM. In plenty of cases it's even better, you can easily access the API that will give you all the data after decryption. Say if there's a process running that has an "authenticated" connection to the database, and holds a decryption key, you just attach a debugger to it, do a dump, then use the info from the dump to do something useful. You could perhaps authenticate a rogue process to siphon the data. Or you could monitor the original process to siphon the data as it accesses it, and somehow coerce that process into sequentially accessing all records. And so on, there's plenty of possibilities there. Even hardware encryption is of little help if there's a running process that you can control -- and if you're a superuser, you can control pretty much everything, and it's not merely theoretical.
I have had data breaches happen to my personal data multiple times at a big-ten school in the U.S., *and* at a big-ten school's medical center. There was always a press release, then a delay of a couple of days, then an personalized email with link & pin to start a year's worth of service with some credit protection service provider.
I wonder if some of those attacks aren't covertly orchestrated by the very credit protection companies. Here's how it typically goes:
1. security breach at company X
2. company X realizes they are in deep shit
3. company X's legal team informs them that it'd "help" to preemptively protect the customers
4. company X buys credit protection services for a year for all of its customers in a deal with company C
5. company X issues a press release disclosing the breach
6. company X's customers are soon individually emailed with the disclosure, worded in a worry-free tone, with a link and a password/PIN needed to start service with company C
Company C has plenty all the motive needed to instigate the whole thing.
What is utterly retarded is that they had to cancel my card and could not tell me which of the Virtual Credit Cards had been misused. If I'd known which card, I'd have known which online store had been leaked my info. CitiBank wouldn't tell me, and further they don't even know how their system works because they had to cancel my physical card number (again, which should have never been used).
You do know that you can list transactions done with each virtual credit card in the very flash applet you mention?
Anyway, I think that the fraudulent charges did not come from any of your virtual credit cards. In all likelihood it was your physical credit card's number that got used. It doesn't imply that someone had access to your card, merely that someone guessed the number. The way the numbers are doled out by the banks, it's no wonder fraudsters can have a good clue as to what number ranges are likely to contain mostly active account.
You mean like a virtual credit card number, available -- for example -- from citi in at least the U.S. market? That's precisely what it is: a credit card number generated on the fly, with an expiration date and spending limit that you select, that locks to the first merchant that will charge it. The latter is because it's generally impossible for a 3rd party to know how the merchant will identify themselves to the credit card processor.
When you're getting a PC-based PLC you're not getting "a base kit". You're getting, by my guesstimate, a software package that cost about $100M to develop over the years. That's where the difference is. I don't care about a C/C++ IDE, that's a commodity these days. When all you get is a bare Windows or Linux development platform, there's no way to have it talk to industrial hardware out of the box, and that's where the buck stops. You need a software development platform that can actually get your code to talk to hardware over various protocols and interfaces. Heck, you need various APIs just to have your code not end up an unmaintainable mess (read some of Miro Samek's articles to know why "the way it's typically done" is not the right way).
I've looked around and none of that functionality is available for Linux as an integrated, out-of-the-box package that I can just take and use. Moreover, you have to interoperate with available software that you don't really want to buy a separate piece of hardware to run on -- that's all the stuff that comes from third parties and runs on nothing but Windows. And that's where the real value of Windows is: it lets you leverage plenty of 3rd party software that doesn't exist for anything but Windows.
I am familiar with what is being done with embedded Linux, and I do use it in my projects, but only for HMI and as long as the platform the HMI runs on doesn't have to control any hardware but "merely" talk to other parts of the system via a network connection. For a cost-effective machine, you'll often run the HMI and control platform on the same PC, there's nothing wrong with that. But if you want to do so, it has to be Windows. Or else you'd have to potentially implement $10k+ worth of ISO/IEC standards -- I'm not talking about software development cost, just about how much it would cost to get the PDFs with the standards that you have to develop for. Probably another $1k would be spent on books that tech you how to navigate the standards. As for the development expense -- got a well-maintained jet somewhere and a buyer for it? Because that's the cash you'd need.
Now there are some commercial libraries that implement various standard industrial protocols, but there's no way you'd get anywhere near the functionality of even TwinCAT I/O for the same price. TwinCAT I/O is just the input/output part of the PLC -- it doesn't run any code, but gives you APIs to read and write to the process image. The process image is the memory that is automagically exchanged with various hardware of your machine (I/Os and drives). To get this costs about $200. That's a fucking bargain if you'd ask me -- it gives you access to pretty much every industrial bus out there (+ cost of the interface cards, if needed). For about $1.5k more you get the PLC functionality, so that you can run code that processes the process image in the real time. That's if you want to deploy on your own PC. If you get Beckhoff's hardware, you get a "discount" (read: the PLC comes pretty much for free).
What I'm saying here is that for a typical industrial application, a hardware platform with a C/C++/.net dev environment is pretty much useless if it's just by itself. It's other software that makes it useful, and -- as an end user or OEM -- you must get this software (the soft PLC) from a 3rd party, you're not going to reimplement it because it'd take ages and it's already been done and is available relatively cheap. At that point, if your supplier *and* the industry has standardized on Windows, there's no point going against that.
Of course there are machine control applications where you can roll-your-own, but you either pay to redo a lot of the stuff that's been done and is available for reuse in a soft-PLC, or you get software that has a lot of noob mistakes built-in. Once you're experienced enough to properly implement industrial-grade software, you realize that it costs so much to do properly that everything that you can reuse is almost always a financial win.
In the end, the cost of the
The OS licensing fees are noise when it comes to machine building, so I wouldn't worry about that. What counts is the functionality that you get with your OS, and there Windows is pretty much a winner. Beckhoff has leveraged the fact that the PC platform generally runs on Redmond-originating OSes. They were targeting the PC platform, and the mainstream OS was part of the platform, and pretty much stays so. The fact that they embraced the whole platform, not just its hardware, is the primary contributor to their success.
The fact that you can get a bog-standard, boring office PC and within a couple of minutes start prototyping a PLC program that can control a bunch of servo drives with shorter than 1ms update cycles, communicating via a bog-standard Intel network card, is not to be dismissed. Maybe you should try it one day for yourself.
I don't even know where to begin. If I buy a Sony TV, even if I were to built it in, I don't know, into a yacht (I'm an OEM, not end user), you think I'll be provided by Sony with any sort of an SDK? Or if I buy some music streaming box, will anyone give me an SDK for it? Haven't you been reading about the Roku brouhaha?
When I get a PC-based PLC I'm not getting any sort of a base platform in the sense of a SoC -- I'm getting something that has pretty much everything but my value added already on it. It's something that can talk to thousands (I kid you not) different pieces of hardware from a hundred vendors or so, communicating on up to a dozen incompatible network technologies, out-of-the-box. That is very different from what you get with a SoC + generic SDK.
As for Linux GUI: don't get me started about Athena. Of course I know about those legacy technologies. And truth be told, I'd much rather program to a bare winapi or to VCL from the times of Delphi 1 than to, say, XT or any other low-level C APIs from the X11 heyday. If you expect that machine builders would be keen on embracing Athena, OpenMotif or any such thing: they'd laugh you out of the room. It's too much work for too little benefit. It'd be almost easier to code the UI from scratch, given that machines have rather fixed-format UI where you don't often need movable windows and similar desktop commodities.
I am fully aware of various uses of Linux. Yet in the PLC, automation and even non-massive (forget LHC for a moment) research data acquisition/processing world, the only widely deployed non-proprietary OS that runs on ARM and ia32 platforms comes from Redmond. There's no way for a company like Beckhoff (or even National Instruments for that matter) to just dump everything and switch everyone to Linux -- it makes no economic sense for them. They and their customers have made huge investments in the Windows-based technology. And I just can't see what difference would it make if the underlying platform was Linux -- given that, at the end of the day, a kernel is a kernel -- assuming that somehow, by magic, Mono would reach parity with current .Net runtime.
Guess what, people don't develop on a bare kernel, and even high-level toolkits like Qt may not be enough. The customers would face big steps when they'd have to interoperate with any software not bundled with the PLC: if you buy a piece of a machine that requires custom software for maintenance/setup, that software runs (if poorly) on Windows and there the story ends. It may be a sad state of affairs, but there's nothing wrong with Beckhoff sticking with what's common in their market, and -- given their financial situation -- one can hardly disagree with them. Future-prospects-wise they are in a much better shape than Nokia.
Nobody cares that a streaming box or a Sony TV in my living room runs linux. It's a closed-box system. The end users and OEMs don't touch it and don't develop for it. At most they have access to a factory setup menu to tweak things. With PLCs, either your end user or the OEM needs to develop on your platform. And, due to legacy requirements, you need to support way more hardware than just a network card. There are various bus interface cards (for sercos II, profibus, canopen, etc), various HMI elements on the HMI itself (lcd displays, panels, buttons), etc.
The issue is that the industry is pretty much Windows centric. Nobody gets fired over buying MS and all that jazz -- this is especially true in the automation industry, where all the tools run on Windows (you're lucky if they run well) and nothing else. A typical "small" machine builder may get a control panel IPC from Beckhoff, run TwinCAT as the PLC platform, and do their own HMI in Visual Basic or .net. Whatever you say about it, it's only very recently that you have any sort of a semi-decent native, eat-my-own-dogfood development environment that runs on Linux: namely Qt creator. The only other alternative I can think of is to develop for JVM using Eclipse and use SWT for the GUI, but this comes with its own bag of problems.
I do of course agree that it'd be very nice if Beckhoff maintained their own realtime extension of the linux kernel, but they'd either have to keep it a binary blob and face deployment woes (compiled kernel-specific shims, separate distribution since it's non GPL-compliant) or, if they'd open-source it, they'd lose a lot of competitive advantage. Everyone and their dog is looking for a simple and cheap way to reliably develop and run IEC-61131 on standard PC hardware. There would be red ink flowing on their balance sheet if someone suddenly had an open-source replacement for TwinCAT (including support for all of the PC-attached hardware like bus interface cards etc).
The deal is that for Beckhoff, like for many other PC vendors, Windows is a way to sell their hardware (IPCs, I/O, drives, etc). I don't see MS taking over PC manufacturers, yet that's precisely what you imply here. It'd make just as much sense for MS to take over Beckhoff.
Now it's true that Beckhoff does sell their TwinCAT software, but if you get it with their IPC you get it for a 90% discount over a license for a "random" PC that you happen to have. So I don't think that for Beckhoff their own software sales are a huge part of the business. The software is a key enabler, but financially there's not all that much there directly. When you buy a low-end IPC from Beckhoff, about 10% of its price would ordinarily be TwinCAT, and likely no more than about 2.5% the Windows XP or CE OEM license. It's significantly less for higher-end IPCs (say 4% total). If MS wanted to get more money out of this market, they could simply increase the license fee they charge for their OEM licenses, and they have not much headroom there either. There's only so much that this market will bear.
Sigh. IPCs themselves are a big part of Beckhoff's business, and with few and between exceptions every single one they sell has a copy of Windows installed on it. MS could terminate OEM licensing agreements if they wanted to cut ties.
Pretty much their entire PLC business hinges on TwinCAT, and that's 100% dependent on Windows. If MS wanted to cut the ties or somehow curtail their access to the Windows platform, Beckhoff would be bankrupt in short order. Of course Beckhoff is no Nokia size wise -- with a USD 0.5E9 turnaround, about 1% of that of Nokia's.
Yet it's the same kind of dependence that Nokia will have with MS: a make-or-break type of a deal. If MS wanted to sink Nokia or Beckhoff, they could do so quite easily.
It's not foolishness. Everybody who does it otherwise (using linux, other realtime OSes, custom hardware) shows over and over that Beckhoff did the right thing. They are leveraging the virtually infinite OS R&D budget of Microsoft, and similarly huge R&D budgets of PC platform designers (CPU and chipset makers).
If you buy almost any other PLC platform, you're constrained by the hardware offered by the vendor. It used to be 8051 derivatives, and some still are offered like that, others went the DSP or ARM route. Yet, if you want a system that can talk to literally tens of thousands of I/O points and still offer stupidly fast cycle times, you just get a high-end PC, slap TwinCAT on it, and off you go. You don't even have to worry about partitioning the system. Due to the way Beckhoff designed their realtime Ethernet-based communication bus (EtherCAT), you can trivially have full redundancy at the network and PLC level. If you have a machine where all you need is a PLC and an operator panel, the cost proposition of going with a bog-standard OS that anyone can develop an HMI app for, then adding a software component to turn it into a PLC, cannot be beat.
As for MS "wanting" into that market: remember that a PLC still has to talk to the I/O, and that's where Beckhoff is also a leader. If MS released their own PLC software platform even today, they'd be at the mercy of everyone else as far as I/O goes. Beckhoff is vertically integrated in that respect: they offer their own IPCs, their own PLC platform, their own I/O that's based on standards and interfaces with almost every other legacy industrial bus out there, their own servo drives and actuators, and they are constantly expanding. Vertical integration has worked very well for them for the same reason it works very well for SpaceX. MS has a huge barrier to entry to become a vertically integrated PLC vendor, and it'd need to become one to really compete in this business. It's not like Boeing or Grumman can magically outdo SpaceX: in fact, they can't, because they lack integration.
Um, Beckhoff is a gold microsoft partner, and they are completely dependent on Microsoft technology: with leverage comes dependence and even vulnerability.
Again, it's all in how you play your cards. Beckhoff has bet big time on the PC platform and the Microsoft OS technology as a key component to that, and they came out on the top. Nokia is making pretty much an identical bet. If they come out on the bottom, I'd tend to think it's their own doing. Of course Elop at the helm makes things somewhat shaky: Beckhoff is a privately owned company, and I think their success is mainly because they owe nothing to nobody. I think that Trolltech's success was due to the same reason (private ownership), as soon as it became part of a publicly traded company things got somewhat uncertain.
I think it's all in how you play your cards. I know of one company that came out extremely well by innovating on MS platforms. It's all in the value you provide. Namely Beckhoff Automation. I have nothing to do with them, just a happy user. It's perhaps an unknown name in the software development world, but they are nevertheless top-notch innovators in the automation business. Their main claim to fame is in deciding about 2 decades ago that industrial controllers and PLCs must be built on the PC platform to stay competitive. So, while mostly everyone else was thinking there was value in doing stuff on custom hardware that was outdated pretty much the day it was released, they chose to go with a PC. These days they offer a line of 100% in-house designed Industrial PCs (IPC) -- and I mean they design their own motherboards, control the BIOS, assemble the darn things locally and not in China, etc. Their PLC software platform, called TwinCAT, runs side-by-side with bog-standard Windows and Windows CE, and offers hard-realtime performance (think of a 62.5us input-processing-output cycle on contemporary hardware). They ship their hardware with XP Embedded or CE preinstalled.
It's an interesting experience, to say the least, when you simply install TwinCAT (a practically unlimited trial is available -- try it out!) on a bog-standard clunker Dell with Windows XP and you can easily run a 500us PLC cycle, just like that.
Their newest push is to standardize their development environment. TwinCAT 2, the current shipping version, has one of those me-too IDEs for IEC 61131-3 programming languages. For TwinCAT 3 (entering a closed beta AFAIK), they went ahead with basing it on the Vistual Studio shell, and in addition to 61131-3 languages you can run C and C++ code in the realtime environment. They have pretty much leveraged the hell out of MS technology and they now ride the gravy train. I can't help but think that they must be doing it right, and everyone else who got burned by MS just didn't have a clue to begin with.
Hmm, then time to edit that wikipedia page, then! Thanks for the info.
Maybe one has to admit that sometimes the reality is such that there's no way to get evidence. The presumption that one has to be, unconditionally, able to obtain evidence no matter what is silly. Sorry, civil liberties sometimes imply that some crimes have to go unpunished. It's the price of a free society. Nothing wrong with that.
Maybe it's time to chose another job?
I wasn't that AC, but I can only hope that a loud whooosh is a fitting reply.
None of your listed statements are true. Any realistic appearing computer generated depiction that is indistinguishable from a depiction of an actual minor in sexual situations or engaging in sexual acts illegal under 18 U.S.C. 2252A. Drawings, cartoons, sculptures, and paintings of minors in sexual situations that do not pass the Miller test were made illegal under 18 U.S.C. 1466A.