As I sit here writing, watching TV and waiting for my wife to go into labor, I wonder about failure. More specifically, I wonder how my generation will fail our children. My parent's generation (Boomers) and their parents (WWII) have failed us. A couple of examples are energy and health care.
The failure in energy is that they couldn't muster the strength of character and will to do what was needed after the 1970s oil crisis. They did start the buying smaller cars, but it didn't last long enough to make the lasting changes needed. Now it's 2009 and we have a economy that's in the toilet. We're bailing out automotive companies that didn't see the writing on the wall because we weren't smart enough as consumers to see that gas might go up a lot one day. Our parents didn't remember the lesson of the 1970s to teach us. They believed cheap gas would be here forever. (When my wife and I bought a car this year, we didn't buy a gas guzzler.)
Health care is another issue where they've failed us. I don't care if you're a Republican or Democrat. You are to blame. (Party loyalty is another joke.)
The Boomers are in the process of retiring. They're going to get health care via Medicare. While they get theirs, they're leaving their children and grand-children behind. Premiums are going up. It may not be seen because the employer is covering the costs, but that's less money in our pockets.
This isn't the only problem. On average it used to take six months to find a job. Even before the recession, the time to find a new job was increasing towards one year. This has special implications for health care. An individual/family can go no more than 6 months without health care coverage before pre-existing condition causes issues with your new coverage.
I had hoped that the health care bill coming from Congress would provide a reasonable public option but it's not going to be. Once again Democrats and Republicans have screwed over their children. They didn't do what really needed to be done which was to prohibit employer provided health care plans.
The current system relies on the employer providing the health care coverage. Why does it have to be this way? My employer doesn't provide my car insurance. I buy the coverage that I need for my car. I have to buy it or I can't drive my car on the road. The money for health insurance should go into my paycheck.
This system is a throwback to the company town where the company owned the town. The employee lived in the company owned house and bought groceries at the company store with company provided scrip. This system makes the employee beholden to the company and probably reduces the number of people attempting to start small businesses due to inability to buy coverage. (Try buying coverage on the open market with pre-existing conditions and see how bad/costly the policies are.)
Oh well, you reap what you sow. Medicare payments to doctors may be slashed up to 21%. This may force many doctors to not accept new Medicare patients. (I saw this first hand a few years ago while sitting in my doctor's office in Va Beach. They told an old lady that they didn't accept new Medicare patients.) Even the doctors are scared about going on Medicare. The irony is fantastic.
But [Dr.] Hagan himself became Medicare-eligible this month -- and he's nervous. "If I accept Medicare for myself and my wife, I'm fearful I won't be able to stay with my cardiologist and my wife won't be able to stay with her physicians," he said.
I wonder how my generation will fail our children.
Update 1:
The article What a Long, Strange, Thoroughly Obnoxious Trip It's Been will probably offend you if you're a boomer. It's an even more scathing look at Boomers and Hippies.
Update 2:
Here's another example of how Boomers don't get it. I think that it shows the real disconnect between Boomers and their children/grand-children. Peggy Noonan is talking about how no one believes that politicians have answer anymore. I don't believe that anyone of my generation believes that politicians have the answer anymore, if they ever did.
Boomers are looking for salvation in their politicians. As Boomers die off, expect political party affiliation too mean less and less. Democrats or Republicans probably aren't prepared for this. Political party affiliation is becoming less about ideology and more about not putting in the same ol bunch of idiots every time.
Saturday, October 31, 2009
Replacing DIS/HLA with AMQP/ProcotolBuffers (Part 1)
Update (2017-03-06): It's been a while since I wrote this. If you're doing distributed simulation for a defense related reasons, you're probably still using HLA or DIS. It's never going away. There are only a few products that do HLA and you probably know what they are. There's also a newer standard called DDS created OMG. OMG is the same organization behind CORBA.
-------
High Level Architecture (HLA) is way of passing simulation data around. HLA was meant to replace DIS. Both systems are crap.
DIS is still used because it's simple, standardized and well understood. Anyone can implement it and inter-operate with other implementations. The biggest problems is that since it's standardized, implementing capabilities outside of the spec means that the new feature/packet won't be supported on others systems.
HLA was supposed to solve the above problems. However, it's cause more problems than it's really solved. It's the reason why the Air Force and others outside of the Navy are sticking with DIS.
One problem with HLA is that there are multiple standards. There's a DOD standard that everyone inside the Navy modeling and simulation world uses and the IEEE 1516 standard. I've not seen anyone actually using the 1516 standard.
Another issue is what the standard actually specifies. HLA while a standard is not an product that you would use. Run-Time Infrastructure (RTI) is the middle-ware that is used. The standard specifies ways in data is distributed and programming interfaces, but it does not specify a wire protocol. As a result, implementations of an RTI are usually not compatible on the wire. So, competing implementations can't talk to one another. This leads to vendor lock-in in that everyone that wants to play in a sandbox must agree to use a common version.
There are various RTI implementations. Raytheon makes one called RTI-NG Pro. It's the "standard" that the Navy has chosen. From what I understand it based on the original DMSO source code. The code has been closed up and you can now buy the "standard" RTI from them.
Other implementations are around. Portico is an open source effort to implement the DoD standard and 1516. RTI-S, while not compliant with the HLA standards, it implements the programming interface and can be easily swapped out with other implementations. It has features that make it desirable to use. RTI-S has funded by a few government agencies. It's government open source in that you can get it if you need it and you're working on a government contract. There was some talk of open sourcing, but I'll believe it when I see it.
The nice feature of the HLA is that the data to be shared between the federates is defined in the Federation Object Model (FOM). As long as all of the players agree on the FOM (and an RTI), it's easy to play together. The FOM can be shared and everyone can implement those pieces that interests them.
The FOM side steps the problem of having to re-convene a DIS committee to update the standard for the new features that are need. It's more agile and easier to change when the players decide that the original understanding was faulty. (What? We were wrong? Doesn't happen here.)
So, we come back to our original problems: DIS => Simple easy to use. HLA => More flexible but must sell soul for licenses.
I think that there's hope for the above problems and TENA isn't it.
What's needed is to combine the simplicity of DIS with the flexibility of the FOM while making it opensource. I believe that Google's ProtocolBuffers (PB) may be a potential solution to part of the problem.
Read the link to get more detail, but a PB is a way of specifying data to be sent on the network or stored in a file in a binary format. The PB is actually specified in a simple text file. It's not even xml. The file with PB definition is processed by a code generator. The resulting code is used to marshal/unmarshal the data. There are code generators for C++, Java, Python and Ruby.
While code generation and simple format specification are great features, the best one is the ability to be backwards compatible with previous specifications. This is accomplished with the required and optional tags for fields in the specification. (Click the PB link above and you'll see an example.)
The PB could be used with UDP, TCP, or Multi-cast to push data onto the network. Just a quick glance at the PB group at Google, produced this example of using PB on the network.
Since DIS is simple and easy to understand, it probably won't take much effort to create a PB version of DIS. NPS has created an XML version of the specification. While it will take some work, parsing the xml and generating the necessary PB files should reasonably straight forward.
While it's nice to have DIS in the PB format, it's just DIS in a new format. As mentioned above, PB provides an easy way to extend an existing packet with new data while maintaining backwards capability with applications that might not have the new data fields. This would allow experimentation and extension without worrying about convening a new committee meeting.
This same capability could be extended to the FOM for HLA. The FOM format is well defined but it has it's own issues and could be more flexible. (Why did it have to have ID numbers specified?) It would not take much to parse it and generate the appropriate PB files.
Since there is no wire standard for HLA, it's not a problem to just broadcast the packets need for HLA. However, HLA specifies certain capabilities that is needed compliance. Data Distribution Management (DDM) is one item that would need to be addressed. DDM allows players to subscribe to data that meets special requirements. PB by itself can't do this. There is potential fix that is open source way and has some standards support.
Advanced Message Queue Protocol (AMQP) may be the standard that is needed to fix the problem. QPID is an opensource implementation that is used by RedHat and others. I'll cover it in Part 2.
Update:
Thrift is an Apache Incubator project that could serve as an alternative to PB.
Benchmark of PB vs other systems.
Update:
Fixed problem with link to DIS XML spec developed by MOVES.
-------
High Level Architecture (HLA) is way of passing simulation data around. HLA was meant to replace DIS. Both systems are crap.
DIS is still used because it's simple, standardized and well understood. Anyone can implement it and inter-operate with other implementations. The biggest problems is that since it's standardized, implementing capabilities outside of the spec means that the new feature/packet won't be supported on others systems.
HLA was supposed to solve the above problems. However, it's cause more problems than it's really solved. It's the reason why the Air Force and others outside of the Navy are sticking with DIS.
One problem with HLA is that there are multiple standards. There's a DOD standard that everyone inside the Navy modeling and simulation world uses and the IEEE 1516 standard. I've not seen anyone actually using the 1516 standard.
Another issue is what the standard actually specifies. HLA while a standard is not an product that you would use. Run-Time Infrastructure (RTI) is the middle-ware that is used. The standard specifies ways in data is distributed and programming interfaces, but it does not specify a wire protocol. As a result, implementations of an RTI are usually not compatible on the wire. So, competing implementations can't talk to one another. This leads to vendor lock-in in that everyone that wants to play in a sandbox must agree to use a common version.
There are various RTI implementations. Raytheon makes one called RTI-NG Pro. It's the "standard" that the Navy has chosen. From what I understand it based on the original DMSO source code. The code has been closed up and you can now buy the "standard" RTI from them.
Other implementations are around. Portico is an open source effort to implement the DoD standard and 1516. RTI-S, while not compliant with the HLA standards, it implements the programming interface and can be easily swapped out with other implementations. It has features that make it desirable to use. RTI-S has funded by a few government agencies. It's government open source in that you can get it if you need it and you're working on a government contract. There was some talk of open sourcing, but I'll believe it when I see it.
The nice feature of the HLA is that the data to be shared between the federates is defined in the Federation Object Model (FOM). As long as all of the players agree on the FOM (and an RTI), it's easy to play together. The FOM can be shared and everyone can implement those pieces that interests them.
The FOM side steps the problem of having to re-convene a DIS committee to update the standard for the new features that are need. It's more agile and easier to change when the players decide that the original understanding was faulty. (What? We were wrong? Doesn't happen here.)
So, we come back to our original problems: DIS => Simple easy to use. HLA => More flexible but must sell soul for licenses.
I think that there's hope for the above problems and TENA isn't it.
What's needed is to combine the simplicity of DIS with the flexibility of the FOM while making it opensource. I believe that Google's ProtocolBuffers (PB) may be a potential solution to part of the problem.
Read the link to get more detail, but a PB is a way of specifying data to be sent on the network or stored in a file in a binary format. The PB is actually specified in a simple text file. It's not even xml. The file with PB definition is processed by a code generator. The resulting code is used to marshal/unmarshal the data. There are code generators for C++, Java, Python and Ruby.
While code generation and simple format specification are great features, the best one is the ability to be backwards compatible with previous specifications. This is accomplished with the required and optional tags for fields in the specification. (Click the PB link above and you'll see an example.)
The PB could be used with UDP, TCP, or Multi-cast to push data onto the network. Just a quick glance at the PB group at Google, produced this example of using PB on the network.
Since DIS is simple and easy to understand, it probably won't take much effort to create a PB version of DIS. NPS has created an XML version of the specification. While it will take some work, parsing the xml and generating the necessary PB files should reasonably straight forward.
While it's nice to have DIS in the PB format, it's just DIS in a new format. As mentioned above, PB provides an easy way to extend an existing packet with new data while maintaining backwards capability with applications that might not have the new data fields. This would allow experimentation and extension without worrying about convening a new committee meeting.
This same capability could be extended to the FOM for HLA. The FOM format is well defined but it has it's own issues and could be more flexible. (Why did it have to have ID numbers specified?) It would not take much to parse it and generate the appropriate PB files.
Since there is no wire standard for HLA, it's not a problem to just broadcast the packets need for HLA. However, HLA specifies certain capabilities that is needed compliance. Data Distribution Management (DDM) is one item that would need to be addressed. DDM allows players to subscribe to data that meets special requirements. PB by itself can't do this. There is potential fix that is open source way and has some standards support.
Advanced Message Queue Protocol (AMQP) may be the standard that is needed to fix the problem. QPID is an opensource implementation that is used by RedHat and others. I'll cover it in Part 2.
Update:
Thrift is an Apache Incubator project that could serve as an alternative to PB.
Benchmark of PB vs other systems.
Update:
Fixed problem with link to DIS XML spec developed by MOVES.
Friday, October 23, 2009
Adblock and CNN
I've noticed that CNN is putting more ads on their videos. This means that if I have AdBlock enabled that I can't watch them. If I want to watch something, I have to disable AdBlock. All this adds up to watching less video on CNN's site.
Saturday, October 17, 2009
Comcast and Encrypted Digital Content
It looks like Comcast is encrypting many digital channels that I could previously watch on my television. Previously, I could watch many channels that I get on Extended Basic cable in HD on a digital channel. SyFy, Discovery, AE, TNT, TBS, and many others was being broadcast unencrypted in HD. It was nice that I didn't need a digital cable box. Many of those channels have disappeared.
It would be nice to HD television, but I'm not "renting" a digital cable box. I've got enough stuff connected to my TV. I'm not investing in a cable card television either. TVs cost too much to be buying a new TV to get the latest new feature. If anything, I may end up dropping the cable television and just continue to buy my Internet access from the cable company.
Hulu now has a linux desktop client. Perhaps, I'll use that to watch television programming that I normally couldn't watch without cable. The other option is to buy DVD's of those shows or use NetFlix.
DVD's of popular shows average around $50 for the season. My extended cable costs ~$45/mth or ~$540/year. For that much money, seaons of 10 programs could be purchased every year. Most seasons of a particular program like House ($35) has 24 episodes. This means that ~240 hours of programming could be bought. (Really it's less, because an episode is about 50 minutes.)
Or, more could be bought if you factored in the cost of digital cable. If digital cable with HD support cost $100/mth or 24 seasons of television programs for a year. That's a lot of television. Of course you can't watch sports on ESPN.
Sports would be the biggest problem. If you love sports, you're still tied to cable. Some of the problem could be mitigated by using Over The Air broadcast reception. That is limited to the local station broadcast and the ability to receive those.
Overall, considering the quality of programming, the cost, and the awful boxes that have to be connected to receive the higher quality broadcasts; it doesn't seem worth it to have cable except as a connection to the Internet. If I need to hook a box up to my tv, I might as well use a computer that would allow me to read my email and use a keyboard. The Wii, Xbox, and Playstation aren't good enough for that. They suck.
It would be nice to HD television, but I'm not "renting" a digital cable box. I've got enough stuff connected to my TV. I'm not investing in a cable card television either. TVs cost too much to be buying a new TV to get the latest new feature. If anything, I may end up dropping the cable television and just continue to buy my Internet access from the cable company.
Hulu now has a linux desktop client. Perhaps, I'll use that to watch television programming that I normally couldn't watch without cable. The other option is to buy DVD's of those shows or use NetFlix.
DVD's of popular shows average around $50 for the season. My extended cable costs ~$45/mth or ~$540/year. For that much money, seaons of 10 programs could be purchased every year. Most seasons of a particular program like House ($35) has 24 episodes. This means that ~240 hours of programming could be bought. (Really it's less, because an episode is about 50 minutes.)
Or, more could be bought if you factored in the cost of digital cable. If digital cable with HD support cost $100/mth or 24 seasons of television programs for a year. That's a lot of television. Of course you can't watch sports on ESPN.
Sports would be the biggest problem. If you love sports, you're still tied to cable. Some of the problem could be mitigated by using Over The Air broadcast reception. That is limited to the local station broadcast and the ability to receive those.
Overall, considering the quality of programming, the cost, and the awful boxes that have to be connected to receive the higher quality broadcasts; it doesn't seem worth it to have cable except as a connection to the Internet. If I need to hook a box up to my tv, I might as well use a computer that would allow me to read my email and use a keyboard. The Wii, Xbox, and Playstation aren't good enough for that. They suck.
Subscribe to:
Posts (Atom)