Major Linux Problems on the Desktop, 2016 Edition

Also, are you using the closed-source or the open-source ATI drivers?

And, are you using Ubuntu, or are you using some other distro? (My experience with non-LTS Ubuntu has been... substantially less than stellar over the past several years.)

One of the biggest issues for me personally is the split effort. There are >300 distributions actively maintained, 300 projects whose sole purpose it is to package the kernel and some userland-stuff to make a usable operating system and provide for update mechanisms. 300 projects who spend resources on creating documentation, websites, giving support to users, ...

And the simple truth is: It does not matter too much which distribution you use, far too much weight is put on that. How much of what you do is distribution-specific? The type of init-system (mostly not important for a Desktop), the update mechanism, packages available, available/supported Desktop Environments / Window Managers, anything I forgot?

Most of the time you are running a browser, editor, terminal, video player, torrent client, openssh, steam, are using some version of python, ruby, perl, php, ... it quite simply does not matter whether you do these things on Fedora, Ubuntu, openSUSE, ArchLinux, Gentoo or FreeBSD.

Linus Torvalds described it in a similar manner once (too lazy to look for the link, but basically something like "I don't care too much about what distribution I use, I mainly work on the kernel anyways")

We are users, as such we use an Operating System in order to use programs.

The fragmentation probably mostly is rooted in the fact that it is quite easy to create your own distribution, and that many out there are head-strong people who are not patient enough to work their way up a command chain (regarding distributions with a democratic structure) or to succumb to what one dictator is saying. And some projects are just boring to work on, for example GUI-stuff or the code-monster Xorg.

I would not want to bundle all 300 distributions into 1, but (and this of course boils down to my opinion) 20 or so would do. It is important to have alternatives, like non-systemd distributions, rolling releases, source-based distributions, et cetera, but 300...

And if the focus is less on having 300+ distributions and more on making 20 or so distributions great, quality would rise without a doubt, not only ease of use, but also support, documentation, et cetera.

btw: Visited this page from Firefox, was greeted by the following:

Reported Web Forgery!

This web page at linuxfonts.narod.ru has been reported as a web forgery and has been blocked based on your security preferences.

Web forgeries are designed to trick you into revealing personal or financial information by imitating sources you may trust.

Entering any information on this web page may result in identity theft or other fraud.

I'm glad they were sufficiently pushed to eventually start thinking about remoting.

I get that X protocol was not that good -- but I'm still not convinced that their model is, not even talking about future proof, suitable for present needs; you have to at least provision for multi-dpi, touch and changing form-factors; you also have to provision for multi-gpu more seriously (his answer: client pb and very difficult) and multimedia (sound synchro, ideally including in remoting cases).

I'm also not 100% convinced that the argument that gedit round-trips too much is a good one. You have to rewrite toolkit to use Wayland anyway, so why not comparing that approach to a mere cleanup of the way they use X?

And to finish, you will still need quasi perfect retro-compatibility with X for lots of users.

So if eventually all of that is handled properly, why not, and given how he said they orient the protocol descriptively more than imperatively this is possible that this can be added in a second time without falling again in X situation full of workarounds, but even in this best case scenario it will still be very late to the party, especially if they feel so much in the mood of stuffs like touchpad driver rewrite (why is that not in a common lower layer anyway?...). And even then, this will only go as far as the client who render every pixel will be able to do anyway... I get that this is more or less what is largely already done anyway by some software, but guess what else is also done today? Using X... so not a really good reason when you are already breaking everything anyway.

And also guess what a really efficient remote protocol focused on bitmaps would intrinsically be kind of equivalent to for a lot of use cases? Describing transformation operations on previous images already known by the server. There are tons of operations which today exists and that are reimplemented in web browsers as hacks of e.g. javascript and tilled jpegs; either future "display" stacks are powerful enough to model them efficiently, or we abandon all hopes and the native graphic stack should just be a glorified frame buffer and the real UI should be implemented in a browser -- after all, that's also what is partly already done!

Specs: http://www.gigabyte.com/products/product-page.aspx?pid=5157

Price: https://pcpartpicker.com/part/gigabyte-wireless-network-card...

It's basically an Intel 7260 Wireless-AC/Bluetooth chip plus a PCIe adapter.

That's the point -- developers can't test all possible hardware configurations and resulting driver mixes. Some of the most often used architectures and configurations usually work pretty well out of a box, but if you had something a little more exotic, prepare to get your hands dirty. Honestly, I don't see a solution to this problem, unless some "openness" is sacrificed by signing drivers (Microsoft style).