No announcement yet.

Canonical Developers To The Community: Help Us Figure Out The Direction Of Mir

  • Filter
  • Time
  • Show
Clear All
new posts

  • #21
    Originally posted by DanL View Post
    Yes, yes, we know - you want everything to run natively on Wayland and you want it done yesterday. Maybe if you repeat it 10,000 more times, it will happen. But that's up to the devs of those projects and is unrelated to the topic.
    No, your post is unrelated to the topic. If the community decides that Mir is a no-go, they could then free up resources and have those devs contribute to other projects instead, for example the ones uid313 mentioned.
    Last edited by Vistaus; 23 November 2017, 11:56 AM.


    • #22
      Originally posted by kravemir View Post

      Wine won't be needed for long. Lots of developers realize, that Linux is slowly becoming widely used platform. But, in order to run old stuff, wine is useful.
      Or to run the more complex software developed by individual developers. Because they only work the software in their spare time, they cannot easily port it, esp. when it's more complex software.


      • #23
        Originally posted by jpg44 View Post
        I wouldn't say it would be a good use of developer resources to spend time on this, when the time could be spent adding more capabilities to the software.
        Depends. If they have 20 people working on a project, they could assign 1 or 2 people who will port it to Wayland. It will go slow, but in the end, we'll get there.


        • #24
          Vistaus covered some of this:

          1) MIR began as its own API, Implementation etc. Now, its implementing Wayland. But, there are still many other implementations of Wayland already. It should also be relatively trivial to implement a Wayland compositor using a library like libweston and other libraries that allows you to focus on implementing your UI by handling the nitty gritty for you. Developer resources are still better spent elsewhere to allow Linux to take on Windows.

          2) The issue of having binary drivers run on Linux is contentious. If it were a Windows driver layer, I think it would be okay and would increase software freedom in the long run. Explanation: Linux deployment would begin to take over the desktop. Its better to have an open source OS with a few legacy binary drivers than a completely closed source OS. The increased user base of Linux would increase the impetus for fully open source native drivers which can then allow the binary drivers to be phased out, once Linux gains the leverage to make this happen. Linux right now lacks leverage to make that happen because the desktop user base is so small. This is true of multimedia hardware devices such as TV tuner cards for instance.

          3) The attitude that "people who need windows app or hardware should use windows" is why Linux remains at 3% desktop user share. Many of us have wanted to get off Windows but cannot because we are tied to proprietary apps and some hardware that Linux does not support. Why should people use Linux? Yes I do read the Linux kernel and it should be a practical reality that people do not depend on blackbox code, because as RMS says, its about freedom. The main disageement I have with RMS is that by supporting some binary drivers from Windows, in the long run, most of the world would be running a fully open source OS. There has to be a practical migration path.


          • #25
            Originally posted by jpg44 View Post

            I respectfully disagree. Wine is among the top most valuable Linux projects. But this is some of the differences between different kinds of mentality on the subject. Many are concerned more about freedom, so want to make it easier for more people to move to a free OS. With what you want, this will never happen. Most people will be left with no choice to stay with Windows, even if they want to move to Linux. Also, on a driver compatability layer, it wouldnt be messy. I would advocate such things be done outside the kernel or in a module, then the mess would only be loaded by people who need it
            Furthermore, wine has helped in the past (and probably still does/will) various open source projects with the porting process from Windows. I vaguely remember some Chromium browser dev's saying that wine was a big help when it was originally ported over to GNU Linux. I'm also told it's helped with numerous native game ports too.

            Edit: I believe eON is a well known wine based library for games (I'm not sure if this is a run-time layer or not), but there's also winelib (which is compile time AFAIK):
            Last edited by Mystro256; 23 November 2017, 01:10 PM.


            • #26
              I do actually agree that the Windows App issue is gradually going away. Slowly. Not for necessarily good reasons from an open source or user rights perspective, because its due to Software as a Service. Running apps on a cloud rather than on the desktop is even worse, even where both are proprietary, due to who posesses the data. Its a throwback to the bad old mainframe days.

              I've always thought, companies could save resources if they were using Qt for app development rather than for proprietary APIs. Often the issue has been the quality of the RAD and app development tools which is why people would develop for propreitary platforms. Its more developers choose their development tool by has the fastest workflow and best feature set than choose the API.


              • #27
                Originally posted by Vistaus View Post
                No, your post is unrelated to the topic.
                Yeah, because I talked about the future of Mir. That was totally unrelated...

                If the community decides that Mir is a no-go
                That's not the question the referenced post/thread asked. Go read it, because you obviously didn't. If you want to dance on Mir's grave, go to sleep and maybe you'll have a dream about it.


                • #28
                  C++ is really horrible. From build tools, to testing, to package management, to STL, to the actual code. Rust is here a real relieve for embedded projects.


                  • #29
                    Originally posted by tomtomme View Post

                    MIR is not comparable to wayland. MIR is AFAIK more like Weston (window management and compositor). Andit now works with wayland. Dumping MIR will help nobody. Helping MIR could help the smaller Desktop Environments to get wayland support, like MATE. MATE does not have the resources to migrate to wayland but with MIR they may get there.
                    Can't they 'copy paste' stuff from Gnome or KDE, instead of MIR? Or even Weston?
                    Anything but MIR.


                    • #30
                      They should work on improving desktop Ubuntu so that it might get profitable.
                      MIR wont be the compositor for Ubuntu anyway.