It did every time it BSODed.
/BAH
It did every time it BSODed.
/BAH
I guess you have no experience.
/BAH
No. Those are the easy bugs to fix. The hairier ones are the deadly embraces, CATCH-22s, etc. There isn't any code bugs but timing bugs.
/BAH
How many bits have been tied to the wrong date/time by then? That was a serious problem which we had to think about.
/BAH
You know you said it. Why ask for a citation?
Kinda like you ... a bunch of small turds piled up to make an Archie. Are there many errors in the chunks of s*it that sum to you?
That's neither true, nor does it address my question.
Some of the errors in large systems are blamed on incorrect interface definitions between modules; modules crash because they are called with bad parameters. In that case the author of the module can claim, with some justification, that his code is correct, it's just being called wrong.
But I suspect that most big-system errors are true coding errors within modules. Given that, if we can ship 10,000 line bare-metal embedded programs - which have realtime responsibilities, interrupt handlers, all that stuff - with zero bugs, why can't the typically much smaller modules in something like Windows or Word or Adobe Reader be correct?
What sort of programming do you do? What's your bug rate?
John
Sure, once they are found by an army of beta testers and a lot of innicent users. But there are so many of them.
The hairier ones are
Windows is famous for unchecked buffer problems. That is, I think, a "local" problem. Nobody should do a memcpy without knowing what is going where and whether it will fit.
John
That is another one of your problems. You guess too much.
No guessing necessary when it comes to you, Archie. You are a certified asshole!
Nobody give a fat flying f*ck what you say, dumbass!
The
that
aShould be that much, NTP should be one of the earliest starting components. Part of the IPL/Boot process really. Long before starting multi-user interactive operation. On top of that most current machines have battery backed hardware clocks that should ride out a couple of months of non-operation. No more hand setting of the clock after the first install.
My guessed are eductated guesses.
/BAH
Do you really like to waste your time writing the same post again and again?
/BAH
Here, wussy, wussy, wussy, wussy...
Bwuahahahaha!
To think that we let retarded bastards like you take an oath and carry a weapon in the name of our nation's freedom.
It's a goddamned shame that you made it back on the sunny side of a body bag, you 4-F grade scumbag retard.
Here's a new question for you Archie:
Why/how do you decide to use any one of your various nyms? You responded to peterchoward69 using Archimedes' Lever and then responded a second time to the same peterchoward69 message as Bart!. Certainly you know that everyone recognizes that both identities are you, so why use multiple names?
Please note that this is a serious question and this posting is devoid of any derogatory comments. I expect you will be mature enough to respond in kind. Thanks.
He wouldn't be busy, he would be in jail. Down time never makes a good boss happy.
QNX has one "master nameserver", which is elected, one standby. That is it. The master nameserver takes registrations from server systems, and brodcasts these throughout the net.
User processes only need to ask locally, but there is a need for one master to control and disiminate state.
That is the ONLY core state needed, and this is just the mster copy of the map of what is where. Whenever you add network gateways, file systems (i.e. mount with a cluster-wide export) you need to inform the master nameserver. All other stuff goes directly from client to server.
There is a time service, with a small set of processes responsible for (external) ntp, internal time service, and responses to user processes.
-- mrr
Don't let AlwaysWrong rattle you. Better still just ignore the wrongness.
Have something to add? Share your thoughts — no account required.
Ask the community — no account required