Hahah, very funny that Skippy runs better for you than your production build.
There are certain elements of Windows that has nothing to do with a lot of hardware variations that needs improvements. USB is one, it has been horrible or at least very unpredictable since it was implemented in Windows. And this issue has nothing to do with bad drivers or exotic hardware.
It's just Windows...
Uh, yes, that is the point - this is *NOT* a daily driver, use every day type of build. You're not to be testing these on live machines, particularly mission critical machines, precisely *because* there are so many things that are broken.
And that is what they are doing - getting back to basics, where the core is one and the same for everyone, including the home users, the business users, and the users of the server-class iterations. In the article they state that the Azure devs were using much older versions of the core with bits and pieces cobbled here and there to just get things to work. This new plan eliminates that, bringing everyone onto the same code base.
But, then again, you're not a typical home user case, nor a typical business user case, nor a typical server-user case.
I would evenly bet that the vast majority of home users, for example, do *NOT* run VMs on their machines. I'll also warrant that a larger percentage of home users than you realize *DO* play games on their machines.
Of course, in a business scenario, VMs are more likely (though still not as much when using non-server-class OSs), and gaming is much less of a priority, but productivity apps like Office suites, A/V (audio/visual, not Anti virus) suites, etc. are also important. And in server-class, obviously data storage, retrieval and access, as well as user management, resource mgmt, etc., are more important.
But logically, it makes the most sense to start with a unified base, the core, and work up from there depending upon the intended use.
Eye C.
That last part - exactly, in a nutshell.So far, I haven't found anything wrong with Skippy or Fast Ring. Everything just works.
Although my computers are at home, I'm not your typical home user; in fact, I will pay extra to get the better one. And I think I can safely say the latest Builds are working fine for me.
But that's the beauty of Windows 10, Jimbo. There's something there for everyone without Microsoft having to go to the expense of building six or eight versions of Windows 10. For someone advocating against features of Windows 10, you sure have a lot of requirements . . . that I don't have.However, having said that, I probably have some requirements you don't have.
Again, the last statement - absolutely *key* to using an Insider's Preview / Skip Ahead build.
Agreed. One of the very reasons the IP program exists is that internal testing is on a very limited pool of resources. And there are users like many of us here that do not fit into a single category, as I outlined with Jimbo - he is not a typical home user of a desktop machine. I am not a typical gamer. Others here also are not stuck in a single category but mixing categories here and there.
But going further, you hit the nail on the head - they can only account for so much of what is out there that people want to do, or need to do, or are stuck with using to get things done. Not everyone can afford a monthly / yearly subscription to M$ Office, or shell out money for other programs like DxO suite, Adobe software, etc.
I'm with Wyonna Shawn. The ZDnet is clear as mud. But if (and its a big if) I get the gist of it I don't think that we will see many (or even any) new features in 20H1 until next year when it will be grafted onto a December internal build. I don't know how they will keep Insiders who are only upgrading on their main physical machine interested but if there is more discussion of virtualization on this forum I will definiitely be keeping my finger in. Pushing VMware to the limits (for example trying to get it to work with the newest Linux kernels) is a major interest of mine having started out with VMware 1.0 on Windows NT and turn of the century Linux OS's.
Hi there
I still re-iterate that basic things should work - especially if they have been working for years
for instance surely display language should work properly - this has been broken for several releases now - and even where you can get bits of it to work the languages are so mixed up with bits of one and then the other (these are where you add additional display languages - not to the base language itself).
On the latest skippy I can't even INSTALL Vmware and VBOX is broken too. Ms Office functions as does Firefox -- but is that really of any use in testing -- just Ms Office, and Firefox. I could probably still run those two applcations on an XP system (in fact Office 2010 - 32 bit runs perfectly on an XP VM in any case !!).
While people have been saying you shouldn't use these builds for testing typical daily use type machines -- but if not when are you supposed to test new releases to ensure basic functionality still works properly.
New features are fine for instance WSL and Sandbox (when it is given a bit more useability) and one expects things to break - but the core useability of the OS shouldn't be compromised.
While here about 99% of the population speak perfect English, and a load speak Danish, German and Norwegian why shouldn't people have a Windows that works in their own language when it's been working perfectly before.
I'd love to see what sort of project plan was devised for these releases -- what to include, test scripts and the result of those etc etc -- something I Imagine is done in every serious reasonably sized I.T dept at typical companies from those with say over 20 users to the mega large ones.
It's of course not easy - with the absolute scale of different hardware and applications that run on Windows but I do think the whole idea of QC seems to have been forgotten totally by Ms.
Cheers
jimbo
@jimbo45
Don't expect anything related to languages and visualizations among other things to work for a very long time on these 20H1 builds. They are focusing on core OS changes, so I doubt the userland features are that high on priority list. A lot will be broken in the kernel and related components for quite some time. This means virtualization will definitely be broken too.
Hi there
@slicendice
there's some discussion on the VMWare forums of problems with vmware on these builds too-- although some enterprising person has found a fix for running this build as a GUEST on a standard Windows HOST. It runs on my system fine as a GUEST on a LINUX Host though !!! --with the language problem -- but it's nice for playing with the WSL.
To run as a VM on a Windows HOST this was the suggested fix you need to make in the VM's .vmx config file
add these lines
cpuid.brandstring = "VMware Fix for Windows 10 Build 18346 x64"
cpuid.1.ecx = "0--------------0----------------"
cpuid.1.edx = "-----------0---------0----------"
monitor_control.enable_fullcpuid = "TRUE"
Note I haven't tested this myself but I might have a go later using the current (standard) Windows build as host.
Cheers
jimbo
I understand and agree with most of what both sides are saying here. While M$ is dealing with so many types of hw and sw, and with all the infinite setups people might employ, it's a giant task to make everything work with everything. And that's understandable for everyone I think. But I also agree with Jimbo here as basic components of the OS should NOT regress. And they DO! In my opinion it almost looks like M$ fixes, breaks and fix things over and over just to make it look like they are doing something. When the list of "Known Issues" seems to be the exact same from build to build, yet we get notes on some random things they fixed or upgraded, that's ridiculous. And who knows which company is NOT playing nice with the other? But at the bottom of it all, M$ has the ball in their court. They can push through whatever they want to, IF they want to badly enough. So basic components like sound and video should ALWAYS work. And common hardware that has been working should keep working unless it is old as hell. Lastly, if they are going to release a new feature, and do so widely, then they should NOT abandon it a few builds later, like "sets".
There's a balancing act to be sure, but I just feel like M$ spends way too much time on things that very small segments will benefit from, and ignore things that are common components of this OS, that huge segments depend on. Just my opinion...
Quote
