5 ms·

This! X11 "synaptics" driver seems to be very high quality already. Personally I really like the great amount parameters that can be tuned. Why do we need jet a

by sprash 6y ago

This! X11 "synaptics" driver seems to be very high quality already. Personally I really like the great amount parameters that can be tuned. Why do we need jet another duplicated effort like libinput?

wott 6y ago
> Why do we need jet another duplicated effort like libinput? That's the mentality of the Freedesktop-Redhat-Gnome-Poettering-Wayland-whichever-comes-next crowd. Take a piece of software that's been working for years and fulfils pretty much every need (after a couple of decades of bug fixing and feature completing), declare it deprecated, and propose/impose a replacement that you push as 'better'. Better for what, in which way? It doesn't matter, just say it is 'modern' and the present system if a messy pile of cruft. Don't forget to make 1 or 2 blog posts which will be pasted as the definitive authoritative reference on the subject each of the 1000 time someone raises a problem with the new tool or its approach. If you want to make the tactic more efficient, first become the handler of the present system and then 'actively' stop maintaining it and refuse to add the few features that new usages may demand, so that that you can justify your claim of deprecation. Then you just have to spend 10 to 15 years getting your brand new toy to an equal condition as the former, and achieve feature parity. When you are done, the super lean and clean model you advertised 10 years before has become the same kind of old farts' mess you ranted against, sometimes more messy because you started by actively fighting against the extensibility which, according to you, was the root of all the mess in the older tool, in order to impose a clean, reduced set of functions, so you had to resort to dirty hacks to add the requested functions. After boasting the first couple of years from conference to conference, don't forget to whine all along the next decade when real and boring work and rework has to be done to reach feature parity. Then, you're finally done, pick another part of the ecosystem (that users had voluntarily picked because they like it or because it was doing the job well for their use case) and repeat the same procedure.
- tannhaeuser 6y ago
  I believe libinput's and synaptic's maintainer is the same person, and he started libinput because the synaptic codebase was a mess without tests whatsoever. I'm also using synaptics btw, as libinput gives me physical pain ...
  - nsajko 6y ago
    What your saying is consistent with your parent's hypothesis. Compare GP's > declare it deprecated, and propose/impose a replacement that you push as 'better'. Better for what, in which way? It doesn't matter, just say it is 'modern' and the present system if a messy pile of cruft. with your's > the synaptic codebase was a mess without tests whatsoever
    - cycloptic 6y ago
      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.
- nsajko 6y ago
  A pattern definitely appears to exist ;) People complain about Systemd the most; but I fear Wayland more, it will be horrible for power-users if it pushes out X Windows.
  - RMPR 6y ago
    Care to explain why you think so?
    - nsajko 6y ago
      Wayland is trouble for users who * do not want just the big Windows-like inefficient and bloated Gnome and KDE desktop environments. And also for those that like or need having various "desktop environments" to switch between. * like to programmatically grab and inject input events. I.e., AFAIK you will not be able to implement atbswp for Wayland environments using pure Wayland, if at all. Even if you do succeed (by depending on a Wayland extension, working with specific compositors or talking directly to the kernel), it will be more difficult than for X Windows. Quoting my comment from this thread, near yours: > 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. > 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? Also see these (sub)threads: https://old.reddit.com/r/wayland/comments/85q78y/why_im_not_going_to_switch_to_wayland_yet/ https://old.reddit.com/r/wayland/comments/85q78y/why_im_not_... https://news.ycombinator.com/item?id=20376316 https://news.ycombinator.com/item?id=20376316 https://news.ycombinator.com/item?id=20379423 https://news.ycombinator.com/item?id=20379423

by sprash 6y ago

This! X11 "synaptics" driver seems to be very high quality already. Personally I really like the great amount parameters that can be tuned. Why do we need jet another duplicated effort like libinput?

wott 6y ago

> Why do we need jet another duplicated effort like libinput? That's the mentality of the Freedesktop-Redhat-Gnome-Poettering-Wayland-whichever-comes-next crowd. Take a piece of software that's been working for years and fulfils pretty much every need (after a couple of decades of bug fixing and feature completing), declare it deprecated, and propose/impose a replacement that you push as 'better'. Better for what, in which way? It doesn't matter, just say it is 'modern' and the present system if a messy pile of cruft. Don't forget to make 1 or 2 blog posts which will be pasted as the definitive authoritative reference on the subject each of the 1000 time someone raises a problem with the new tool or its approach. If you want to make the tactic more efficient, first become the handler of the present system and then 'actively' stop maintaining it and refuse to add the few features that new usages may demand, so that that you can justify your claim of deprecation. Then you just have to spend 10 to 15 years getting your brand new toy to an equal condition as the former, and achieve feature parity. When you are done, the super lean and clean model you advertised 10 years before has become the same kind of old farts' mess you ranted against, sometimes more messy because you started by actively fighting against the extensibility which, according to you, was the root of all the mess in the older tool, in order to impose a clean, reduced set of functions, so you had to resort to dirty hacks to add the requested functions. After boasting the first couple of years from conference to conference, don't forget to whine all along the next decade when real and boring work and rework has to be done to reach feature parity. Then, you're finally done, pick another part of the ecosystem (that users had voluntarily picked because they like it or because it was doing the job well for their use case) and repeat the same procedure.

tannhaeuser 6y ago
I believe libinput's and synaptic's maintainer is the same person, and he started libinput because the synaptic codebase was a mess without tests whatsoever. I'm also using synaptics btw, as libinput gives me physical pain ...
- nsajko 6y ago
  What your saying is consistent with your parent's hypothesis. Compare GP's > declare it deprecated, and propose/impose a replacement that you push as 'better'. Better for what, in which way? It doesn't matter, just say it is 'modern' and the present system if a messy pile of cruft. with your's > the synaptic codebase was a mess without tests whatsoever
  - cycloptic 6y ago
    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.
nsajko 6y ago
A pattern definitely appears to exist ;) People complain about Systemd the most; but I fear Wayland more, it will be horrible for power-users if it pushes out X Windows.
- RMPR 6y ago
  Care to explain why you think so?
  - nsajko 6y ago
    Wayland is trouble for users who * do not want just the big Windows-like inefficient and bloated Gnome and KDE desktop environments. And also for those that like or need having various "desktop environments" to switch between. * like to programmatically grab and inject input events. I.e., AFAIK you will not be able to implement atbswp for Wayland environments using pure Wayland, if at all. Even if you do succeed (by depending on a Wayland extension, working with specific compositors or talking directly to the kernel), it will be more difficult than for X Windows. Quoting my comment from this thread, near yours: > 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. > 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? Also see these (sub)threads: https://old.reddit.com/r/wayland/comments/85q78y/why_im_not_going_to_switch_to_wayland_yet/ https://old.reddit.com/r/wayland/comments/85q78y/why_im_not_... https://news.ycombinator.com/item?id=20376316 https://news.ycombinator.com/item?id=20376316 https://news.ycombinator.com/item?id=20379423 https://news.ycombinator.com/item?id=20379423