Warning: Windows 10 May Auto-Install On Your PC

Status
Not open for further replies.
The thing is, in a perfect world, updates would always be a pure beneficial thing that you just add and be done with. The reality is MOST of the time it's that way, other times, you get real problems. For example, I use a custom shell on my system and after doing a giant update pack on a system on 7, I noticed that the Z-order on my windows got completely screwed. I couldn't see the links that were supposed to appear always on top of other windows. It made my GUI practically unusable. So I reverted and went down the updates one by one, until I found the problem. Turns out TWO updates introduced the problem (KB3145739 and KB3153199 for those that want to know). If I had to rely on forced auto-update, my system would be effectively broken for my use, meanwhile most people would be happily singing "works for me!" because they're not doing the same things with their system that I am. Knowing that Microsoft can and will potentially break my system with an update means I need to have the capacity to skip ones that end up being problematic. But whatever. According to some here, I'm part of the 0.00000001% of people who has ever have a problem from a bug Microsoft introduced.

Of course anytime you change software you run the risk of adding bugs. Indeed you always do. But over time as functional and other changes are made to that software, not updating will introduce bugs as well. How many times have we seen security flaws that have been patched be exploited? Or even other bugs corrected in software that cause issues with other software because the updates weren't there?

It's never going to be perfect and I'm not saying 10 can't handle it better in non-Enterprise versions but simply refusing updates doesn't solve everything and can introduce problems of its own when the OS is getting constant functional and non-functional changes.
 
Of course anytime you change software you run the risk of adding bugs. Indeed you always do. But over time as functional and other changes are made to that software, not updating will introduce bugs as well. How many times have we seen security flaws that have been patched be exploited? Or even other bugs corrected in software that cause issues with other software because the updates weren't there?

It's never going to be perfect and I'm not saying 10 can't handle it better in non-Enterprise versions but simply refusing updates doesn't solve everything and can introduce problems of its own when the OS is getting constant functional and non-functional changes.
Again, I see this as a false dichotomy. It shouldn't be a choice between "don't update anything, ever" v. "forced automatic updates on everything that you have no control over", which is how everyone seems to be presenting it. I added what felt like 100 updates to that system, but was able to leave out those two that added problems that weren't there before and effectively wrecked my system. This makes me be wary about updates I add and want to retain the ability to revert my system if new ones cause problems. 10 doesn't give me that luxury, whereas 7 does. I guess I'm the lone voice of opposition here in that I don't want my OS to be a testing ground for whatever MS is working on next, when they've already demonstrated to me before that they can ruin my system.
 
  • Like
Reactions: Nenu
like this
Again, I see this as a false dichotomy. It shouldn't be a choice between "don't update anything, ever" v. "forced automatic updates on everything that you have no control over", which is how everyone seems to be presenting it. I added what felt like 100 updates to that system, but was able to leave out those two that added problems that weren't there before and effectively wrecked my system. This makes me be wary about updates I add and want to retain the ability to revert my system if new ones cause problems. 10 doesn't give me that luxury, whereas 7 does. I guess I'm the lone voice of opposition here in that I don't want my OS to be a testing ground for whatever MS is working on next, when they've already demonstrated to me before that they can ruin my system.

If you look at how Windows 10 updates are done, there are two distinct update paths. One for the LTSB and one for the current branch. This isn't anything about false dichotomies, it has to do with how the different branches are updated. The LTSB doesn't generally get functional updates, only bug and security fixes. The current branch gets all updates. Over time if those using the current branch picked and chose themselves each and every update, you now have big problem. The current branch you're working from doesn't necessarily represent the code that many of your users are running. Each and every update isn't necessarily standalone, in Agile they end up being cumulative.

This is basic software change control stuff. There's nothing nefarious about it, it's how this works. You cannot introduce constant functional change into a software product AND allow end users to pick and chose the updates, at least not permanently unless each and every update were completely self-contained, i.e. each and every change introduced zero dependencies. That's pretty much impossible in something like an OS. Those users would need to be on a different branch and that's the point of the LTSB.
 
So you did say that? I clicked on the link back to your post and I didn't see it. The actual text in the message he linked to is


Guess it could be a glitch in the Forum s/w.

No I said it with quite a bit of other text for context. However "Someone" didn't like what I said and reported it so the post got deleted for "Inappropriate content". I basically called BS on him being in charge of any kind of a competent IT staff if they were "Dreading" supporting Windows 10 in an enterprise environment.
 
