2 ms·

Is there some other explanation that would please you? I am trying to parse that GP post for an argument and I can't find one. Your old drivers are all still th

Is there some other explanation that would please you? I am trying to parse that GP post for an argument and I can't find one. Your old drivers are all still there, they're not going away. You can continue using them but it would be wise to remain aware of the associated caveats, in this case, that the synaptics driver is unmaintained, hard to test, and is at a large risk of having regressions introduced after any changes.

nsajko 6y ago
There is a pattern of deprecating working software and trying to replace it with experimental stuff, with the design of that experimental stuff often being oriented largely toward less-technical users, with some detriment to old/power users and the ecosystem in general. For example, Wayland compositors, unlike X Windows window managers, are complicated to implement and on top of that the Wayland protocol standardizes little. This hurts the Wayland compositor ecosystem (again, as compared to X Window managers), and the lack of standardization hurts users directly, too (because then we have to rely on compositor-specific features, thus being tied to that compositor implementation). Last time I looked there still was not any prevalent solution to injecting or logging input events, and even capturing the screen (screen shot) was dependent on the specific compositor implementation. Remember the excuse for ditching X Windows? It was X having too many extensions to the standard. But even that is better than not standardizing on expected features at all. (I know the Wayland folks excuse a lot of that stuff with "security", but that is just security theater as their security model does not makes sense. If two Linux processes are owned by the same user there is no point in restricting what one can know about the other.) EDIT3: also see the section on this ArchWiki page: https://wiki.archlinux.org/index.php/Wayland#Input_grabbing_in_games,_remote_desktop_and_VM_windows https://wiki.archlinux.org/index.php/Wayland#Input_grabbing_... Edit: also, even breakage for users that can be fixed by adapting to the next technology (e.g., evdev -> libinput, or X Windows -> Wayland) still costs users time. EDIT4: Note that I am not saying X Windows is "good", but the fact is Wayland's design is hostile to a lot of things that work with X Windows, instead of Wayland improving on X Windows. So how could I be content with Wayland possibly replacing Xorg? Hutterer is surely not some evil genius nor is he part of a conspiracy; but I think that Red Hat's (or, now, IBM's) business model indeed may present some adverse incentives to software maintainers: I think Red Hat's main source of revenue is from support, but they deal in open-source software - which should be (in principle), and actually is, much easier to modify, adapt, fork, just plain use without paying Red Hat. Thus it it is necessary to have almost all relevant software maintainers on your payroll, but that is not enough, to protect their business their software needs to be "safe" from forks, that means making it unnecessarily (from a technical standpoint) complicated and reinventing everything so only your employees are familiar with the code. I am sure Red Hat employees would let the technical and power user perspective prevail given a sufficient and independent cash source, but alas, they are in IBM's employ and don't want to get fired and do want a periodical raise; so it is hard for me to believe that they don't do what is good for their employer's business. I am not comfortable airing speculation like this given that some people will feel hurt, but I am in real fear for open-source and Linux (because, what could I use instead ...), so there's my opinion. EDIT5: my child commenter correctly pointed out that my speculation about programmers employed at companies with certain business models is FUD-y, because of the lack of evidence and appeal to fear. I guess the only thing I can say about that is that my fears are honest, I am not aiming to harm Red Hat or anybody I just observed a pattern, but have no proof, of course. Otherwise, aside from my "FUD", the core idea I was trying to get across was to think about how the design choices in creating open-source software or protocols that have the potential to become monopolistic may affect us as users. I.e., please do not accept breakage just because of some undefined "modernity", as a lot of people in fact do. Also, I think there may be some systemic societal problems that I am not smart enough to propose a solution to if Red Hat is really bad for open-source. In other words, maybe another open-source business model is needed? EDIT2: I rambled too far off the primary topic here (libinput), so let me just say that libinput very well might be the best we can have given the requirement to support both mices and other, less efficient, input devices; and also both X Windows and Wayland. Not that I'm happy about those requirements, obviously.
- cycloptic 6y ago
  >There is a pattern of deprecating working software and trying to replace it with experimental stuff This is par for the course. Open source does not have any warranty, it can break or be deprecated at any time. I don't care to discuss Wayland right now, if you don't want to use it you don't have to. >If two Linux processes are owned by the same user there is no point in restricting what one can know about the other. This is wrong on several levels. For example, namespacing and SELinux policies still work even when processes share the same user, and there are valid reasons why you would want to do that. >I am not comfortable airing speculation like this given that some people will feel hurt, but I am in real fear for open-source and Linux Please do not allow yourself to succumb to FUD that is spread on social media. This type of speculation comes up constantly in these threads and it's completely unfounded. Sorry. It's open source, anyone can pay for support/warranties for it from any company that they like, or you can not pay for support from anyone at all. It's your decision.
  - nsajko 6y ago
    > This is par for the course. Open source does not have any warranty, it can break or be deprecated at any time. I don't care to discuss Wayland right now, if you don't want to use it you don't have to. There is no relation between open-source licensing or culture and careless breakage. Even if there was, what would be the justification for it (Red Hat's behavior). > This is wrong on several levels. For example, namespacing and SELinux policies still work even when processes share the same user, and there are valid reasons why you would want to do that. I know about cgroups, namespacing, SELinux and how they could hypothetically provide other means of privilege separation than users and groups already provide; but I don't see how that applies to Wayland. I doubt anyone has actually set up a system with sandboxed untrusted processes in a way that would justify the Wayland security model. The way I see it, Wayland will over time gain even more extension protocols than X Windows has to accomodate things that were not thought out during the design phase. I also doubt the user namespace implementation in the kernel will be solid enough for secure usage for many years. Or that compositor and application programmers will understand the security implications of their software on the possible security models well enough for users to actually have a usable and feature-complete system where the Wayland-implied security model could shine.

