Check out our Monthly Survey Page to see what our users are running.
We do often include affiliate links to earn us some pennies. See more here.

The Linux market share appears to continue rising with Ubuntu winning

By - | Views: 46,245

Take it with your usual dose of salt and scepticism but when looking over the Linux market share, at least on NetMarketShare it appears to continue rising.

While the latest from the Steam Survey shows a dip during June, the opposite is true here. We reported last month that NetMarketShare was showing a clear upwards trend. The sort of thing you can easily write-off across one or two months but now three months in a row it gives it a bit more credit.

Going from 1.36% in March 2020, up to 2.87% in April, 3.17% in May and now June's figure is in with 3.61%. Looking over past figures from them, this might be the first time we've ever seen it rise three months in a row without a break. This is not counting Chrome OS either, like some other stats end up bundling with Linux. Chrome OS has stayed around ~0.40%, with Ubuntu over this period rising from 0.27% in March to 2.57% in June which is crazy.

Still not clear what's driving this big uptick in Ubuntu users on their statistics and we can speculate until the end of days, still interesting to see though and quite possibly as a result of people working from home during the COVID19 outbreak.

What are your thoughts?

Article taken from GamingOnLinux.com.
Tags: Editorial, Misc
33 Likes
About the author -
author picture
I am the owner of GamingOnLinux. After discovering Linux back in the days of Mandrake in 2003, I constantly came back to check on the progress of Linux until Ubuntu appeared on the scene and it helped me to really love it. You can reach me easily by emailing GamingOnLinux directly. Find me on Mastodon.
See more from me
The comments on this article are closed.
59 comments
Page: «5/6»
  Go to:

minkiu Jul 3, 2020
View PC info
  • Supporter
Quoting: DefaultX-od
Quoting: DefaultX-od
Quoting: Linas
Quoting: DefaultX-od
Quoting: TheRiddick3) Nvidia to offer Wayland support.
They are offering it, it's just none of DE willing to implement it
What do you mean? Is there something Nvidia-specific they need to implement?

EGLStreams

And you guys know what's the funniest thing? Windows 10 will soon have Wayland support in WSL2 no matter what GPU will be in use.

I don't have all the info/know the story, but I believe the whole linux ecosystem was pitching for GBM and nvidia just went their way with EGLStreams?
DefaultX-od Jul 3, 2020
Quoting: minkiu
Quoting: DefaultX-od
Quoting: DefaultX-od
Quoting: Linas
Quoting: DefaultX-od
Quoting: TheRiddick3) Nvidia to offer Wayland support.
They are offering it, it's just none of DE willing to implement it
What do you mean? Is there something Nvidia-specific they need to implement?

EGLStreams

And you guys know what's the funniest thing? Windows 10 will soon have Wayland support in WSL2 no matter what GPU will be in use.

I don't have all the info/know the story, but I believe the whole linux ecosystem was pitching for GBM and nvidia just went their way with EGLStreams?

Well here's what I found:

Nvidia dev says:

GBM - The current way used by Wayland compositors... It provides buffer allocation, arbitration, and handles. The "benefits" expressed is that it's already supported by many code-bases, is widely-deployed and tested, and ia a minimal API while supporting allocation-time usage specification. Current GBM shortcomings expressed in the presentation are process-local handles only, very GPU-focused, and arbitration is within device scope.

EGLStream - NVIDIA's current preferred method supports allocation, arbitration, handles, state management, and synchronization. It's viewed as being proven, portable, and comprehensive/extensive abilities. But viewed shortcomings of EGLStream are the open standard being implemented differently by vendors, there isn't cross-device support, it's based upon EGL, there is a lot of encapsulation, and the behavior can vary in some areas.

Original post at Phoronix:

https://www.phoronix.com/scan.php?page=news_item&px=XDC2016-Device-Memory-API


Last edited by DefaultX-od on 3 July 2020 at 1:28 pm UTC
Mohandevir Jul 3, 2020
Quoting: DefaultX-od
Quoting: minkiu
Quoting: DefaultX-od
Quoting: DefaultX-od
Quoting: Linas
Quoting: DefaultX-od
Quoting: TheRiddick3) Nvidia to offer Wayland support.
They are offering it, it's just none of DE willing to implement it
What do you mean? Is there something Nvidia-specific they need to implement?