If you look at how Windows 10 updates are done, there are two distinct update paths. One for the LTSB and one for the current branch. This isn't anything about false dichotomies, it has to do with how the different branches are updated. The LTSB doesn't generally get functional updates, only bug and security fixes. The current branch gets all updates. Over time if those using the current branch picked and chose themselves each and every update, you now have big problem. The current branch you're working from doesn't necessarily represent the code that many of your users are running. Each and every update isn't necessarily standalone, in Agile they end up being cumulative.

This is basic software change control stuff. There's nothing nefarious about it, it's how this works. You cannot introduce constant functional change into a software product AND allow end users to pick and chose the updates, at least not permanently unless each and every update were completely self-contained, i.e. each and every change introduced zero dependencies. That's pretty much impossible in something like an OS. Those users would need to be on a different branch and that's the point of the LTSB.
Well that would be nice except my understanding is if I were to buy Windows 10 Pro, I don't GET access to the LTSB, I only have one option, which is everything updated, with the potential for some of it breaking my software. I find that unacceptable as I've seen it interfere with using my system in the past. I need more control than that in my own OS. It has nothing to do with how nefarious it is, if it causes me real world problems, no explanation as to why this is better is going to cut it if I can't use my system or run my software properly.

You say "it's pretty much impossible" for an OS, yet updating manually is how I did it in XP and 7. It's a conscious choice by MS that introduces an additional vulnerabilities for the end user if their update ends up breaking things.
 
Well that would be nice except my understanding is if I were to buy Windows 10 Pro, I don't GET access to the LTSB, I only have one option, which is everything updated, with the potential for some of it breaking my software. I find that unacceptable as I've seen it interfere with using my system in the past. I need more control than that in my own OS.

No change control process is perfect. Again, plenty of things break when people don't update software. Distributing the LTSB to anyone who wants also introduces other complexities, like people wondering why they've not received any functional updates in a year. I'm not saying that should be an option, but it's not necessarily a perfect one.

You say "it's pretty much impossible" for an OS, yet updating manually is how I did it in XP and 7. It's a conscious choice by MS that introduces an additional vulnerabilities for the end user.

Windows 10 is updated FAR more rapidly than XP or 7. In just one year, Microsoft will have release three distinct versions of Windows 10. The RTM from last year which they retroactively called 1507, the update for November last year 1511 and in two weeks Redstone 1. 1607. Supposedly Windows 10 is the "last version" of Windows. While that's probably not the case it is the FIRST version that introduces major functional changes in months, not years, as a result of the change control process.

And say whatever you will of Microsoft, Agile, with constant continuous updates, is becoming the defacto standard in software change control these days. The consensus is that this is a better way to do it these days. It's not perfect but it does allow for smaller, more incremental change to be delivered faster.
 
No change control process is perfect. Again, plenty of things break when people don't update software. Distributing the LTSB to anyone who wants also introduces other complexities, like people wondering why they've not received any functional updates in a year. I'm not saying that should be an option, but it's not necessarily a perfect one.



Windows 10 is updated FAR more rapidly than XP or 7. In just one year, Microsoft will have release three distinct versions of Windows 10. The RTM from last year which they retroactively called 1507, the update for November last year 1511 and in two weeks Redstone 1. 1607. Supposedly Windows 10 is the "last version" of Windows. While that's probably not the case it is the FIRST version that introduces major functional changes in months, not years, as a result of the change control process.

And say whatever you will of Microsoft, Agile, with constant continuous updates, is becoming the defacto standard in software change control these days. The consensus is that this is a better way to do it these days. It's not perfect but it does allow for smaller, more incremental change to be delivered faster.
So we've gone from "pretty much impossible" to mean "not updated as frequently" now?

As for agile updates, it really depends on the environment you're talking about. Again, I don't think I WANT my OS rapidly changing all the time, potentially breaking things as it goes. I want it to be stable and know with certainty that my software will run on it from one day to the next. I'm not even against agile updating in and of itself, I'm against the NO RECOURSE part if something goes wrong, leaving me no option to revert whatsoever if MS makes a mistake. You can spout the advantages all you want, but I also consider software changes from a worst case scenario perspective. I mean it's about this simple to me:

