The GZDoom 3.5.0 survey's results

[Graf Zahl]

After closing the survey with the 3.5.1 release, here's the results from 15000 users reporting:

The big numbers (3.3 survey results in parentheses)

61% (57%) of the reporting users use a graphics card which is DX12/Vulkan compatible.
34% (34%) of the reporting users use a graphics card which is at least OpenGL 3.3 compatible, i.e. it can use the modern core profile render path.
This is further split up into 19% running an OpenGL 3 compatible card and 15% running an OpenGL 4.3+ compatible (i.e. capable of running the most modern render path) card.
2.5% (6%) of the reporting users use a graphics card which only has OpenGL 2 support, i.e. has to be run the legacy build.

No separate reports were made for the software renderer anymore.

Distribution of operating systems is:

90% (88%) Windows
1.9% (2%) Mac
8% (10%) Linux
0.3% are on Windows XP - most using the vintage build.

87% (85%) use 64 bit on a 64 bit system
9% (10%) use 32 bit on a 64 bit system. (This one's odd, I'd appreciate if some of these users can tell us why.)
4% (6%) use 32 bit on a 32 bit system

I think the most interesting aspect in here is the sharp dropoff in users on systems with OpenGL 2 and OpenGL 3.1. It more than halved over a mere 4 months!
This speaks a very clear language about the future of support for this hardware group. If the dropoff continues at the given rate and factoring in the Christmas business this will most likely not be supported past 2019.
Windows XP user share has already reached numbers where supporting it makes no real sense anymore - the exact number as of this morning was 48 users out of roughly 15000. As long as there is no need to reconfigure the project it will remain supported but I give no guarantees whatsoever about for how long.

[landfill baby]

Since you asked, I'm one of the people using 32-bit OS on 64-bit hardware, and honestly, I have no idea why, it was like this when my school gave it to me 8 years ago, and I never bothered to change it. It's only just started to become a problem now that everyone's finally starting to drop support for it. I'm using an old Toshiba Satellite Pro L500-1VT with Windows 7 Pro SP1.

[Rachael]

Sometimes it takes people dropping support for it before people start adopting a new standard.

The reason why we're stuck with IPv4 despite having run out of address space more than a year ago is because no one's dropping IPv4 support.

[GFD]

Wait, does the 32 on 64 statistic include PCs with a 32-bit OS install with a 64-bit processor, and not just users running the 32-bit binary on a 64-bit OS? That would explain things a little bit better, as this is something users can't easily change. Just the other day I serviced a PC with 32-bit Windows installed, despite having a 64-bit processor, and apparently that's just how the PC was distributed. Granted, it's quite old, and it only has 1 gig of RAM anyway...
...actually, looking it up just now, "Windows 7 Starter" was only available in 32-bit. Guess that explains that. (Linux Mint runs a lot better on it.)

[Rachael]

Some PC's are indeed done this way - I have a laptop that cannot use a 64-bit Windows despite using a 64-bit processor because the drivers are simply missing for all of its hardware. The 64-bit processor is kind of a token "oh we have 64-bit now, yay?" from the manufacturer - from back when 64-bit was an emerging technology.

Nowadays I just use it to run Kali Linux (64-bit) and that runs just fine.

[Graf Zahl]

Wait, does the 32 on 64 statistic include PCs with a 32-bit OS install with a 64-bit processor, and not just users running the 32-bit binary on a 64-bit OS?

No, it checks the OS. 32 bit OS on 64 bit systems are among the 4% of 'true' 32 bit users.
I don't actually think there's many true 32 bit CPUs still out there. They were a thing of the past 10 years ago already and if it wasn't for Microsoft having forced 32 bit users of older Windows versions to upgrade to the 32 bit version of Windows 10, my guess would be that the numbers would be a lot lower.

[Hirogen2]

ILP32 can be faster in some cases, depending on the CPU type, amount of memory shuffled around, etc.
http://www.osnews.com/story/5768/Are_64 ... es_/page1/ (very old page)
For a x86_64 CPU type though, one should be exploiting all registers and choose an ILP32 ABI of x86_64, rather than the x86 ABI. (e.g. prefer Debian x32 in place of Debian i386).

[Graf Zahl]

To be honest, choosing an OS with a 32 bit memory model for some abstract benefit strikes me as supremely stupid in a time when software can actually make use of more memory a 32 bit pointer can handle.

As for that link - that information is 14 years out of date and really should be treated as obsolete. The future is 64 bit.
And your advice, just one remark: "Living in the past"...

[ibm5155]

this is offtopic but why this specific page is told to be not safe by the browser itself?

[GFD]

That would've been my fault. It is no longer my fault, and now it's your fault. My avatar was being loaded externally through unencrypted http, but I just realized I could probably change all the URLs to "https" to make it not do that anymore, so I did, and it worked. Yours is still using unencrypted http though, so the browser rightfully doesn't label the page as totally secure.

[Nash]

Can external avatars be exploited into security loopholes?

[wildweasel]

Can external avatars be exploited into security loopholes?

I'm sure anything that uses a loaded image as its method of entry could be used in this context, since the forum doesn't appear to make any restrictions on avatar embeds. (I've had to ask a few users to remove their avatars due to being well in excess of 3 MB or more, for example...)

[GFD]

Granted, I haven't heard of any significant image library-based exploits in quite some time. It might be theoretically possible of course, but I would think images are probably one of the safest kinds of content to load from other sources. Much more dangerous are externally loaded Javascript libraries, which are unfortunately both common practice and commonly targeted.

The level of encryption used for loading externally-hosted images is largely irrelevant to this specific threat model, of course, since if the actual image data has been altered to host an exploit of some kind, it doesn't matter how it's delivered to you. The web browser's concern is primarily whether or not your communications are encrypted, to prevent bad actors from snooping on your activity specifically, or performing man-in-the-middle attacks on your communications. For this page, Chrome's security warning actually explicitly states that only images could be targeted in this way, since that's the only kind of content being loaded without encryption:

[Graf Zahl]

I think, if it could be done, plain http links should be blocked for avatars. The more the browsers tighten security, the more of an issue it may become.

[Kinsie]

Disabling external avatars outright would cover most risky scenarios, but it would probably suck in other ways.