6 ms·

for the record. this: "ranging from the sensible (we want to write our own display serve so that we can control it)" is sensible to him. What the hel

for the record. this: "ranging from the sensible (we want to write our own display serve so that we can control it)" is sensible to him. What the hell is going on at Canonical? I can't imagine how BADLY mir will damage desktop development in linux if Canonical actually forces its adoption and then holds the main repository. It would have to be forked to get it away from them. Are we even allowed to fork CCA code? Why do I get the feeling that if any of this happens, canonical is going to be suing linux end users. what a mess.

asb 14y ago
He means it's a sensible speculation to make, not necessarily that it's a good reason for Canonical to start Mir.
marcoperaza 14y ago
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.
Sanddancer 14y ago
So why does RedHat seem to get a pass with GNUists when they do similar things, such as with writing systemd instead of patching upstart?
- dscrd 14y ago
  It's a good point. I see two options: 1. we're irrational morons and just like RedHat more or 2. systemd is technically so much better than upstart. Perhaps both.
  - fingerprinter 14y ago
    Ah, the old false dichotomy logical fallacy.
    - dscrd 14y ago
      Well, either it actually isn't or you're trying to troll me.
- andor 14y ago
  Some core concepts of upstart and systemd are incompatible. Even if they patched upstart instead of starting from scratch it would now be a completely different system. In his initial blog post about systemd, Lennart Poettering writes: "Well, the point of the part about Upstart above was to show that the core design of Upstart is flawed, in our opinion. Starting completely from scratch suggests itself if the existing solution appears flawed in its core. However, note that we took a lot of inspiration from Upstart's code-base otherwise." Link: http://0pointer.de/blog/projects/systemd.html http://0pointer.de/blog/projects/systemd.html Unlike the Mir specs, this post is really detailed. Upstart is certainly an improvement on sysvinit, but falls short compared to more modern init systems like Apple's launchd.
  - Sanddancer 14y ago
    Mir likewise states that inherent incompatibilities is exactly why they're creating a new project as well. Though a big difference being that Upstart is actually in use, whereas no one's using Wayland. To be quite honest, a lot Poettering's rationalizations with systemd, especially when discussing other inits like launchd, seem to be purely NIH. He could do this work and organize with what's already out there, but he'd rather do our own thing. Instead of creating a system that is backward compatible, he's saying for daemon writers to write for a completely new specification, and to ignore any pretenses of compatibility, like not double forking. More discouraging are the intentional incompatibilities, and statements that they're only targeting the linux kernel and udev, and will reject patches that make it more compatible with other systems.