Manual updating: If I have a problem with a new update, I uninstall the update (or if it's really bad, use an image recovery) make a note of it, and don't install the offending update afterwards. Result = my system still works.

Mandatory Automatic updating: If I have a problem with a new update, I'm fucked.

Am I wrong here?
 
  • Like
Reactions: Nenu
like this
So we've gone from "pretty much impossible" to mean "not updated as frequently" now?

As for agile updates, it really depends on the environment you're talking about. Again, I don't think I WANT my OS rapidly changing all the time, potentially breaking things as it goes. I want it to be stable and know with certainty that my software will run on it from one day to the next. I'm not even against agile updating in and of itself, I'm against the NO RECOURSE part if something goes wrong, leaving me no option to revert whatsoever if MS makes a mistake. You can spout the advantages all you want, but I also consider software changes from a worst case scenario perspective. I mean it's about this simple to me:

Manual updating: If I have a problem with a new update, I uninstall the update (or if it's really bad, use an image recovery) make a note of it, and don't install the offending update afterwards. Result = my system still works.

Mandatory Automatic updating: If I have a problem with a new update, I'm fucked.

Am I wrong here?

It's not a matter of right and wrong, it's about how one approaches software change control. There's basically two ways to approach it that I know. Frequent bug and security oriented updates with functional changes done in longer cycles with larger deliverables. Or frequent time boxed deliverables that are both feature and bug/security related where features are delivered faster than the first process and more frequently. Whatever software development process one uses they fundamentally deal with change control one way or the other or both.

If you use the later process, you're guaranteed to create dependencies on the prior updates. Update 3 depends on Update 2 depends on Update 1 unless EACH update is completely standalone and creates no external dependencies which kind of defeats some of the purpose of Agile because as you update software you want newer versions to take advantage of the prior updates.

The forced updates isn't a result of Microsoft being dicks about it, it's a byproduct of the development process. A process that's become extremely popular in software development and is considered to be better than longer, larger development cycles by many these days.
 
The forced updates isn't a result of Microsoft being dicks about it, it's a byproduct of the development process. A process that's become extremely popular in software development and is considered to be better than longer, larger development cycles by many these days.

Linux distributions maintain many versions of software and they actively patch many different versions simultaneously. Regardless of how packages are updated at no time is an update forced. Regardless of whether you are doing rolling updates or long term releases at no time is forcing updates a requirement or even a byproduct.
 
Linux distributions maintain many versions of software and they actively patch many different versions simultaneously. Regardless of how packages are updated at no time is an update forced.

And this has it's own problems. Lots of different versions.

Regardless of whether you are doing rolling updates or long term releases at no time is forcing updates a requirement or even a byproduct.

Unless you branch off different versions then you're going to create dependencies. There's soon going to be three different versions of Windows 10. So to validate an application assuming that every update is user selectable you'd have to validate at least three versions. And then the cumulative updates to each of those. Again, this is not a simple thing as some people portray.
 
And this has it's own problems. Lots of different versions.
Unless you branch off different versions then you're going to create dependencies. There's soon going to be three different versions of Windows 10. So to validate an application assuming that every update is user selectable you'd have to validate at least three versions. And then the cumulative updates to each of those. Again, this is not a simple thing as some people portray.

I would say that if Canonical, Suse, RedHat, Debian, and many more can pull it off there's no reason why Microsoft with it's billions can't do the same thing. Linux distributions are far more modular and they don't control all of the dependencies. Microsoft does. While it's definitely not simple it's also not uncharted territory.
 
I would say that if Canonical, Suse, RedHat, Debian, and many more can pull it off there's no reason why Microsoft with it's billions can't do the same thing. Linux distributions are far more modular and they don't control all of the dependencies. Microsoft does. While it's definitely not simple it's also not uncharted territory.

So every application written to run for desktop Linux is 100% compatible with every version of Linux and has zero dependencies on any updates?
 
It's not a matter of right and wrong, it's about how one approaches software change control. There's basically two ways to approach it that I know. Frequent bug and security oriented updates with functional changes done in longer cycles with larger deliverables. Or frequent time boxed deliverables that are both feature and bug/security related where features are delivered faster than the first process and more frequently. Whatever software development process one uses they fundamentally deal with change control one way or the other or both.

If you use the later process, you're guaranteed to create dependencies on the prior updates. Update 3 depends on Update 2 depends on Update 1 unless EACH update is completely standalone and creates no external dependencies which kind of defeats some of the purpose of Agile because as you update software you want newer versions to take advantage of the prior updates.

The forced updates isn't a result of Microsoft being dicks about it, it's a byproduct of the development process. A process that's become extremely popular in software development and is considered to be better than longer, larger development cycles by many these days.
Again, it depends on the situation. For some people's usage, completely agile forced updating may work perfectly fine. For me, in an OS, I run a couple hundred programs. I value stability and functionality above all else. Knowing the OS can change without my permission and prevent things from working makes any potential benefits the process brings not worth it for me personally.

Also I think you're not using your imagination if you think that having some sort of recourse defeats the purpose of an agile update. Let's say on July 15th, my system works fine, but on July 16th there was a forced update that broke something important to me. You're saying it's impossible for the company to allow the user to revert back to July 15th (or even let them make a private backup of the updates to that point themselves). That way if there are fifty more updates come September, I can still stay at July 15th, back when everything still worked? Granted, I'll miss out on some improvements, but that's preferable to a broken system. Again, I'm not advocating this is what most users should do, I'm saying taking away the option of no recourse at all if an update wrecks something you use is a dick move in my eyes, regardless of intent. The fact that they DO have this option for enterprise and education solutions to control which updates they accept should say speak volumes right there. If it was really as universally great as you seem to be advocating, they wouldn't have the option either, would they?
 
Also I think you're not using your imagination if you think that having some sort of recourse defeats the purpose of an agile update. Let's say on July 15th, my system works fine, but on July 16th there was a forced update that broke something important to me. You're saying it's impossible for the company to allow the user to revert back to July 15th (or even let them make a private backup of the updates to that point themselves). That way if there are fifty more updates come September, I can still stay at July 15th, back when everything still worked? Granted, I'll miss out on some improvements, but that's preferable to a broken system. Again, I'm not advocating this is what most users should do, I'm saying taking away the option of no recourse at all if an update wrecks something you use is a dick move in my eyes, regardless of intent. The fact that they DO have this option for enterprise and education solutions to control which updates they accept should say speak volumes right there. If it was really as universally great as you seem to be advocating, they wouldn't have the option either, would they?

But if you continued to refuse updates after July 15th eventually something will probably break anyway if you don't update the system. Look, I'm not saying this is perfect but again, how do you manage change control for an OS that's as widely deployed and with as much hardware and software support as it has. Countless configurations the OS where anything could break because there's so many systems in various states?

I'm not saying this can't be improved but it's not like Windows 7. That level of control can't work if updates are dependent on prior update and software is dependent on those updates being in place. Just as much can break without updating. If the LTSB version needs to be widely available then ok.
 
But if you continued to refuse updates after July 15th eventually something will probably break anyway if you don't update the system. Look, I'm not saying this is perfect but again, how do you manage change control for an OS that's as widely deployed and with as much hardware and software support as it has. Countless configurations the OS where anything could break because there's so many systems in various states?

I'm not saying this can't be improved but it's not like Windows 7. That level of control can't work if updates are dependent on prior update and software is dependent on those updates being in place. Just as much can break without updating. If the LTSB version needs to be widely available then ok.
Actually I would clarify that. Unless there's a MASSIVE security hole (which I imagine most get taken care of out the gate and most of what we get are smaller ones less likely to affect the average user), your programs will NOT break using the same software you've always. Now new programs in the future, sure, that's a possibility, but that's future stuff, not the here and now. Your existing programs that you've used for years and don't depend on updates themselves aren't going to change if the OS doesn't. I'm sorry, none of your arguments convince me any of this is a good reason to have no recourse whatsoever if something goes wrong. It seems like a vulnerability waiting to happen. A good analogy would be when antivirus systems release a bad update then brick thousands of systems:

McAfee update bricks thousands of enterprise computers
Avira antivirus upgrade wreaks 'catastrophic' havoc on Windows PCs
Panda antivirus mistakenly flags itself as malware, bricks PCs | ZDNet

At least that stuff is obvious. The worst is when auto-updating introduces a bug that affects a small number of people that NEVER gets fixed.
 
I love how you have no idea who I am or anything really about me but, you decide I am a shill?

I know you defend a product like a fanatical worshiper defends their god. I know you enjoy insulting those who don't like your god. If you're not a shill, then I apologize for not recognizing your religious devotion to a collection of bits.
 
  • Like
Reactions: DPI
like this
However "Someone" didn't like what I said and reported it so the post got deleted for "Inappropriate content". I basically called BS on him being in charge of any kind of a competent IT staff if they were "Dreading" supporting Windows 10 in an enterprise environment.

You insulted me and my coworkers for simply reporting that we didn't like your god. Rules don't disappear just because infidels dare to utter blasphemies.
 
I'm sorry, none of your arguments convince me any of this is a good reason to have no recourse whatsoever if something goes wrong.

I'm not making any arguments for this. I'm pointing out that right now, with the development process that Microsoft is using, there's no way to allow permanent refusal of OS updates. They are cumulative now and the updates are interdependent. This is more than just a matter of Microsoft forcing updates, it goes to the very core of how Windows 10 is being developed. They'd have to drop this model and move to something else to allow refusal of updates. They can't simply do what they are doing and then allow user control of updates. It can't work. If you think you've see busted machines, try mixing interdependent updates with a system that allows users to refuse them. That's all I was trying to say.
 
So every application written to run for desktop Linux is 100% compatible with every version of Linux and has zero dependencies on any updates?
Basically that's what the distros do. They package linux with other programs and they make sure all of the dependencies are met. So more or less yes. Is there a possibility that something breaks? Of course it's software made by humans. The discussion isn't about software that never breaks. What you have discussed is that somehow there's no way for Microsoft to not do forced upgrades and keep everything compatible which they already do.
 
And this has it's own problems. Lots of different versions.



Unless you branch off different versions then you're going to create dependencies. There's soon going to be three different versions of Windows 10. So to validate an application assuming that every update is user selectable you'd have to validate at least three versions. And then the cumulative updates to each of those. Again, this is not a simple thing as some people portray.
Not really in reality.

I can have multiple versions of java installed and choose which one is active with a symlink. I can have many versions of kernels installed, and when I install the nvidia drivers, it builds a kernel module for each one automatically. In most cases it works quite well. Packages that depend on a kernel but don't know what kernel you have installed should use "DKMS". People with dependencies on <= or >= version of a package can specify that in the installation package and during install it will alert the user. Docker containers can also force a package to use specific versions of things & they remain that way AFAIK (I haven't used docker yet, but learning it is on my todo list).
 
I'm not making any arguments for this. I'm pointing out that right now, with the development process that Microsoft is using, there's no way to allow permanent refusal of OS updates. They are cumulative now and the updates are interdependent. This is more than just a matter of Microsoft forcing updates, it goes to the very core of how Windows 10 is being developed. They'd have to drop this model and move to something else to allow refusal of updates. They can't simply do what they are doing and then allow user control of updates. It can't work. If you think you've see busted machines, try mixing interdependent updates with a system that allows users to refuse them. That's all I was trying to say.

The problem is that in the real world software companies don't have the resources Microsoft does to throw at a problem. Every business of any decent size uses some form of ERP software where any version bump represents additional costs to the customer as every customized portion has to be redone. Business are not going to bear the burden of that cost, their customers are. This is even more prevalent in manufacturing where you simply do not touch a running system, ever. The PLC programming software always uses custom drivers that would need to be recompiled against every change in the OS to be re-certified and then every other part of that manufacturing process would need to be PPAP'd again. This will not happen. All Microsoft has done is ensured we'll be using Windows 7 for the next 20 years or until our vendors decide to go Linux.
 
Not really in reality.

I can have multiple versions of java installed and choose which one is active with a symlink. I can have many versions of kernels installed, and when I install the nvidia drivers, it builds a kernel module for each one automatically. In most cases it works quite well. Packages that depend on a kernel but don't know what kernel you have installed should use "DKMS". People with dependencies on <= or >= version of a package can specify that in the installation package and during install it will alert the user. Docker containers can also force a package to use specific versions of things & they remain that way AFAIK (I haven't used docker yet, but learning it is on my todo list).