EGLStreams

And you guys know what's the funniest thing? Windows 10 will soon have Wayland support in WSL2 no matter what GPU will be in use.

I don't have all the info/know the story, but I believe the whole linux ecosystem was pitching for GBM and nvidia just went their way with EGLStreams?

Well here's what I found:

Nvidia dev says:

GBM - The current way used by Wayland compositors... It provides buffer allocation, arbitration, and handles. The "benefits" expressed is that it's already supported by many code-bases, is widely-deployed and tested, and ia a minimal API while supporting allocation-time usage specification. Current GBM shortcomings expressed in the presentation are process-local handles only, very GPU-focused, and arbitration is within device scope.

EGLStream - NVIDIA's current preferred method supports allocation, arbitration, handles, state management, and synchronization. It's viewed as being proven, portable, and comprehensive/extensive abilities. But viewed shortcomings of EGLStream are the open standard being implemented differently by vendors, there isn't cross-device support, it's based upon EGL, there is a lot of encapsulation, and the behavior can vary in some areas.

Original post at Phoronix:

https://www.phoronix.com/scan.php?page=news_item&px=XDC2016-Device-Memory-API

QuoteWith those current "prior arts" from here, James Jones (NVIDIA) is hoping that the development community will ultimately devise a more optimal API that's minimal, portable, supports more than just GPUs, allows for optimal performance, handles driver-negotiated image capabilities, allows good performance, supports image layout transitions, and more. Again, while it's of concern to Wayland compositors and is the hot topic being debated right now since NVIDIA isn't supporting GBM, the hope is to make a much more universal and full-featured API to other clients / windowing systems. Obviously this isn't something that can be solved in one day, especially in trying to reach a consensus for a new, optimal API for device memory / surface allocation.

Hopefully there will ultimately be this new optimal API that's agreed upon -- and supported -- by all major vendors, but until then the Wayland compositor maintainers will still probably be focused on their GBM-only code-path. NVIDIA doesn't seem interested in budging right now on supporting GBM by their proprietary driver if it's only to be replaced in the (near?) future by a better surface allocation API and their interest in also seeing cross-platform support. Thus don't expect any miracles in the immediate future for the NVIDIA proprietary driver to work on the current-generation of Wayland compositors using GBM for their surface allocation. At least the XDC2016 feedback and comments so far have been productive and developers are open to discussing a new, better API.

Interresting read... So Nvidia thinks GBM too limited and decided to settle on EGLStream while waiting for a new and better API that didn't materialized, yet... Am I getting it right?
DefaultX-od Jul 3, 2020
Quoting: Mohandevir
Quoting: DefaultX-od
Quoting: minkiu
Quoting: DefaultX-od
Quoting: DefaultX-od
Quoting: Linas
Quoting: DefaultX-od
Quoting: TheRiddick3) Nvidia to offer Wayland support.
They are offering it, it's just none of DE willing to implement it
What do you mean? Is there something Nvidia-specific they need to implement?

EGLStreams

And you guys know what's the funniest thing? Windows 10 will soon have Wayland support in WSL2 no matter what GPU will be in use.

I don't have all the info/know the story, but I believe the whole linux ecosystem was pitching for GBM and nvidia just went their way with EGLStreams?

Well here's what I found:

Nvidia dev says:

GBM - The current way used by Wayland compositors... It provides buffer allocation, arbitration, and handles. The "benefits" expressed is that it's already supported by many code-bases, is widely-deployed and tested, and ia a minimal API while supporting allocation-time usage specification. Current GBM shortcomings expressed in the presentation are process-local handles only, very GPU-focused, and arbitration is within device scope.

EGLStream - NVIDIA's current preferred method supports allocation, arbitration, handles, state management, and synchronization. It's viewed as being proven, portable, and comprehensive/extensive abilities. But viewed shortcomings of EGLStream are the open standard being implemented differently by vendors, there isn't cross-device support, it's based upon EGL, there is a lot of encapsulation, and the behavior can vary in some areas.

