CCRL 40/40, 40/4 and FRC lists updated (23rd February 2019)

[Modern Times]

but the link is a windows only version. I guess some CCRL members are testing under linux ?

None.

[xr_a_y]

but the link is a windows only version. I guess some CCRL members are testing under linux ?

None.

That is a surprise for me. Any particular reason ?

[Modern Times]

but the link is a windows only version. I guess some CCRL members are testing under linux ?

None.

That is a surprise for me. Any particular reason ?

I guess testers prefer to run Windows, I don't know. Let's not have this thread explode into a Windows vs Linux debate !

[Ras]

That is a surprise for me. Any particular reason ?

1) the market share of desktop Linux is negligible in general.

2) application deployment under Linux is bad. You can't just make an EXE on one distro and hope that it will work on another distro - and there are hundreds of distros around in a completely fragmented ecosystem.

3) the packet manager is bad for applications because you will never get all these smallish engines into let's say Debian, let alone in a timely manner. No maintainer will care, and the effort for the authors becoming Debian maintainers would be absurd.

4) engine authors won't really care to join the distro maintainers in their completely redundant work to make and test packages for umpteen distros.

5) engine authors won't want to dive into Docker images just to work around Linux application deployment issues.

6) compiling from source can be difficult because people's build chains can be brittle.

7) if you even have the source, by far not all engines are OSS.

8) and because of the dependency problems under Linux that when bypassing the packet manager you'd have to fiddle out manually.

9) let's not even get started at the task of maintaining several different build chains of the same compiler in different versions to match what the engine authors have tested.

10) if you go via WINE, then you'll have to troubleshoot Linux and Windows EXEs. Don't bet that the authors will care to support and debug such a configuration.

11) if something doesn't work under Linux, it's always the user's fault. Under Windows, people do expect an EXE to just work.

[xr_a_y]

That is a surprise for me. Any particular reason ?

1) the market share of desktop Linux is negligible in general.

2) application deployment under Linux is bad. You can't just make an EXE on one distro and hope that it will work on another distro - and there are hundreds of distros around in a completely fragmented ecosystem.

3) the packet manager is bad for applications because you will never get all these smallish engines into let's say Debian, let alone in a timely manner. No maintainer will care, and the effort for the authors becoming Debian maintainers would be absurd.

4) engine authors won't really care to join the distro maintainers in their completely redundant work to make and test packages for umpteen distros.

5) engine authors won't want to dive into Docker images just to work around Linux application deployment issues.

6) compiling from source can be difficult because people's build chains can be brittle.

7) if you even have the source, by far not all engines are OSS.

8) and because of the dependency problems under Linux that when bypassing the packet manager you'd have to fiddle out manually.

9) let's not even get started at the task of maintaining several different build chains of the same compiler in different versions to match what the engine authors have tested.

10) if you go via WINE, then you'll have to troubleshoot Linux and Windows EXEs. Don't bet that the authors will care to support and debug such a configuration.

11) if something doesn't work under Linux, it's always the user's fault. Under Windows, people do expect an EXE to just work.

I agree only with 1) although this is less and less true now. I guess all the next points are more your own sensations than the truth (and many are just wrong, but I won't argue the linux/windows thing here : as windows i also a great and convenient system to use and develop with).

Best regards