Announcement

Collapse
No announcement yet.

Ubuntu 14.04 Codename Revealed, Mir Haters Attacked

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • chrisb
    replied
    Originally posted by bridgman View Post
    Android drivers generally have open source kernel components even if the user-space bits are proprietary and binary-only.
    I looked for some statistics to back this up and found this informal and out-of-date (2011) survey of Android tablets which indicates that, out of 138 Android devices surveyed, 118 had closed source kernel components, and 20 had open source kernel components. That's only 14.5% open source, so unless things have changed substantially since then, the majority of Android devices are using closed source kernel modules. (I would suspect that the number hasn't really changed, and that the number using closed source in phones would be slightly higher since they required a 3g chipset driver, but I haven't seen any surveys for Android phones)

    I would be interested if anyone has seen more recent surveys?

    Leave a comment:


  • blackiwid
    replied
    Originally posted by makomk View Post
    ...
    you point very corner cases, who many linux users dont care

    1. with the driver stuff you mean they changed their stuff to support proprietary drivers right? thats than sad that we have a not so good architecture because of nvidia
    2. wine who cares about wine... I dont want to run unfree software under linux, maybe in a sandbox vm like kvm but not really native. I have a seperate pc, it doesnt really make sense to install nsa-trojans and backdoors to your free software just use windows on such pcs in the first place and know its a rootkit.

    So yes there are shurely solutions for that, but that you focus so hard and most evil stuff you could do with it tells much about your priorities.

    But another big point, you do like wayland has big problems and MIR not, Mir is a piece of shit at least at the same amount then wayland is right now. Its also not usable for anybody it has no advantages for users. thats why they disabled it in the current ubuntu version. And even Xwayland is not usable. The only plattform they ship wayland instead of X is mobile... but there Xwayland does not work, so you cant run any linux apps, just this 10 garbage demo apps they developed for mir.

    So yes Wayland isnt done yet yes but at least it seems gnome will be done in 5 months more or less. But general I dont see much benefit from neighter Mir or Wayland in short term, at the moment u cant bypass XWayland or XMir to do something usefull, and there you get worse Results (Benchmarks) so both is not ready for production yet.

    So maybe you should look into Mir and show where all your problems you have are fixed there, show me the perfect running wine in mir (without XMIR) show me anything good there.
    Last edited by blackiwid; 21 October 2013, 08:48 AM.

    Leave a comment:


  • makomk
    replied
    Originally posted by xeekei View Post
    The idea with Wayland is making the already available compositors the "display servers", like KWin in KDE and Mutter in GNOME. Mir wouldn't be a problem at all if it used the Wayland protocol, but it doesn't. It uses its own.
    Having the compositor be the display server was one of the main original selling points, but in practice they ran into fundamental problems - on multi-user systems everyone would have to use the same window manager and desktop, and also your choice of window manager would depend on your graphics drivers. So now they're splitting it into a Wayland "system compositor" running a "session compositor" which renders frames and passes them to the system compositor through a hardware-independent API, with the system compositor handling the driver-specific bits. In essence, they've returned to the old model of a separate compositor and display server in separate processes, just with a slightly different division of responsibilities. (Except that the major session compositors are expected to access the driver-specific APIs directly. So both the session compositor and system compositor will wind up containing a bunch of duplicated graphics driver-specific code.)

    Originally posted by dee. View Post
    Even with all the variation in Linux distributions, developers have always been able to count on a common display server, X, and assume it to be used on any distro. With Wayland, the transition would have been painless, since Wayland would have provided XWayland, and developers could depend on the existence of either X or Wayland.
    XWayland doesn't actually work properly. When people complain about it being so broken it makes Wayland unusable, they get accused of spreading FUD on the front page of Phoronix because it's officially not part of Wayland; same with any of the other essential parts of the Wayland stack like rendering libraries for clients. Wayland is small in the sense that almost everything is someone else's problem and officially not their fault.

    Actually, I'm not convinced XWayland can ever work properly with all applications. Quoting from another front-page article here: "Once XWayland is finalized and merged we should have more-or-less perfect backwards compatibility because every X app just gets its own mini X-server to deal with. There is one known snag and thats with window transformations because app thinks its in the top right corner of the screen (yay global coordinates) because that client's X server is locked to the size of that client's window." What happens when an app has multiple top-level windows that are related in space? (I doubt Wine will ever work reliably under Wayland except in virtual-desktop mode either; Windows apps expect to know their window's global coordinates and that's intentionally impossible under Wayland.)

    Leave a comment:


  • chrisb
    replied
    Originally posted by RahulSundaram View Post
    It is funny how you expect everyone else to spell out every single factor without any real understanding of what you are talking about. Have you wondered why Canonical choose to use GPLv3 and insists on a CLA for Mir? Do you have a good explanation of why Mir even exists? Matthew Garett isn't merely a software engineer but a Linux kernel developer and licensing expert. I will defer to his analysis over your non existest one. Sorry if that offends your sensibilities.
    Your inability to explain your own position and your tendency to hurl insults at anyone who questions that position do not reflect well on you.

    Leave a comment:


  • chrisb
    replied
    Originally posted by mrugiero View Post
    Answer: it has nothing to do with the kernel, actually. The user space driver targets the display system, not the kernel. In desktop Linux it's MIT, so they can do whatever they want. On Ubuntu based devices, it will be Mir, which is GPLv3 with exceptions when Canonical explicitly authorizes them. GPLv3 prevents you from locking your device, MIT does not.
    If the user space driver requires a kernel shim that exposes custom syscalls then it has a lot to do with the kernel, and there are kernel developers who believe this to be a GPL violation:

    The fact that user-space code is at issue is also significant. The COPYING file shipped with the kernel begins with this text:

    NOTE! This copyright does *not* cover user programs that use kernel services by normal system calls - this is merely considered normal use of the kernel, and does *not* fall under the heading of "derived work".
    Normally, kernel developers see user space as a different world with its own rules; it is not at all common for kernel maintainers to insist on free licensing for user-space components. Dave's raising of licensing issues might also seem, on its face, to run counter to the above text: he is saying explicitly that closed user-space graphics drivers might be a work derived from the kernel and, thus, a violation of the GPL. These claims merit some attention.

    The key text above is "normal system calls." A user-space graphics driver does not communicate with its kernel counterpart with normal system calls; it will use, instead, a set of complex operations which exist only to support that particular chipset. The kernel ABI for graphics drivers is not a narrow or general-purpose interface. The two sides are tightly coupled, a fact which has made the definition of the interface between them into a difficult task - and the maintenance of it almost as hard. While a program using POSIX system calls is clearly not derived from the kernel, the situation with a user-space graphics driver is not nearly so clear

    Leave a comment:


  • MWisBest
    replied
    By contrast, those same outraged individuals have NIH?d just about every important piece of the stack they can get their hands on? most notably SystemD, which is hugely invasive and hardly justified. What closely to see how competitors to Canonical torture the English language in their efforts to justify how those toolkits should support Windows but not Mir. But we?ll get it done, and it will be amazing.
    Speaking of torturing the English language, jeeeeeeeeeeeeeeeeeez.

    Anyways... long-live Wayland! Down with Mir! Rah Rah Rah! :P

    Leave a comment:


  • mrugiero
    replied
    Originally posted by chrisb View Post
    Are you suggesting that your legal arguments are only correct in the context of ARM architecture, and are incorrect on others? Please clarify:

    Do you believe an OEM using the Nvidia or AMD closed source drivers (which both have closed source kernel modules) on a desktop is a violation of the GPL license of the Linux kernel? If not, then why would introducing a GPL display server suddenly create a GPL violation?

    Do you believe an OEM using the Nvidia or AMD closed source drivers on an embedded system like the Steam Box is a violation of the GPL license of the Linux kernel? If not, then why would introducing a GPL display server suddenly create a GPL violation?

    Do you believe an OEM using open source kernel drivers and closed source user space drivers on an ARM tablet is a violation of the GPL license of the Linux kernel? If not, do you believe that a simple kernel shim is enough to protect a driver from being a derivative work, even though that shim exposes complex kernel functionality? Do you believe that introducing a GPL display server would suddenly create a GPL violation, merely because the GPU driver runs in user space? Is this a situation analogous to the one quoted by Torvalds - where he does not believe that an independently developed GPU driver running in kernel space is a derivative work? Do you believe that an independently developed GPU driver running in user space forms a derivative work with the display server? Even though Torvalds explicitly stated that the equivalent running in kernel space does not form a derivative work - when in user space it suddenly becomes a derivative work?
    Answer: it has nothing to do with the kernel, actually. The user space driver targets the display system, not the kernel. In desktop Linux it's MIT, so they can do whatever they want. On Ubuntu based devices, it will be Mir, which is GPLv3 with exceptions when Canonical explicitly authorizes them. GPLv3 prevents you from locking your device, MIT does not.

    Leave a comment:


  • RahulSundaram
    replied
    Originally posted by chrisb View Post
    I said it was flawed, not incorrect. There is a difference. Your "explanation" consisted of the single claim that the analysis applied to the ARM architecture, when the actual blog doesn't mention ARM at all. When asked to clarify your claims, you either can't or refuse. You keep citing a blog post written by a software engineer as though it's the gospel truth when it comes to legal questions, but then refuse to answer questions about it. Don't you see the contradiction between quoting a software engineer's blog as an authoratative source, and telling people not to play internet lawyer? If you understand the argument, then answer the questions. If you don't understand the argument, then stop pretending that you do.
    It is funny how you expect everyone else to spell out every single factor without any real understanding of what you are talking about. Have you wondered why Canonical choose to use GPLv3 and insists on a CLA for Mir? Do you have a good explanation of why Mir even exists? Matthew Garett isn't merely a software engineer but a Linux kernel developer and licensing expert. I will defer to his analysis over your non existest one. Sorry if that offends your sensibilities.

    Leave a comment:


  • chrisb
    replied
    Originally posted by RahulSundaram View Post
    Not true. You claimed that Matthew's analysis is incorrect when I tried to explain it to you and gave you the link. He has the direct expertise which you clearly don't. End of argument.
    I said it was flawed, not incorrect. There is a difference. Your "explanation" consisted of the single claim that the analysis applied to the ARM architecture, when the actual blog doesn't mention ARM at all. When asked to clarify your claims, you either can't or refuse. You keep citing a blog post written by a software engineer as though it's the gospel truth when it comes to legal questions, but then refuse to answer questions about it. Don't you see the contradiction between quoting a software engineer's blog as an authoratative source, and telling people not to play internet lawyer? If you understand the argument, then answer the questions. If you don't understand the argument, then stop pretending that you do.

    Leave a comment:


  • RahulSundaram
    replied
    Originally posted by chrisb View Post
    Please show me where I said that I "know better than people who have worked on such systems and have defended the license in actual court cases"? I merely asked you to clarify your argument.
    Not true. You claimed that Matthew's analysis is incorrect when I tried to explain it to you and gave you the link. He has the direct expertise which you clearly don't. End of argument.

    Leave a comment:

Working...
X