fingerprinter 14y ago
Wat? This comment literally makes no sense. Can you try explaining it again? Canonical can't force any other project to use Mir. So, what are you saying? Any open source project can be forked. So, what are you saying? Canonical suing linux END users? What? What are you trying to say here?
- GhotiFish 14y ago
  >This comment literally makes no sense. Can you try explaining it again? SURE! Let's give it a go! >Canonical can't force any other project to use Mir. So, what are you saying? Yes they can, Canonical can force adoption with their user base. Ubuntu has made itself the defacto distribution. Denying that canonical can't force adoption of a standard in linux is almost as bad as denying microsoft can't force the adoption of a standard in general. Lookout everybody! Here comes C# and .net! choo choo. >Any open source project can be forked. So, what are you saying? Actually no, they can't. Freely licensed open source projects (FOSS) definitely can! But the CCA is not GPL compatible. Worse, it's not clear exactly what Canonical can do with the CCA. The CCA gives canonical the right to change the license at whim. To be honest, this is fear, uncertainty, and doubt. but no spreading necessary. Canonical changed to a new, not well understood license, which gave them permission to change to other licenses. F I don't trust canonical, U I'm not certain exactly what they can do with that license D and I doubt it's anything good. Shoe fits. >Canonical suing linux END users? What? What are you trying to say here? I have a feeling that if any group of developers actively deprived Canonical of it's control over any of the projects by forking them and becoming more popular, they would manipulate the terms of their license, and sue the party that forked the repository. This was speculation, I have no idea to be honest what they are capable of. Of course, I wouldn't be worried at ALL if they were just using the freaking GPL. Hope that answered your questions.
  - deleted 14y ago
    [deleted]
  - eurleif 14y ago
    The CCA isn't a software license issued to end users, like the GPL; it's an agreement contributors sign giving Canonical rights to their code. It looks like a less-restrictive alternative to copyright assignment, which the FSF requires for contributions. What is GPL incompatible about it? Note that it includes "a promise back to the contributor to release their contribution under the license in place when they made the contribution" (http://www.canonical.com/contributors/faq http://www.canonical.com/contributors/faq).

asb 14y ago

He means it's a sensible speculation to make, not necessarily that it's a good reason for Canonical to start Mir.

marcoperaza 14y ago

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.

Sanddancer 14y ago

So why does RedHat seem to get a pass with GNUists when they do similar things, such as with writing systemd instead of patching upstart?

dscrd 14y ago
It's a good point. I see two options: 1. we're irrational morons and just like RedHat more or 2. systemd is technically so much better than upstart. Perhaps both.
- fingerprinter 14y ago
  Ah, the old false dichotomy logical fallacy.
  - dscrd 14y ago
    Well, either it actually isn't or you're trying to troll me.
andor 14y ago
Some core concepts of upstart and systemd are incompatible. Even if they patched upstart instead of starting from scratch it would now be a completely different system. In his initial blog post about systemd, Lennart Poettering writes: "Well, the point of the part about Upstart above was to show that the core design of Upstart is flawed, in our opinion. Starting completely from scratch suggests itself if the existing solution appears flawed in its core. However, note that we took a lot of inspiration from Upstart's code-base otherwise." Link: http://0pointer.de/blog/projects/systemd.html http://0pointer.de/blog/projects/systemd.html Unlike the Mir specs, this post is really detailed. Upstart is certainly an improvement on sysvinit, but falls short compared to more modern init systems like Apple's launchd.
- Sanddancer 14y ago
  Mir likewise states that inherent incompatibilities is exactly why they're creating a new project as well. Though a big difference being that Upstart is actually in use, whereas no one's using Wayland. To be quite honest, a lot Poettering's rationalizations with systemd, especially when discussing other inits like launchd, seem to be purely NIH. He could do this work and organize with what's already out there, but he'd rather do our own thing. Instead of creating a system that is backward compatible, he's saying for daemon writers to write for a completely new specification, and to ignore any pretenses of compatibility, like not double forking. More discouraging are the intentional incompatibilities, and statements that they're only targeting the linux kernel and udev, and will reject patches that make it more compatible with other systems.

fingerprinter 14y ago

Wat? This comment literally makes no sense. Can you try explaining it again? Canonical can't force any other project to use Mir. So, what are you saying? Any open source project can be forked. So, what are you saying? Canonical suing linux END users? What? What are you trying to say here?

GhotiFish 14y ago
>This comment literally makes no sense. Can you try explaining it again? SURE! Let's give it a go! >Canonical can't force any other project to use Mir. So, what are you saying? Yes they can, Canonical can force adoption with their user base. Ubuntu has made itself the defacto distribution. Denying that canonical can't force adoption of a standard in linux is almost as bad as denying microsoft can't force the adoption of a standard in general. Lookout everybody! Here comes C# and .net! choo choo. >Any open source project can be forked. So, what are you saying? Actually no, they can't. Freely licensed open source projects (FOSS) definitely can! But the CCA is not GPL compatible. Worse, it's not clear exactly what Canonical can do with the CCA. The CCA gives canonical the right to change the license at whim. To be honest, this is fear, uncertainty, and doubt. but no spreading necessary. Canonical changed to a new, not well understood license, which gave them permission to change to other licenses. F I don't trust canonical, U I'm not certain exactly what they can do with that license D and I doubt it's anything good. Shoe fits. >Canonical suing linux END users? What? What are you trying to say here? I have a feeling that if any group of developers actively deprived Canonical of it's control over any of the projects by forking them and becoming more popular, they would manipulate the terms of their license, and sue the party that forked the repository. This was speculation, I have no idea to be honest what they are capable of. Of course, I wouldn't be worried at ALL if they were just using the freaking GPL. Hope that answered your questions.
- deleted 14y ago
  [deleted]
- eurleif 14y ago
  The CCA isn't a software license issued to end users, like the GPL; it's an agreement contributors sign giving Canonical rights to their code. It looks like a less-restrictive alternative to copyright assignment, which the FSF requires for contributions. What is GPL incompatible about it? Note that it includes "a promise back to the contributor to release their contribution under the license in place when they made the contribution" (http://www.canonical.com/contributors/faq http://www.canonical.com/contributors/faq).