|
Rajesh R Subramanian wrote: I thought that's exactly what Randor said:
Not quite. Delaying something doesn't mean it'll magically stop from a reboot without your knowledge when it finally does decided to download a patch. It just simply defers the "magical reboot". Your server can still go down willy nilly, just 180 days later than everyone else.
Rajesh R Subramanian wrote: One could argue that the exact opposite of this might happen (both opinions being predictions anyway), but only time will tell what would happen.
One could, but then they'd be wrong.
Jeremy Falcon
|
|
|
|
|
CoreOs already does that, they have it as one of the reasons to choose them[^].
|
|
|
|
|
Keep in mind I'm new to containers but even with that I could see it... almost. Not so much in a server environment though. And I'm sure some people will use a container on a server but I digress.
Jeremy Falcon
|
|
|
|
|
Randor wrote: It seems perfectly reasonable to give the server administrator several days or perhaps weeks to perform a manual reboot. if that does not happen... force the update.
Absolutely NOT. Computer systems are tools of the business, not the other way around.
The vendor does not own the environment, does not manage the environment, and has absolutely no say in how the environment is managed. They can recommend, but it is NOT their call.
I have worked in complex, highly regulated environments where any computer rebooting in the middle of a process will cause (at least) hundreds of thousands of dollars in damage, not including loss of business due to loss of confidence by the customers. People get fired for doing anything that negatively affects such processes, so I don't expect any OS that can force reboots will be allowed.
|
|
|
|
|
BryanFazekas wrote: Absolutely NOT. Computer systems are tools of the business, not the other way around.
It's always easy to see when someone is speaking from experience or not. You sir, sound like you're speaking from experience.
BryanFazekas wrote: The vendor does not own the environment, does not manage the environment, and has absolutely no say in how the environment is managed. They can recommend, but it is NOT their call.
BryanFazekas wrote: I have worked in complex, highly regulated environments where any computer rebooting in the middle of a process will cause (at least) hundreds of thousands of dollars in damage
I knew it. I could tell this before I got to this part. I think anyone with any real server admin experience would agree with you and I.
Jeremy Falcon
|
|
|
|
|
And how much do you pay out from those hundreds of thousand dollars to those clients who lost everything using your service because a timing issue existed in your system unpatched? Or because Google is your competitor[^]?
|
|
|
|
|
Peter Adam wrote: And how much do you pay out from those hundreds of thousand dollars to those clients who lost everything using your service because a timing issue existed in your system unpatched?
This has nothing to do with the point of allowing a known defect (unmanaged server reboot) into a business process.
|
|
|
|
|
Jeremy Falcon wrote: There's no way to stop this thing from magically rebooting I think that I can say with pretty much absolute certainty that the adjective I would have used is not "magically".
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
Touché.
Jeremy Falcon
|
|
|
|
|
I don't get how you want to 'keep going 24/7' and have this running on a single server and not in a cluster (in VM's on a Nano Server or something...)
|
|
|
|
|
Fair enough, but still doesn't mean a magical reboot is a good idea.
Jeremy Falcon
|
|
|
|
|
So Netflix reboot there servers all the time, and they have no idea when it's going to happen. It makes their system more robust.
I know they are an extreme example, but I think it shows that if you can't handle a machine reboot, it means that your architecture is wrong for 24/7 up time.
If you are designing applications for a cloud environment then following the 12 factor approach is a good start, specifically The Twelve-Factor App - Disposability[^]
|
|
|
|
|
While I agree, that in the context of something redundant, "underlying OS for a cloud", etc. that's just a node on a cluster of machines, a single machine reboot can be acceptable. I don't agree that forcing it upon the user within a guest VM or legit server is prudent. And since Windows update tends to release updates for all at the same time, it would force more than one machine to reboot at similar times. I don't agree with that, it takes the assumptions that server admins are smart enough to figure out how to keep machines up to date.
Jeremy Falcon
|
|
|
|
|
After giving this much thought, I'm going to side with Microsoft on this one. A server is intended to be part of a domain and to therefore adopt the domain policies once deployed. Until then, it should default to the most fanatically secure/paranoid state possible. Public facing system deployment should be done with deliberation requiring opt-out options for anything related to security.
|
|
|
|
|
You disagreeing with me... again? Say it isn't so.
I don't agree with MS. I've administered ISPs. Under no circumstance should a machine go down without the admin having a say-so in it. This takes the assumption a sys admin is a retard who can't patch his/her system without being spoon fed.
Jeremy Falcon
|
|
|
|
|
This is about a default configuration, not a deployed configuration. A server should never be deployed in its default configuration. The unfortunate reality is that many admins aren't doing due diligence in setting up servers. The number of unpatched servers of all OS varieties is astonishing.
Another point is that Microsoft intends Windows Server to be used on a domain with domain policies in place, not stand-alone.
|
|
|
|
|
I know it's about a default configuration. I also know it's not nearly as easy to avoid this now. And I know there are stupid admins out there. However, magical default reboots are silly. And stand-alone or cluster doesn't matter.
I don't expect you to agree with me. Seriously Joe. I get how this pattern works between us. You never reply to my posts unless it's to disagree with me. Been years now bro. Seriously. Tell me something nice.
Jeremy Falcon
|
|
|
|
|
... if they had put this[^] into the movies.
Don't watch if you like Ewoks.
The language is JavaScript. that of Mordor, which I will not utter here
This is Javascript. If you put big wheels and a racing stripe on a golf cart, it's still a f***ing golf cart.
"I don't know, extraterrestrial?"
"You mean like from space?"
"No, from Canada."
If software development were a circus, we would all be the clowns.
modified 5-Nov-16 16:56pm.
|
|
|
|
|
Puerile.
If you have an important point to make, don't try to be subtle or clever. Use a pile driver. Hit the point once. Then come back and hit it again. Then hit it a third time - a tremendous whack.
--Winston Churchill
|
|
|
|
|
Robot Chicken. 'nuff said.
|
|
|
|
|
Daniel Pfeffer wrote: If you have an important point to make, don't try to be subtle or clever. Hear, hear!
Daniel Pfeffer wrote: Puerile. True, but that would be about 10 years more than George Lucas was aiming for with the Ewoks. We're getting there.
The language is JavaScript. that of Mordor, which I will not utter here
This is Javascript. If you put big wheels and a racing stripe on a golf cart, it's still a f***ing golf cart.
"I don't know, extraterrestrial?"
"You mean like from space?"
"No, from Canada."
If software development were a circus, we would all be the clowns.
|
|
|
|
|
CDP1802 wrote: if you like Ewoks. You can use that prhase if you ever have to explain the empty set to someone.
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
To @sanderrossel
Based on our last conversation I just published an article containing information about table types (or UDT's in Oracle) along with few other mechanisms to pass data to the database.
So if still interested, have a look
|
|
|
|
|
Nice article, thanks for thinking about me!
|
|
|
|
|
Since it is sooo slow in the lounge today, I was forced to peruse some of the recent articles...it was either that or do work. Anyhow, I just came across my favorite new quote from this article:
Introduction to the 'Fail Fast!' Principle in Software Development[^]
Quote: If a function be advertised to return an error code in the event of difficulties, thou shalt check for that code, yea, even though the checks triple the size of thy code and produce aches in thy typing fingers, for if thou thinkest 'it cannot happen to me', the gods shall surely punish thee for thy arrogance." - Harry Spencer
"Go forth into the source" - Neal Morse
|
|
|
|