Libre office is not a Linux problem. Direct that to the correct dev team and not towards Linux.
A modified form of the "It's Just A Kernel!" argument, which, as ever, is irrelevant. It doesn't
matter whether or not it's "part of Linux," it's what Linux users are stuck with. Even if LibreOffice isn't part of Linux per se, it's one of the only alternatives Linux users have to MS Office, and the one most frequently put forward by the Linux community, and it does not cut the mustard - just like the GIMP, just like tons of other shoddily-designed Linux software that the Linux developer community has gotten to a point of "basically feature-complete" and then dropped in the laps of prospective users, because they know Linux needs to have it to draw in users but they don't think it needs to be
good, because in the world of Linux the users exist for the benefit of the OS and not the other way around.
Your link doesn't work. Fix it, I'm interested in reading it. Some people don't have the aptitude or willingness to learn something new and stick with the simplest, no matter how archaic.
Or, alternatively, some people don't have any patience for putting up with pointless bullshít when there's other alternatives out there that don't demand that of them.
Really? That's definitely incorrect. The only somewhat difficult UI issues I've read or seen is when users try to install a different window manager like Enlightenment or whatever isn't a default wm like Gnome 2/3 etc.
If you haven't seen people having serious issues with Linux, you haven't looked. There are plenty of widely-recognized issues with Linux UI, and they all spring from the same ultimate source:
1. XWindows only handles low-level drawing.
2. Since XWindows only handles low-level drawing, toolkits have to be developed to display UI components and handle user interaction with them.
3. Anytime toolkits have to be developed, the Linux developer community will come up with at least three mutually-incompatible toolkits to accomplish the exact same thing.
4. Since there are at least three toolkits that do the same thing, the odds of any two applications using the same toolkit are no better than 33%.
5. Since the problem encompasses not merely two applications, but dozens or hundreds, since many other aspects of UI rely not on the toolkit, but on the programmer, and since most programmers don't actually care about UI at all except in that it gets people to use the cool backend code they wrote,
6. basically nothing behaves consistently with anything else. Except when you use one of the overblown multi-application suites developed to address this, in which case there's still plenty of bad design decisions and you lose the consistency anyway when you inevitably need an application that isn't part of the suite.
You can argue all you like that you don't notice this, but that won't change the fact that it's an issue for people who haven't spent twenty years forcibly acclimating themselves to bad UI.