nsajko 6y ago

There is a pattern of deprecating working software and trying to replace it with experimental stuff, with the design of that experimental stuff often being oriented largely toward less-technical users, with some detriment to old/power users and the ecosystem in general. For example, Wayland compositors, unlike X Windows window managers, are complicated to implement and on top of that the Wayland protocol standardizes little. This hurts the Wayland compositor ecosystem (again, as compared to X Window managers), and the lack of standardization hurts users directly, too (because then we have to rely on compositor-specific features, thus being tied to that compositor implementation). Last time I looked there still was not any prevalent solution to injecting or logging input events, and even capturing the screen (screen shot) was dependent on the specific compositor implementation. Remember the excuse for ditching X Windows? It was X having too many extensions to the standard. But even that is better than not standardizing on expected features at all. (I know the Wayland folks excuse a lot of that stuff with "security", but that is just security theater as their security model does not makes sense. If two Linux processes are owned by the same user there is no point in restricting what one can know about the other.) EDIT3: also see the section on this ArchWiki page: https://wiki.archlinux.org/index.php/Wayland#Input_grabbing_in_games,_remote_desktop_and_VM_windows https://wiki.archlinux.org/index.php/Wayland#Input_grabbing_... Edit: also, even breakage for users that can be fixed by adapting to the next technology (e.g., evdev -> libinput, or X Windows -> Wayland) still costs users time. EDIT4: Note that I am not saying X Windows is "good", but the fact is Wayland's design is hostile to a lot of things that work with X Windows, instead of Wayland improving on X Windows. So how could I be content with Wayland possibly replacing Xorg? Hutterer is surely not some evil genius nor is he part of a conspiracy; but I think that Red Hat's (or, now, IBM's) business model indeed may present some adverse incentives to software maintainers: I think Red Hat's main source of revenue is from support, but they deal in open-source software - which should be (in principle), and actually is, much easier to modify, adapt, fork, just plain use without paying Red Hat. Thus it it is necessary to have almost all relevant software maintainers on your payroll, but that is not enough, to protect their business their software needs to be "safe" from forks, that means making it unnecessarily (from a technical standpoint) complicated and reinventing everything so only your employees are familiar with the code. I am sure Red Hat employees would let the technical and power user perspective prevail given a sufficient and independent cash source, but alas, they are in IBM's employ and don't want to get fired and do want a periodical raise; so it is hard for me to believe that they don't do what is good for their employer's business. I am not comfortable airing speculation like this given that some people will feel hurt, but I am in real fear for open-source and Linux (because, what could I use instead ...), so there's my opinion. EDIT5: my child commenter correctly pointed out that my speculation about programmers employed at companies with certain business models is FUD-y, because of the lack of evidence and appeal to fear. I guess the only thing I can say about that is that my fears are honest, I am not aiming to harm Red Hat or anybody I just observed a pattern, but have no proof, of course. Otherwise, aside from my "FUD", the core idea I was trying to get across was to think about how the design choices in creating open-source software or protocols that have the potential to become monopolistic may affect us as users. I.e., please do not accept breakage just because of some undefined "modernity", as a lot of people in fact do. Also, I think there may be some systemic societal problems that I am not smart enough to propose a solution to if Red Hat is really bad for open-source. In other words, maybe another open-source business model is needed? EDIT2: I rambled too far off the primary topic here (libinput), so let me just say that libinput very well might be the best we can have given the requirement to support both mices and other, less efficient, input devices; and also both X Windows and Wayland. Not that I'm happy about those requirements, obviously.

cycloptic 6y ago
>There is a pattern of deprecating working software and trying to replace it with experimental stuff This is par for the course. Open source does not have any warranty, it can break or be deprecated at any time. I don't care to discuss Wayland right now, if you don't want to use it you don't have to. >If two Linux processes are owned by the same user there is no point in restricting what one can know about the other. This is wrong on several levels. For example, namespacing and SELinux policies still work even when processes share the same user, and there are valid reasons why you would want to do that. >I am not comfortable airing speculation like this given that some people will feel hurt, but I am in real fear for open-source and Linux Please do not allow yourself to succumb to FUD that is spread on social media. This type of speculation comes up constantly in these threads and it's completely unfounded. Sorry. It's open source, anyone can pay for support/warranties for it from any company that they like, or you can not pay for support from anyone at all. It's your decision.
- nsajko 6y ago
  > This is par for the course. Open source does not have any warranty, it can break or be deprecated at any time. I don't care to discuss Wayland right now, if you don't want to use it you don't have to. There is no relation between open-source licensing or culture and careless breakage. Even if there was, what would be the justification for it (Red Hat's behavior). > This is wrong on several levels. For example, namespacing and SELinux policies still work even when processes share the same user, and there are valid reasons why you would want to do that. I know about cgroups, namespacing, SELinux and how they could hypothetically provide other means of privilege separation than users and groups already provide; but I don't see how that applies to Wayland. I doubt anyone has actually set up a system with sandboxed untrusted processes in a way that would justify the Wayland security model. The way I see it, Wayland will over time gain even more extension protocols than X Windows has to accomodate things that were not thought out during the design phase. I also doubt the user namespace implementation in the kernel will be solid enough for secure usage for many years. Or that compositor and application programmers will understand the security implications of their software on the possible security models well enough for users to actually have a usable and feature-complete system where the Wayland-implied security model could shine.