And if a particular thing needs to use something that causes that system a problem? What you're describing here isn't the same thing as user controlled updates.
 
You insulted me and my coworkers for simply reporting that we didn't like your god. Rules don't disappear just because infidels dare to utter blasphemies.

Who's my god bud? I'm as neutral as they come on this forum when it comes to things like this. I railed against MS and Windows 8 for years, I have called MS out on every single misstep when it came to Win 10. I have stated repeatedly that I despise the practices employed by them concerning the upgrades and have not defended them a single time over it. However I haven't once let that displeasure blind me to the things they did correct with the OS or bias me against things that weren't applicable. The fact is all the things people hate about win 10 aren't applicable in an enterprise environment. I called you out on your BS plain and simple. You claim to be working for some team of IT people who all hold the same biases against Win 10 that No competent IT person who "Actually works in an enterprise environment" would have. I can state this without reservation because Windows 10 enterprise and windows 10 consumer (home, pro) aren't even remotely close to the same experience. I can state that because even IF you couldn't turn off all the unwanted telemetry, if you have network engineers worth their money, they can block ANY unwanted traffic at the firewall. If you cannot, then either my original statement about the competency of your team (Which I don't even believe exists) is true or my statement that you don't work in an enterprise environment is true. Either way I'm dead to rights on my original statement. Not one single statement you have ever made is applicable to an enterprise environment and every single person here who has obviously worked at that level is in agreement with me.

