It isn’t necessarily a matter that it couldn’t be fixed. With an open source project like this fixing bugs of this sort requires someone to volunteer to try and fix it. That hasn’t happened, probably because of a combination of it not being a problem that the main developers have faced and the focus on OH 2.
It isn’t necessarily that nobody cares. But OH 1.8 (core, not necessarily bindings) is basically end of life. There will be no new major updates and there will not be a 1.9 version released. But again, the 1.9 bindings are continuing to be fixed and enhanced.
It depends on what bindings you install. The core is rock solid. And it is possible to run using the OH 2 core with all 1.9 bindings which is as stable as OH 1.8.3. I’ve been running OH 2 now for a couple of months and find it as stable as 1.8.3.
There is a migration tutorial I wrote when I transitioned. Even with all the careful documentation and redoing things different ways that I had to do to write the tutorial I had transitioned my setup to OH 2 using 1.9 bindings in a couple of hours. If using 1.9 version bindings, your config can move over unchanged with a couple of minor exceptions:
- you have to change the imports on your rules files because some core classes have moved and are not included by default
- you have to break openhab.cfg up into separate .cfg files, one for each addon.
I believe so, thought that is a really unsatisfactory workaround.
I don’t know. I’ve experienced it on Ubuntu 14, 15, and 16. I think the theory is that the file system runs out of inodes or the disk is too busy to respond to the request to open the file.