the Windows kernel is proprietary. it will never happen. Bill Gates will be in charge until he isn't anymore. Steve Jobs lost for today. sorry Steve he's probably up in Alpha Centauri
Intel still has work to do. because nVidia will get mad. I can still get a 3DFX card to work. so whatever.
If such trend affects the long-term channel, then I am not ruling out on quitting Windows altogether. As a general observation, it is already painful to figure out the Group Policy and registry tweaks.
Bringing this back around to the future ... and thinking about what you've wrote about deleting and removing ... I agree that this is not the best way. Disabling the function is the better solution. You're Wrapper Script disables WU components online which--for the time being--is barely 'allowed' by Microsoft. It's allowed, but gets 'repaired' if the user does a sfc scan. If Microsoft does an 'inventory assessment' or looks to see about "mandatory services" it can easily decide that the OS is broken and then proceed to either force an unwanted repair or alert the user that their system is damaged and unsupportable, causing you--as a developer--no end of headaches. Microsoft is already doing inventory scans as discussed by this dude @GodHand here: So if we're thinking of the future, I think someone needs to start looking at how to disable the updating function offline. It's a bigger pain for the user since they have to do a fresh install. However, in the end, if it's done right, Microsoft sees the system as 'healthy' and (will hopefully) leave us to do what we want with regard to managing WU. As they say ... the devil is in the details ... I'm not the hero that can code this or do what needs to be done. I do think that it's a more achievable goal to consider how to implement an offline alteration of a WIM image versus trying to code an entire kernel--as worthy of a goal as that might be!! These are my final two-cents!
I often try to imagine a solution that is: Easy to adopt High Performing Does not put its developers in a position where they must fight a war of attrition vs. Microsoft Not very easy to imagine. The only thing I can see really meeting those criteria would be something like a ReactOS "distribution," which would allow end-users to choose between a limited vanilla configuration (with a squeaky-clean licensing pedigree) and an assortment of unofficial and often less-squeaky-clean options to hybridize real Windows kernel-space and user-space components with the official components, as required, to get various software running. Hence it would need to be a containerized solution for spinning up multiple Windows-like sandboxes and choosing how those sandboxes are allowed to interact. Virtualization -- real virtualization -- is as far as I'm concerned incompatible with bullet point #2. AFAIK there is nothing like that, now (unless we count various wine-based projects but these perpetually lag behind the latest-and-greatest era of software compatibility that many people really want). I think it would be an extremely labor-intensive undertaking to create such a thing. I also think it would be a challenge for such a project to stay out of trouble, as any level of success would immediately mark them as a threat to various profitable and infamously litigious institutions. A nice fantasy, but probably nothing more.
I believe, that is already there. After disabling some useless service, I got Critical Service Failed, abut 5 mins after boot or it just refused to boot at all with the same BSOD.
Correct, except for the part about Microsoft "repairing" changes done by the wrapper script. All changes done by the script will survive updating from 1607 to 1703 to 1709 to 1803 to 1809 through updates or with an iso, sfc, dism, anything you throw at it, because I've tried to make Windows defeat my script and it cannot. That's why I give a warning about sfc errors with my script since sfc can't repair it without uninstalling the script first. So far the only way Microsoft can repair the WU components in any way is if you uninstall the script. It's rock solid... so far, which is the point of this thread. So far I have made Microsoft my bitch with my script. But, with 1809, unlike previous versions like I mentioned in the OP, I had to remove system file permissions as TrustedInstaller in v2.5.4 (the latest version which is the only version that can do that). With the next version of Windows 10, who knows, I might not be able to remove permissions anymore without triggering a system alert. For instance, In 1809, if I take ownership and disable the Update Orchestrator tasks the system locks me out of ever running Task Manager again because it's blocked by a system alert that "this app has been blocked, blah blah...". The Update Orchestrator tasks are protected process introduced in 1809. In 1803 they were not protected. I bypass that problem by removing permissions from usoclient.exe and osrss.dll which are the files that the Update Orchestrator tasks try to run. The wrapper script is better than most people realize. This is not the pride of a developer speaking, it's an unbiased fact. And I didn't do it in a vacuum. A lot of people helped me with vital information. All I did was put it all into a comprehensive script. Actually, if you keep running the script until there are no more updates, and never run it again, Windows 10 will never update again until the end of time. With the next version of Windows 10, with the way my script operates currently without modifications, it could possibly completely break windows requiring a complete reinstall because of protected processes, but I won't let that happen. I test for things like that and modify the script accordingly ahead of time by trying to break bleeding edge versions of Windows in a VM which gives me roughly a 6 month window to adjust. You said it all in a nutshell right there. You "get it". And the problem is protected processes like the ones that protect 1809's Update Orchestrator tasks. More parts of Windows 10 will become protected in the future and devising a way to disable or bypass these processes is the topic of this thread. I can't predict the future, no one can. But a good start would be trying to find out what processes protect Update Orchestrator tasks and defeating them. This is only one example. With the people at MDL's minds working together we can slay this dragon, or at least work around it. I have no doubt that Microsoft is going to only get more serious about defeating our methods to control updates. So far, they have failed, but this is a chess game and we need to try to anticipate their next move...
Exactly. Protecting certain services and update orchestrator tasks is only the beginning, I think. The "removing permissions from system files" method that I use still works, but for how long? Microsoft is beginning to get very serious about our efforts to control updates. By the way, what exact version of Windows 10 and what service was it that caused the blue screen?
I've been talking to you for some time now not to enter the OS with chainsaw, the worst solution is to always and constantly learn from your own mistakes. So, Do not miss it Control Windows Update
At least Linux, or I should say the majority of Linux distros, are offered for free. The alternative is to pay $100 for Windows 10 Home or $150 for Windows 10 Pro and have Microsoft not give a s**t about you.
my feeling saying they like to hold Linux to them self and not make mainstream they know if its will be easy as windows, many will just jump windows and linux wont be control by them anymore Sméagol will approve
Don't get me wrong, I don't complain. But until Linux is as simple to use as Windows "year of Linux" never.
Do not wait for Santa Claus, maybe he never comes https://forums.mydigitallife.net/th...ows-update-service.72203/page-46#post-1490980
I use LTSC 1809. I use gedit*whoops* gpedit.msc to tell windows to notify before download or install of updates, tell it to use a bogus intranet (caintgetnowhere.no) source, tell it not to include driver updates with windows updates, disable windows updates service, take ownership of registry entries and change them to disable windows update and Windows Update Medic service...and probably a few more things I forgot to mention. Then I plug in my Plantronics 515HD headset (USB) that works just fine with the default driver...and Windows STILL goes straight to windows updates, fetches and forces in a shi##y Dolby©® *Fake* Surround Sound driver that 100% breaks my headset so it produces only clicking sounds. Windows needs to just die, and Linux needs to become the mainstream.