back
1 comments
I noticed that (that's the "Summary" I mentioned).

But reading it after the very long text about individual bugs is much less useful. Most position/research papers put the executive summary/abstract first with good reason - that helps the paper be better received. Maybe even organizing the lists as collapsible items could help the presentation be better* .

As for the summary list, it too can benefit from a more probing look which tries to look at the issue more deeply, much more than listing individual issues. For example, ABIs and APIs are often unstable on purpose, especially on the kernel. Linus has long arguments supporting the unstable model and some Free software proponents like that this encourages GPL code.

Do we want the Windows model? Maybe a shim could supply that? Or maybe we shouldn't have even that due to Free software reasons? (RMS tried that which gcc and it was one of the reasons that led to LLVM gaining traction). Or development speed?

* That doesn't require JavaScript. One could use HTML5's simple summary/detail elements.

https://developer.mozilla.org/en-US/docs/Web/HTML/Element/de...

There are css hacks which can achieve the same result on HTML4, but they are much more complicated and I suspect a list on Linux issues shouldn't care about supporting Internet Explorer.

The article was meant to be read in full.

Yeah, the modern generation of people is mostly capable of consuming 140/280 chars tweets and has severe issues with the attention span but if you're wanna get deep into it, you'll read it all. Or just dismiss everything because you didn't like how the article is organized - that'll work as well, as it has for the past 30 years which means Linux on the desktop will remain a hobby OS for geeks.

Your tone is unwarranted.

I did not dismiss anything. Nor did I ask you to remove any information. I merely wished you'd organize it in a better way.

The better way IMHO is to emphasize the structural economical/sociological/technical reasons. Why? Because even fixing all the small technical bugs in that long list would help only for a little while.

For example, if Linux Desktop somehow got to magically all items fixed case, it is way underfunded. So it will either stagnate in place or try to innovate and introduce new bugs... On the other hand, find a workable revenue model, and then devs would be paid to fix bugs, and that would be sustainable.

Another example, fixing current NVidia incompatibilities would help, but the unstable Linux ABI/API would remain, and that would cause issues in the future with any other future NVidia or other manufacturer which balk at putting their code under OSS. This issue needs a decision which balances all the competing interests.

> Why? Because even fixing all the small technical bugs in that long list would help only for a little while.

Totally agree with that.

> For example, if Linux Desktop somehow got to magically all items fixed case, it is way underfunded.

Kinda disagree with "the underfunded" part. The biggest issue with Linux is that it's not a platform like Windows, Android, iOS, etc. All of them feature

1) Rich stable APIs/ABIs, including for device drivers 2) Strong backward and forward compatibility 3) Strong cohesion between system components (e.g. kernel and userspace) 4) Excellent support for hardware 5) Universal packaging mechanism (the same 'exe' can be installed on any supported version of Windows/MS-DOS/OS/2, the same APK can be installed on any supported version of Android)

(See the Solving Linux part of the article).

There's just one distro which ticks almost all the checkboxes and that's RHEL and it's not exactly meant to be used on the desktop. Besides its hardware support leaves a lot to be desired as RedHat sticks to the same kernel release for all the support period (10 years or something) and regularly backports only certain drivers from mainline.

If someone created a Linux platform, even with the same number of bugs/missing features that we already have and it would still be a hundred times more successful than Linux has ever been.