So we have been on Build 9926 for a while and Microsoft is aware that we want something new. They started out this Technical Preview claiming that we will see the OS evolve as it is built. While we have, for the most part, been given builds frequently enough to influence the development, the last couple of updates have been about half of their expected interval.
For this release, Microsoft claims that there is just a single blocking bug that is preventing a public release. They also state that users who want a more stable preview build, such as those who installed it to a production machine (not naming any names… sigh), should switch their update schedule to “Slow”. Users on the “Fast” lane will get new builds much quicker. The words “Daily Builds” appeared on an internal document, but was quickly clarified as an internal memo.
Microsoft is also considering a third tier that pushes updates faster than both “Fast” and “Slow”.
There are two opposing forces when it comes to the update speed of preview software. While you end up with more stability if you are extra careful with troubleshooting, you will not catch every bug. For that matter, there are still bugs that I can point to in Windows 7 that will never be fixed at this point (there is one bug with resizing windows on vertically-separated multiple monitors that still exists in Windows 10 — although other multi-monitor interfaces that are not in Windows 7 give plenty of workarounds room).
When the update speed is low, you are stuck with bugs that feel excruciating for what feels like forever. Add that to the slow, bursty roll-out of new features and it gives some extra merit to the fast release model. That is, unless you get so quick that you run into bluescreens and other, more critical failures. It is a tough balance that I can sympathize with and empathize to.
It's tough, so I have personally flipped my machine over to “slow”. I figure that I could keep on the more stable builds for a short period of time and wait to hear what the community thinks about each new release before flipping to the fast track.
What are your thoughts? Let us know in the comments!
Came out yesterday Office Pro
Came out yesterday Office Pro 2016 Preview update.
I hope they can release the
I hope they can release the full version of windows 10 in june or july.!?
They also state that users
They also state that users who want a more stable preview build, such as those who installed it to a production machine (not naming any names… sigh)…”
It wasnt ne >.>
The only interest/thing that
The only interest/thing that possibly has me even looking in win 10, it the possibility of an HSA aware OS, via the Graphics/other API/s, and the ability to utilize any and all of the various GPUs(discrete, integrated) plugged in/connected GPU devices for Graphics/GPGPU regardless of who manufactured to GPU, or SOC integrated GPU. Being able to plug in, and utilize any make and model of discrete GPU, and SOCs Integrated GPU and utilize them for any and all graphics/GPGPU workloads is definitely the Goal for HSA computing.
I guess both DX, and Vulkan are moving in that direction, and Vulkan’s use of a the SPIR-V IL, LLVM type of API, for its graphics(OpenGL) and GPUPU(OpenCL), is definitely paralleling the proposed HSA foundation’s HSAIL intermediate language functionality. So maybe on HSA aware Linux/other OSs, Vulkan’s SPIR-V IL, LLVM can be used to allow/make the various GPU/SOC makers’ hardware accessible via the SPIR-V IL, and virtual machine for HSA style graphics/GPGPU workloads, and windows DX12, may have some SPIR-V IL style functionally of its own, or maybe utilize both DX, and Vulkan assets at the same time.
There is no reason that any compiled/interpreted language can not utilize a backend conversion to any DX12/Vulkan( SPIR-V IL, DX12 IL equivalent, or both) standard cross platform abstraction layer that all makes and models of GPU(integrated/discrete) hardware can use! For sure all OSs are doing it already for GPGPU and OpenCL, and OpenCL already utilizes the SPIR-V IL, LLVM API/abstraction layer. So with the Vulkan now utilizing SPIR-V IL, LLVM API/abstraction layer for OpenGL, in addition to OpenCL, and other languages(subset of C++, scripting languages etc.) HSA aware OSs can easily use the Vulkan API for HSA style computing.
The root problem is the way
The root problem is the way Windows handles GPUs. To simplify the driver layer starting with DX10, MSFT only allows one display driver to be active at a time, which limits what you can do with GPUs. Yes, you can do a lot via the driver layer, but that’s typically limited to just one OEM at a time (No easy way to NVIDIA/AMD).
Yes, and people purchase
Yes, and people purchase hardware to add to their computing systems and the supposed OS can not do its job and make all the installed hardware usable all of the time. It should not matter what is plugged in, GPUs, Integrated GPUs, sound card/s, whatever it is the job of the OS to make sure that every device approved to work with the OS is available for use all of the time. The OS maker/s need to dictate this to the GPU makers, NO usability for the intended purpose on an all the time basis no certification to work with the OS/s!
The makers of integrated and discrete GPUs should be required to make their hardware usable in mixed maker/model GPU mode, and their GPU hardware/diver APIs should be required to support at least one open cross platform driver/API standard, to go along with all the proprietary standards, same for the OS makers. Before the PC/Laptop/mobile device is allowed to be sold! There needs to be these requirements, no compliance no approval for sale by any government agency. People have a right to be able to use all the processing power of whatever CPU/SOC/GPU they have purchased, on an always on basis, all of the time, no more of this switchable GPU crap. If the device has integrated and discrete GPUs, then the user should be able to use both, no excuses, OpenCL has been around for a good while, and there is no reason the integrated GPU can not be made to do at least computation, while the discrete GPU/s does Graphics. HSA aware OSs need to be mandated, and this hardware held hostage must be stopped!
For sure the SPIR-V IL and LLVM is an HSA aware graphics/GPGPU API so there is no excuse for the GPU makers not adopting The Khronos Vulkan graphics API, and Khronos is the dictionary definition of a cross platform open standards organization, and all the CPU/SOC/GPU makers have representation on the various Khronos committees, and BOD. This using of proprietary non-cross-platform graphics APIs over the open industry standard APIs needs to be stopped, there is no reason that computing systems can not support at least one open industry standard graphics/GPGPU API, and the proprietary ones also. HSA aware OSs should have been the standard 10 years ago!
Pretty sure this only
Pretty sure this only applies (or applied?) to Vista, unless you are talking about something completely different than I think you are. For compute workloads, I've personally used both my Intel HD graphics and my NVIDIA GeForce GPU simultaneously in Windows 7. It is difficult and it is annoying, especially if you are trying to make it automated across arbitrary configurations, but it is entirely possible and works in the GPU compute space today.
Also, for Vulkan, graphics workloads can be separated to multiple vendors, integrated/discrete or multiple discrete. There might be some issues with direct resource sharing in some cases, though. Source: https://youtu.be/qKbtrVEhaw8?t=13m38s
So… am I completely misunderstanding what you're saying?
I simply can’t wait. Belch,
I simply can’t wait. Belch, stretch, yawn ….
And Now M$ is offering its 10
And Now M$ is offering its 10 OS “Free” and hoping the fish will bite, and what of this “Free” after that unspecified amount of time, and the bills start to arrive for that metered OS subscription service, and a lifetime of pay to play. Welcome to the Comcast of the metered OS service, and the 365 days of year in year out milking for Giga$. Steam OS will be the option for those that will escape the empire! Free roaming TuxBirds outside of the barbed/concertina wire fences, and lookout towers, roaming in many open and unfettered ways, unmolested by flying executive chairs, and the market milking of the grunting, profusely sweating management Monkeys.