Right now you are just showing your blatant bias and frankly showing your ass. You are trying to lump me into the group that has blindly defended MS at every turn when I'm the one who has been utterly opposed to the majority of what they have done. I'm only defending specific things about Win 10 because I don't let my personal dislikes blind me to what they did right. The fact of the matter is Windows 10 in an Enterprise environment is functionally identical to Win 7. It does not report anything win 7 doesn't and moving forward in the long term there is zero reason to exclude it out of your normal upgrade schedules. It will be supported longer than win 7 and it will run on a larger variety of hardware than Win 7. That isn't to say companies on win 7 right now need to jump to win 10, no company should deviate outside their normal schedules.

So yes, I insulted your imaginary team or if they are real then your real team. Why? Because I have nothing but absolute contempt for IT people who let their biases blind them to their job and go around pushing flagrantly FALSE information.

Edit: By the way, the only one fanatically refusing to admit they are wrong is you. You are so entrenched in this blind refusal you are now attacking people like me who traditionally have been on your side. You are wrong about this..Period.
 
And if a particular thing needs to use something that causes that system a problem? What you're describing here isn't the same thing as user controlled updates.

I was responding to your post in general, not within the context of user controlled updates.

As per what I described above, you'd purposely have to install a NEW version (eg kernel 3.2.0-58) and it wouldn't "update" otherwise. That package is an updated kernel, but doesn't replace 3.2.0-57. It's an additional kernel you install.
 