Original post at Phoronix:

https://www.phoronix.com/scan.php?page=news_item&px=XDC2016-Device-Memory-API

QuoteWith those current "prior arts" from here, James Jones (NVIDIA) is hoping that the development community will ultimately devise a more optimal API that's minimal, portable, supports more than just GPUs, allows for optimal performance, handles driver-negotiated image capabilities, allows good performance, supports image layout transitions, and more. Again, while it's of concern to Wayland compositors and is the hot topic being debated right now since NVIDIA isn't supporting GBM, the hope is to make a much more universal and full-featured API to other clients / windowing systems. Obviously this isn't something that can be solved in one day, especially in trying to reach a consensus for a new, optimal API for device memory / surface allocation.

Hopefully there will ultimately be this new optimal API that's agreed upon -- and supported -- by all major vendors, but until then the Wayland compositor maintainers will still probably be focused on their GBM-only code-path. NVIDIA doesn't seem interested in budging right now on supporting GBM by their proprietary driver if it's only to be replaced in the (near?) future by a better surface allocation API and their interest in also seeing cross-platform support. Thus don't expect any miracles in the immediate future for the NVIDIA proprietary driver to work on the current-generation of Wayland compositors using GBM for their surface allocation. At least the XDC2016 feedback and comments so far have been productive and developers are open to discussing a new, better API.

Interresting read... So Nvidia thinks GBM too limited and decided to settle on EGLStream while waiting for a new and better API that didn't materialized, yet... Am I getting it right?

It's seems they are busy with this:

https://www.phoronix.com/scan.php?page=news_item&px=NVIDIA-Generic-Allocator-2019
Mohandevir Jul 3, 2020
Quoting: DefaultX-od
Quoting: Mohandevir
Quoting: DefaultX-od
Quoting: minkiu
Quoting: DefaultX-od
Quoting: DefaultX-od
Quoting: Linas
Quoting: DefaultX-od
Quoting: TheRiddick3) Nvidia to offer Wayland support.
They are offering it, it's just none of DE willing to implement it
What do you mean? Is there something Nvidia-specific they need to implement?

EGLStreams

And you guys know what's the funniest thing? Windows 10 will soon have Wayland support in WSL2 no matter what GPU will be in use.

I don't have all the info/know the story, but I believe the whole linux ecosystem was pitching for GBM and nvidia just went their way with EGLStreams?

Well here's what I found:

Nvidia dev says:

GBM - The current way used by Wayland compositors... It provides buffer allocation, arbitration, and handles. The "benefits" expressed is that it's already supported by many code-bases, is widely-deployed and tested, and ia a minimal API while supporting allocation-time usage specification. Current GBM shortcomings expressed in the presentation are process-local handles only, very GPU-focused, and arbitration is within device scope.

EGLStream - NVIDIA's current preferred method supports allocation, arbitration, handles, state management, and synchronization. It's viewed as being proven, portable, and comprehensive/extensive abilities. But viewed shortcomings of EGLStream are the open standard being implemented differently by vendors, there isn't cross-device support, it's based upon EGL, there is a lot of encapsulation, and the behavior can vary in some areas.

Original post at Phoronix:

https://www.phoronix.com/scan.php?page=news_item&px=XDC2016-Device-Memory-API

QuoteWith those current "prior arts" from here, James Jones (NVIDIA) is hoping that the development community will ultimately devise a more optimal API that's minimal, portable, supports more than just GPUs, allows for optimal performance, handles driver-negotiated image capabilities, allows good performance, supports image layout transitions, and more. Again, while it's of concern to Wayland compositors and is the hot topic being debated right now since NVIDIA isn't supporting GBM, the hope is to make a much more universal and full-featured API to other clients / windowing systems. Obviously this isn't something that can be solved in one day, especially in trying to reach a consensus for a new, optimal API for device memory / surface allocation.

