3 ms·

Why wouldn't you be able to fork Mir? The open source licenses used explicitly allow that. Disagree with Canonical on strategy if you want, but spreading FUD

Why wouldn't you be able to fork Mir? The open source licenses used explicitly allow that. Disagree with Canonical on strategy if you want, but spreading FUD about lawsuits is misinformed at best, maliciously dishonest at worst.

zanny 14y ago
If you for Mir you can't accomplish anything by doing so because the drivers target the reference implementation. It is why you don't see prolific display servers all about like you do text editors, terminal emulators, or music players. And as Mir changes, and as those changes prompt changes in the drivers that run Mir, and derivative project ends up having to adopt those changes to continue using newer drivers. And unless the developers of a Mir fork also plan on maintaining patches to all the GUI toolkits and compositors to support their fork, they also need to emulate Mir's behavior in relation to the rest of the upwards stack.
- tmzt 14y ago
  Though if there is a well defined and stable driver ABI compatibility shouldn't really be a problem.
  - zanny 14y ago
    The kernel doesn't have a stable ABI, don't expect Canonical to get stable ABI's for Mir. And the fact it is meant to use SurfaceFlinger drivers gives two degrees of instability to contend with, because if Google changes SF at all and demands revised drivers, those changes have to make their way to Mir to use any revisions.
    - tmzt 14y ago
      I'm assuming that these drivers are userspace drivers, whatever interface they have with the kernel is another problem. The presence of SurfaceFlinger in these decisions seems to be derived from some speculation in an article, not based on what Canonical themselves have said. When it comes to embedded hardware graphics, the industry is coalescing around Android as a kind of HAL/BSP, and so other projects that want to support off the shelf available consumer hardware either end up having to adopt Bionic or develop a solution like libhybris. This allows non-Android systems to use the same hardware accelerated EGL drivers. SurfaceFlinger is one option for managing hardware buffers and blitting between surfaces in the main and GPU memory.

zanny 14y ago

If you for Mir you can't accomplish anything by doing so because the drivers target the reference implementation. It is why you don't see prolific display servers all about like you do text editors, terminal emulators, or music players. And as Mir changes, and as those changes prompt changes in the drivers that run Mir, and derivative project ends up having to adopt those changes to continue using newer drivers. And unless the developers of a Mir fork also plan on maintaining patches to all the GUI toolkits and compositors to support their fork, they also need to emulate Mir's behavior in relation to the rest of the upwards stack.

tmzt 14y ago
Though if there is a well defined and stable driver ABI compatibility shouldn't really be a problem.
- zanny 14y ago
  The kernel doesn't have a stable ABI, don't expect Canonical to get stable ABI's for Mir. And the fact it is meant to use SurfaceFlinger drivers gives two degrees of instability to contend with, because if Google changes SF at all and demands revised drivers, those changes have to make their way to Mir to use any revisions.
  - tmzt 14y ago
    I'm assuming that these drivers are userspace drivers, whatever interface they have with the kernel is another problem. The presence of SurfaceFlinger in these decisions seems to be derived from some speculation in an article, not based on what Canonical themselves have said. When it comes to embedded hardware graphics, the industry is coalescing around Android as a kind of HAL/BSP, and so other projects that want to support off the shelf available consumer hardware either end up having to adopt Bionic or develop a solution like libhybris. This allows non-Android systems to use the same hardware accelerated EGL drivers. SurfaceFlinger is one option for managing hardware buffers and blitting between surfaces in the main and GPU memory.