Its probably also because people are motivated to help out when they see work to be done. For me, my mouse and trackpad work just fine. I don't even know what I could work on with such a project. It all just works.
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.
> 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
EDIT3: also see the section on this ArchWiki page: 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.
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.
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 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.
There already is one, called Flatpak.
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.
And this comment is also informative: https://news.ycombinator.com/item?id=14409234
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.
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.
People complain about Systemd the most; but I fear Wayland more, it will be horrible for power-users if it pushes out X Windows.
* 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_...
It's here: https://web.archive.org/web/20101222190833/http://www.micros...
It is annoying in other OSes that you have to jump through hoops to disable that stuff.
I would argue that it does enhance the precision if it's correctly implemented. (I haven't used Windows in a decade, so I can't comment on that point.)
Example: on a laptop, move the cursor to the bottom left corner of the screen. In one very slow continuous swipe, drag your finger from the bottom left to the top right of your touchpad. How far across your screen do you get? In my case, I get only about 1/3 of the way across the diagonal.
Assume I have no acceleration feature on my touchpad driver. This means I have two options to make the touchpad usable. Either (a) I can get used to dragging across the entire touchpad 3+ times to get the cursor across the screen, or (b) I can turn the touchpad speed way up. Suppose I do the latter.
Now suppose my cursor is 10px away from some target and I want to hit that target with a quick movement on the touchpad. Because of the very high speed required by the previous change, my accuracy is greatly reduced. I have trouble hitting small targets with tiny movements on the touchpad.
On the contrary, acceleration gets me the best of both worlds. With one quick swipe, I can get the cursor all the way across the screen. This is the "expected" behavior most people have for a laptop the first time they pick it up. On the other hand, when I'm trying to hit a small target with a slow cursor movement, I have a much easier time doing that. This feels like "enhanced precision" to your average user - the cursor moves more slowly and accurately when I need it to.
Different input modalities deserve different affordances.
Apple’s Magic Trackpad is over 6 inch, the latest MacBooks have a trackpad of over 5 inch.
I think mousepads are mostly an artifact of pre optical & laser mice, if someone uses one today it's either because they have a glass desktop or they want wrist support.
Or they just want a good surface where the mouse glides smoothly, without any rubbing or scraping or pits that affect tracking..
I've never had a desk that felt good without a pad. I imagine glass would be smooth as long as it's clean.
Even the original Mac, with its 512 pixel screen width, had a setting that enabled mouse acceleration (fairly rudimentary. It doubled distance travelled when the sum of horizontal and vertical displacement exceeded 6 pixels).
I think the discussion is more about tuning the acceleration curve than about whether to have one or not, for both mice and trackpads. There probably isn’t a single answer that suits everybody, either.
Acceleration works much better on trackpads though.
1:1 is all I ever wanted.
Now I’ve just gone over to Apple’s trackpads for 100% of my cursor needs.
[1] http://download.microsoft.com/download/B/1/0/B109F931-70E2-4...
Apple is very opinionated about all the parts of User Interfaces (including inputs), it's great if you agree with their opinions.
https://downloads.steelseriescdn.com/drivers/tools/steelseri...
The trackpad, it's the opposite.
Years ago I had this argument with a coworker, and I tried to take the position that the Windows curve is better for games. He politely disagreed, I implied that he was a casual gamer, and he gently told me of the year his Quake III team won the world championship. We spent the next while watching demo videos of him doing 360 noscopes with the rail gun against a target in the air.
I handily lost that disagreement.
(I think libinput breaks that -- or at some point did break it -- and I solve it by removing libinput. Coincidentally, I started having issues with my trackpad when someone somewhere made libinput the new default. I fixed that by removing libinput)
Is there something else you'd like to see?
I have never even noticed a difference, let alone registered a preference.