Hopefully there will ultimately be this new optimal API that's agreed upon -- and supported -- by all major vendors, but until then the Wayland compositor maintainers will still probably be focused on their GBM-only code-path. NVIDIA doesn't seem interested in budging right now on supporting GBM by their proprietary driver if it's only to be replaced in the (near?) future by a better surface allocation API and their interest in also seeing cross-platform support. Thus don't expect any miracles in the immediate future for the NVIDIA proprietary driver to work on the current-generation of Wayland compositors using GBM for their surface allocation. At least the XDC2016 feedback and comments so far have been productive and developers are open to discussing a new, better API.

Interresting read... So Nvidia thinks GBM too limited and decided to settle on EGLStream while waiting for a new and better API that didn't materialized, yet... Am I getting it right?

It's seems they are busy with this:

https://www.phoronix.com/scan.php?page=news_item&px=NVIDIA-Generic-Allocator-2019

Nice! All is not doom & gloom (GBM/EGLStream debate), afterall. I admit that I lost track on the matter. Could it be Nvidia's missing piece of the puzzle to support Valve's forthcoming Gamescope?
mylka Jul 3, 2020
Quoting: barotto
Quoting: stankalovichThere have a been a few Linus Tech Tips videos that were very pro Linux. The impact of a channel with 11.2M subscribers (as of now) can't be ignored.

LTT is a gaming channel and Steam numbers went down, not up.


they mostly show and explain hard and software. the benchmark games, but they rarely play them
it is a tec channel and not a gaming channel
Purple Library Guy Jul 3, 2020
Quoting: DefaultX-od
Quoting: Purple Library Guy
Quoting: DefaultX-od
Quoting: tmtvlNeat. Too bad it's Ubuntu, we don't need Canonical to grow too big for their shoes.
Jesus Christ what's wrong with you people, why you can't just be happy?
Give it up. You are not going to single-handedly hector people, with one-liners yet, into ceasing to dislike Canonical.

They are doing pretty good job to increase performance of gnome shell, isn't it a good reason to stop hate them?
1) I don't hate Canonical. Distrust, yes. Disrespect their technical decision-making, indeed. Hate, not at all. There's people and outfits I hate--ExxonMobil, for instance. It's different.
2) No. I don't use or like the Gnome shell, so I don't care what they do with it.
DefaultX-od Jul 3, 2020
Quoting: Purple Library Guy2) No. I don't use or like the Gnome shell, so I don't care what they do with it.

Well according to this article the vast majority using Ubuntu and that's basically means gnome + Fedora which is gnome too, so Canonical helping to improve what's de facto is the standard now.

What do you use?


Last edited by DefaultX-od on 3 July 2020 at 6:20 pm UTC
tuubi Jul 3, 2020
View PC info
  • Supporter
Quoting: DefaultX-od
Quoting: Purple Library Guy2) No. I don't use or like the Gnome shell, so I don't care what they do with it.

Well according to this article the vast majority using Ubuntu and that's basically means gnome + Fedora which is gnome too, so Canonical helping to improve what's de facto is a standard now.

What do you use?
In case you're interested, GNOME is the second most popular DE among GOL users after KDE Plasma. I'm partial to Xfce myself.
DefaultX-od Jul 3, 2020
Quoting: tuubi
Quoting: DefaultX-od
Quoting: Purple Library Guy2) No. I don't use or like the Gnome shell, so I don't care what they do with it.

Well according to this article the vast majority using Ubuntu and that's basically means gnome + Fedora which is gnome too, so Canonical helping to improve what's de facto is a standard now.

What do you use?
In case you're interested, GNOME is the second most popular DE among GOL users after KDE Plasma. I'm partial to Xfce myself.

In case you're interested, not everyone who uses Linux are into gaming stuff
While you're here, please consider supporting GamingOnLinux on:

Reward Tiers: Patreon. Plain Donations: PayPal.

This ensures all of our main content remains totally free for everyone! Patreon supporters can also remove all adverts and sponsors! Supporting us helps bring good, fresh content. Without your continued support, we simply could not continue!

You can find even more ways to support us on this dedicated page any time. If you already are, thank you!
The comments on this article are closed.