The Lounge is rated Safe For Work. If you're about to post something inappropriate for a shared office environment, then don't post it. No ads, no abuse, and no programming questions. Trolling, (political, climate, religious or whatever) will result in your account being removed.
If you figure out something new, holler. I've played a bit, and successfully taken ownership of the wuaueng.dll and some others, but still get '5' error with the batch file saying access denied. Maybe have to take ownership of svchost? Don't know - hesitant to play with that one.
so you replace 1 program that runs continuously in the background with another.
But one of those causes considerable grief when your machine restarts without your permission. And technically, it is not a replace! They both keep running. But such is life in this case. Checked, and the command prompt is stuck at 0% usage if that is any consolation.
just curious, (I'm not on 10), what about stopping it and renaming the service .exe file?
Might be possible, but there are a couple other background processes that Windows runs that might trigger the file to be reimplemented. And I'm not knowledgeable about them.
Everyone is wrong at least once in their life! If MS gave an option to use the old style update system, where a notification came in your task tray, I'd use it. But they don't, so spreading ways to get some control back is a market force. If everyone did so, they might read this message and add the option. Then I would not promote alternatives.
But if your machine is forcing a restart, that means you've been ignoring the "please restart" notifications for too long.
I can't ignore something it never gave me. That is the biggest problem with the current screwed up system.
Richard Deeming wrote:
And then promptly blamed Microsoft
Never did, so don't toss me into that camp.
It is fine if they keep the current system as default, for the people that only browse, and never leave projects open overnight. But give an option so power users can control their machine if they so wish. Then this thread wouldn't exist.
Without saving them first? You must have a decent UPS to be that confident that you won't lose power in the middle of the night.
David O'Neil wrote:
But give an option so power users can control their machine if they so wish.
Because "power users" will never click to delay an update indefinitely, then forget to apply the update, and get hit by malware, right?
It's a no-win situation. If they give you the option to delay indefinitely, you end up getting infected and infecting others. If they give you the option to delay for a finite length of time, it's never going to be long enough for some people.
Yes, there's room for improvement. But turning updates off completely is still not a good idea. It's like solving the problem of worn brake-pads in your car by removing the brakes!
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
We agree. And I do update, and don't recommend others don't. Point MS to this thread to get it improved.
Richard Deeming wrote:
Without saving them first?
Regardless of whether or not I save them, when Windows forces the update without telling me, I lose the entire workspace. Yes, I have to recreate it when I do the update, but I can take steps to mitigate it when I know about the impending update, like saving tab arrangements and such if I want.
I have lost stuff 3 times because of this issue in the past. And I never got notifications for any of those updates. Enough is enough.
Well, I started the rant in the other thread and I declare total bullshit. I bought Windows Professional for a good damn reason. I'm a professional. And if I have to save all my projects because my a**hole stupid OS forced a reboot... that's just stuck on stupid.
As I said earlier, you can polish the turd all you want, and in the end, you'll have a shiny turd. Tell you what, go into the MS server room and start pulling power plugs. See if there is an issue.
As a matter of fact, I DO have damn good UPS's on my LAPTOPS (battery - more UPS), there is no reason I should not be able to leave my machine up for weeks on end. MS' position is total and complete BS.
<italic>Stuck in a dysfunctional matrix from which I must escape...
"Where liberty dwells, there is my country." B. Franklin, 1783
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
We're all developers here. If updates are giving anyone such grief, they owe it to themselves to at least learn about Microsoft's Windows Update Server (WSUS). I suspect most of us on CP have an MSDN subscription, and have access to Windows Server. WSUS is a free add-on, is available from Windows Server 2003 onward, and it's rather trivial to install and configure. And it leaves you in total control of all updates.
It's certainly overkill for the average consumer, but we're not the typical bunch - most of us have multiple machines, and even more VMs, all of which need to be kept up to date - so even more reason to leverage the tools that are at our disposal.
Recently, I became older. Over the course of my life, this has been a disturbing trend. However, the alternative doesn't seem much more appealing. I'd be willing to "Benjamin Button" it for a few years, but that doesn't seem to be on the menu.
Now, don't get me wrong, I'm simply getting older. "I'm not old", he says, quickly concealing his gray hair.
I've noticed many older people ranting. It seems like it might be fun? So, I thought I'd experiment with it (in this post). I originally wanted to post this to my blog, but then realized I don't have one.
So, I'm posting it here instead. I'm hoping that the villagers will keep their pitchforks and Tiki torches in the shed. At the moment, I can't afford to pay a bridge troll its fare to pass.
So, anyhow, here goes...ranting powers activate...
I've been thinking a lot about software methodologies lately. Mostly, because there is no beer left in the fridge.
They always start out well-intentioned. "We keep falling behind our delivery schedules. Let's do something about that." Yeah!
Initially, much like a Mogwai, they start out all "cute and fuzzy". Then, someone feeds them after dark. Suddenly, they're trying to eat your face off.
OK, I digress, that might be some other critter. Honestly, I don't know much about Gremlins. I just know they're bad!
I think a better name might be software ideology. After the good intentions are long forgotten, the dogmatic elements become dominant.
"You can't do it that way." Why? Because, the methodology says its wrong.
We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:
Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan
That is, while there is value in the items on
the right, we value the items on the left more.
I continue to agree with absolutely every one of these goals. If anything, its almost an anti-methodology. I suspect, but cannot prove, the pain of those well-intentioned heroes.
However, it suffers the fate of most good intentions. It follows a life-cycle familiar to many of us.
Step 1: Save the World - Some people with good intentions, recognize a problem and try to fix it. "Let's write a few simple guidelines. That should help."
Step 2: Build a Better World - Inevitably, that damned imperfect "real" world refuses to cooperate. "It doesn't always work for us. Let's fuss with it. If we just add a few simple rules, it will be even better."
Step 3: Write a Book - People start to interpret or misinterpret those few simple rules. A couple more rules should add clarity. "These rules are a little unclear. Can someone maybe write a book on the topic?"
Step 4: Hire an Expert - Companies have difficulty consistently implementing the rules. A couple more rules are added to help. "We're having some trouble with those rules. Can we get one of the folks who wrote that book to help us with a lecture?"
Step 5: Get Certified - Companies recognize that people experience uneven success following the rules. A couple more rules are added to help. "Folks aren't consistently following the rules. Is there some certification they can get to make sure they understand?"
Step 6: Enforce The Rules - Companies recognize the results are still inconsistent. A couple more rules are added to help. "Folks are still inconsistently following the rules. Can we hire some management experts to help enforce them?"
Step 7: Build a Culture - Countless studies (with little peer review) conclude that this is THE WAY to develop software. "This is definitely the way to go, let's make it part of our corporate culture."
Step 8: Build a Religion - Evidence of a problem with the methodology seems to exist. "It didn't work for you? The methodology isn't wrong. You're just doing it wrong."
Step 9: Attend Seminars - – Fans of the methodology assemble. "Those dumb people still don't understand our methodology. Let's start a seminar so we can discuss it!"
Step 10: Recognize a Problem - The industry as a whole comes to realize the methodology is flawed, return to step 1. “Hey, this isn’t working. I heard about this new methodology. Let’s try it.”
I wish people would allow software methodologies to serve them instead of making it the other way around.
I wish people would recognize the wisdom in common clichés: all things in moderation, no solution fits all problems, etc.
If a methodology is working for a project, great! Use it. If its not, use a different methodology for a while.
Methodologies shouldn't be a suicide pact. Multiple methodologies can co-exist. Let's end the rule that new methodologies must kill off their predecessors. This isn't Thunderdome.
Ultimately, in the software industry, we're making sausages. It's sometimes an ugly business. However, if the product is of good quality and affordable, the process used to create it shouldn't matter too much.
Ranting wasn't as much fun as I hoped. I tried it. I don't think its the thing for me after all.
Ah well, there's beer in the fridge again...problem solved...ranting powers deactivate.
P.S. Apologies for originally posting this on Soap Box. After reading a few posts there, it seemed misplaced, so I moved it here. Long time author, but first new post on a forum, so hopefully I'm not too off base
The trouble with "methodologies" is that, sometimes, they fit the job at hand and the instigator/author gets all excited and writes a book about how well it all went and we should follow along and do the same thing, etc, ad infinitum blah, blah, blah.
The problem, of course, with this is that no 2 businesses are the same. No 2 groups of people are the same. And therein lies the rub. All processes, no matter how well orchestrated, are people driven. And people, for the most part, act like mindless cats and are impossible to herd in any meaningful way.
So, for me and me alone, the best approach has been to hire really smart people and let them get on with it. And they still all have personalities and characters and great ideas that tear down the "methodologies" and show them up for what they really are: a one size fits all problems that ends up being the problem.
Yeah, I like the notion of agile but I'm damned if I'll follow along slavishly. That is dumb.
Anyway, do what you want - people always do anyway.
ps I am also gaining age - it's been and is being a fun run.
Never let the bastards grind you down is the only pattern that really works for me.
Have a nice weekend, cats.
Keep your friends close. Keep Kill your enemies closer. The End
In my experience the problem is mostly just programmers who can't write decent software.
I've heard programmers say "software architecture isn't going to work for us, that's only nice in theory."
So no UI, business and data layers, no abstractions, no nothing.
No matter your software ideology, that's going to end bad (they were lucky that the software didn't change all that much).
Then I've seen software with a gazillion useless layers, just as bad.
Or software that took a non-DI library and used it as DI (the result was a very awkward method to instantiate objects when you need them, and no DI of course).
A completely wrong implementation of an ORM and the programmers who made the mess cursing the ORM (the problem really wasn't the ORM)...
Or a "core" library that every application depended on, but which changed almost daily.
These are programmers of all ages, not just the old farts.
No matter how clear or vague the business requirements are or how well your business structure is or how good the tools are you use, such software never ends well.
Maybe we should just learn to write software properly first.
After that we can worry about tools and methodologies.