Khronos announces openGL successor Vulkan
A next generation successor to openGL named Vulkan was announced by the Khronos Group. This API promises to provide better 3D graphics performance and GPU support on desktop and mobile devices.
Peter Bright reports for Ars Technica:
Vulkan, previously known as Next Generation OpenGL or just GLnext, is designed to be a low-overhead API that facilitates multithreaded 3D development, enabling different threads to simultaneously prepare batches of commands to send to the GPU. It gives developers greater control of generating commands, putting tasks such as memory and thread management in their hands rather than relying on video drivers to handle these responsibilities. In so doing, it greatly reduces the amount of work that the driver must perform.
It represents the fourth graphics API aiming to offer this kind of control and the performance gains that come with it. AMD's Mantle, Microsoft's DirectX 12, and Apple's Metal were all developed with similar goals in mind. However, these are all platform limited in one way or another; Mantle only works with AMD GPUs, DirectX 12 only works in Windows, and Metal only works in iOS. Vulkan will span both GPU and operating system vendors, continuing in the footsteps of the cross-platform, vendor-neutral OpenGL before it.
Vulkan is also intended as suitable for both mobile and desktop development. This is in contrast to OpenGL, which has the OpenGL ES variant for mobile and embedded systems. The duality is in part due to OpenGL's age; it includes old features that aren't really relevant to modern 3D programming, but which nonetheless remain part of the specification. OpenGL ES removes many of these to be a little slimmer and more streamlined. Vulkan will similarly do away with them, eliminating the need for a special mobile API variant.
Redditors reacted to the news about Vulkan:
Beammaker: "Vulkan reunification, bringing desktop and mobile APIs together once again."
Afiefh: "We must follow the teachings of Surak if our APIs are to find harmony and balance."
3G6A5W338E: "Live long and prosper, open standards."
Xanny: "It is a clean slate for Linux to compete on. The model is so different you should expect one open source Vulkan to SPIR implementation, plus common work on some LLVM compiler backends for each GPU architecture.
However, the fact there is already driver development, but the API is not being disclosed, does not bode well for free drivers. It means once again the blob drivers will have the head start and that Khronos does not give a shit about having a blessed reference implementation, which I think continues to be the greatest flaw in all their APIs.
It is highly unlikely developers will use Vulkan the way it is intended. You should be writing your game engines and GPGPU programs against SPIR once and running them everywhere, be it with an abstraction layer like SDL or a third party engine. Instead most dev houses will continue developing their "PC" versions using DirectX - which will be stuck on DX11 for a long time, until Windows 10 adoption and GPUs supporting DX12 take off - and having third parties rewrite all their shaders against Vulkan now instead of GLSL.
Additionally, we have no idea how eager Apple or Google are to enable Vulkan on their platforms - it is highly unlikely Apple will enable it on iOS since it competes with their own proprietary API. Google will probably adopt it, but if the way they handle OpenGLES is anything to go by, rather than use a common free implementation with simple vendor drivers, its going to be blobs all the way down again, and blobs that do not work properly... again. If you even get blobs. Remember how poorly updated most Android devices are? It is unlikely Android will require Vulkan drivers until Android 6, so it will be at least five years before enough people even own phones that support the API to justify writing for it.
So I expect proprietary Nvidia and AMD Vulkan drivers out immediately after the API release later this year, launching first for Windows and second for Linux, Nvidia shortly thereafter and AMD probably months later. Then the Mesa community can panic and try to somehow implement an API a huge majority of them either have not had access to or have been gag ordered not to publish patches for for months and be behind once again in driver tech. No other platform will adopt it any time soon, and Windows developers are still high on the Microsoft crack and will never use anything but DirectX.
Korora 21 reviews
Fedora has lots to offer desktop users, but it doesn't come with proprietary software or some multimedia codecs. Korora builds on the basic Fedora desktop and tries to offer a more user-friendly experience.
I did a full review of Korora 21 on Desktop Linux Reviews:
I think that Korora 21 has the right idea in terms of making Fedora more accessible to casual users or those new to Linux. It hits all of the sweet spots of a desktop distribution until you get to the software management tool. And, as I noted above, that’s where it stumbles and stumbles very badly. This is such a shame because otherwise Korora 21 is a fine desktop distribution.
If I had to make a recommendation, I’d suggest that only experienced Linux users try Korora 21. Yum Extender shouldn’t matter to those folks one way or the other since they’d probably opt to use Yum at the command line anyway. But newbies or casual desktop users would be much better served by sticking with the Linux Mint version of Cinnamon until Yum Extender is replaced by something that more closely resembles an app store.