I'm not making any arguments for this. I'm pointing out that right now, with the development process that Microsoft is using, there's no way to allow permanent refusal of OS updates. They are cumulative now and the updates are interdependent. This is more than just a matter of Microsoft forcing updates, it goes to the very core of how Windows 10 is being developed. They'd have to drop this model and move to something else to allow refusal of updates. They can't simply do what they are doing and then allow user control of updates. It can't work. If you think you've see busted machines, try mixing interdependent updates with a system that allows users to refuse them. That's all I was trying to say.
You keep saying "no way" and "impossible", so explain to me what's impossible about this:

Allow an advanced user to disable updates or revert back to a certain time period, however unless you are fully updated, you receive no support from Microsoft?

Anyway, if MS is going to continue to be as invasive as it's been with Windows 10, it makes me never want to switch to the damn thing. It's a complete paradigm shift of how it's handled its previous OS's and takes things in a direction I don't want for my system use. I simply use my system for too many things to risk MS screwing things up while I'm in the middle of a project. I guess moving forward I'll have a dual boot so I can run it for games and that's about it. This entire update model sends the message to me "if you're doing serious work, stay off Windows 10." Again, I always look at the worst case scenario first and 10's is a lot worse than previous Windows versions.

The problem is that in the real world software companies don't have the resources Microsoft does to throw at a problem. Every business of any decent size uses some form of ERP software where any version bump represents additional costs to the customer as every customized portion has to be redone. Business are not going to bear the burden of that cost, their customers are. This is even more prevalent in manufacturing where you simply do not touch a running system, ever. The PLC programming software always uses custom drivers that would need to be recompiled against every change in the OS to be re-certified and then every other part of that manufacturing process would need to be PPAP'd again. This will not happen. All Microsoft has done is ensured we'll be using Windows 7 for the next 20 years or until our vendors decide to go Linux.
This is it all over.
 
Status
Not open for further replies.
Back
Top