Bugs
0
Fixed
OpenICE patch
>
> Hi Jeff,
>
> I’m a contractor at NIST working on the ICE project. I have been tracking and using your OpenICE code releases here for some time. Your recent addition of reading /etc/issue for operating system information on Linux systems broke the code running here. Locally, /etc/issue is over 800 bytes long and contains a warning about accessing a federal government owned computer.
>
> After a little research, I found the file /etc/os-release has become a standard file in most all the major Linux distributions. The file was originally introduced for systemd, but it has since been picked up even by distributions that have not converted to using systemd. Ubuntu 12.04 LTS has the file, for instance. The file format is defined at http://www.freedesktop.org/software/systemd/man/os-release.html .
>
> I have attached a patch that reads this file instead of /etc/issue. I’m a C++ programmer and not a Java programmer so perhaps the code could be improved. But I have tested it here and it works. I hope you this useful.
>
> Dennis
Attachments:
0001-Use-etc-os-release-instead-of-etc-issue-for-OS-infor.patch
> Hi Jeff,
>
> I’m a contractor at NIST working on the ICE project. I have been tracking and using your OpenICE code releases here for some time. Your recent addition of reading /etc/issue for operating system information on Linux systems broke the code running here. Locally, /etc/issue is over 800 bytes long and contains a warning about accessing a federal government owned computer.
>
> After a little research, I found the file /etc/os-release has become a standard file in most all the major Linux distributions. The file was originally introduced for systemd, but it has since been picked up even by distributions that have not converted to using systemd. Ubuntu 12.04 LTS has the file, for instance. The file format is defined at http://www.freedesktop.org/software/systemd/man/os-release.html .
>
> I have attached a patch that reads this file instead of /etc/issue. I’m a C++ programmer and not a Java programmer so perhaps the code could be improved. But I have tested it here and it works. I hope you this useful.
>
> Dennis
Attachments:
0001-Use-etc-os-release-instead-of-etc-issue-for-OS-infor.patch
Answer
Answer
Fixed
Hi Dennis,
I’m sorry that the recent change broke the code for you and I greatly appreciate your reporting it and even including a patch. In our lab we’re still working on a really flexible deployment strategy for our ‘fleet’ of beaglebones. I added the /etc/issue as a quick way to see which had been upgraded to 14.04LTS. I should have done more research on the /etc/issue file in general before including it. I know a lot of folks at NIST who use CentOS, is that the distro you are using?
If I understand correctly what broke down was the lengthy string … probably throwing an exception in the CdrOutputStream? I’m really not thrilled about RTI’s API support for java programmers. On the plus side they have bound their underlying CDR (common data representation) libraries to java which is great. It means I can generate types natively in java (other implementations such as OpenDDS require types be generated in C++ first; then a JNI binding library is built specifically for those types … which is a multi-platform deployment nightmare). But on the other hand they do not support the standard java DDS API (I believe they plan to in the future) So as you can see the one adjustment I made to your patch was to jump some hurdles to avoid hardcoding the length (128). It would be nicer in java if they annotated max lengths in a way that facilitated validation. The commit in SourceForge git viewer:
http://sourceforge.net/p/mdpnp/code/ci/5757b04fabe6c870e748e7922a8573cc45a152b3/
If you wouldn’t mind I’d love to hear more about how you are using the code. Should I expedite a new release for you or are you building from source? If I know your particular areas of interest I can try to involve you in relevant discussions about how OpenICE should evolve. Also if you have issues or comments we’ve set up a website at http://community.openice.info that you can use in the future.
Thanks again,
Jeff
I’m sorry that the recent change broke the code for you and I greatly appreciate your reporting it and even including a patch. In our lab we’re still working on a really flexible deployment strategy for our ‘fleet’ of beaglebones. I added the /etc/issue as a quick way to see which had been upgraded to 14.04LTS. I should have done more research on the /etc/issue file in general before including it. I know a lot of folks at NIST who use CentOS, is that the distro you are using?
If I understand correctly what broke down was the lengthy string … probably throwing an exception in the CdrOutputStream? I’m really not thrilled about RTI’s API support for java programmers. On the plus side they have bound their underlying CDR (common data representation) libraries to java which is great. It means I can generate types natively in java (other implementations such as OpenDDS require types be generated in C++ first; then a JNI binding library is built specifically for those types … which is a multi-platform deployment nightmare). But on the other hand they do not support the standard java DDS API (I believe they plan to in the future) So as you can see the one adjustment I made to your patch was to jump some hurdles to avoid hardcoding the length (128). It would be nicer in java if they annotated max lengths in a way that facilitated validation. The commit in SourceForge git viewer:
http://sourceforge.net/p/mdpnp/code/ci/5757b04fabe6c870e748e7922a8573cc45a152b3/
If you wouldn’t mind I’d love to hear more about how you are using the code. Should I expedite a new release for you or are you building from source? If I know your particular areas of interest I can try to involve you in relevant discussions about how OpenICE should evolve. Also if you have issues or comments we’ve set up a website at http://community.openice.info that you can use in the future.
Thanks again,
Jeff
Customer support service by UserEcho
I’m sorry that the recent change broke the code for you and I greatly appreciate your reporting it and even including a patch. In our lab we’re still working on a really flexible deployment strategy for our ‘fleet’ of beaglebones. I added the /etc/issue as a quick way to see which had been upgraded to 14.04LTS. I should have done more research on the /etc/issue file in general before including it. I know a lot of folks at NIST who use CentOS, is that the distro you are using?
If I understand correctly what broke down was the lengthy string … probably throwing an exception in the CdrOutputStream? I’m really not thrilled about RTI’s API support for java programmers. On the plus side they have bound their underlying CDR (common data representation) libraries to java which is great. It means I can generate types natively in java (other implementations such as OpenDDS require types be generated in C++ first; then a JNI binding library is built specifically for those types … which is a multi-platform deployment nightmare). But on the other hand they do not support the standard java DDS API (I believe they plan to in the future) So as you can see the one adjustment I made to your patch was to jump some hurdles to avoid hardcoding the length (128). It would be nicer in java if they annotated max lengths in a way that facilitated validation. The commit in SourceForge git viewer:
http://sourceforge.net/p/mdpnp/code/ci/5757b04fabe6c870e748e7922a8573cc45a152b3/
If you wouldn’t mind I’d love to hear more about how you are using the code. Should I expedite a new release for you or are you building from source? If I know your particular areas of interest I can try to involve you in relevant discussions about how OpenICE should evolve. Also if you have issues or comments we’ve set up a website at http://community.openice.info that you can use in the future.
Thanks again,
Jeff