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.
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.)
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.
>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.
> 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.
>There is no relation between open-source licensing or culture and careless breakage.
There is no relation between open-source licensing or culture and working software either. Go take a look around on github and you will see tons of broken, outdated and unmaintained software. (I am not saying there is anything wrong with this, eventual death is a fundamental part of any product lifecycle)
>I doubt anyone has actually set up a system with sandboxed untrusted processes in a way that would justify the Wayland security model.
I said "a system", making a sandboxing program like Flatpak is the easy part. Also, why is it that neither https://flatpak.org nor https://github.com/flatpak/flatpak mention security or "secure"? I think that is because Flatpak is not meant for running untrusted/malicious processes (without using additional protection; such as a virtual machine, another OS user, or another physical machine). I am not sure why that is, but it may be because, as I said, it is simply too complicated to think through everything while satisfying relevant security models, or because Flatpak programmers know that for real security you do not want user namespaces in your Linux (attack surface increase, etc.).
Also, even if Flatpak and the kernel were perfect, if you want to sandbox a complex application with only Flatpak; using the app and configuring its sandbox would then be an impractical nightmare for either administrators or users. See the article linked here about the problems with Flatpak-sandboxing complex real-world programs: https://news.ycombinator.com/item?id=18180017.
Basically, for real secure and robust sandboxing I think one needs to use the Chromium setuid + seccomp + multiple processes approach. This implies thinking about security while designing the program, and it being open-source; so it is only applicable to trusted software that deals with untrusted data, or executes Javascript or something. So, if a program is designed with security in mind (e.g., Chromium), Flatpak provides nothing beneficial. On the other hand, if one needs to execute real-world untrusted software, it again seems it is necessary to use another user account or another machine.
Sandboxing is part of an overall security solution and also has other uses besides security. And as you know there are many other parts to securing your system. Of course if you already implement sandboxing yourself then you probably don't need to use Flatpak to make security guarantees.
I think you have made a lot of wild assumptions from reading those posts you linked, and those assumptions don't apply to everyone. Regardless of your feelings on Flatpak/Wayland in certain applications, they are being used for security purposes right now. The Chromium security model also makes a lot of assumptions and only applies to certain applications.
