Yet another sleep



  • Function names changed to protect the legally - and programmatically - stupid.

      // OP: Identical arguments are passed to each blocking database function call
      // OP: result of func is just a simple enum value
      if (funcToQueryOneIntFromDb(...) == SomeEnum.A ||
          funcToQueryOneIntFromDb(...) == SomeEnum.B ||
          ...
          funcToQueryOneIntFromDb(...) == SomeEnum.X) {
         pushMessageFromUpstreamSystemToDownstreamSystemViaESB(theMessage);
      }
    

    So, rather than using a temp to hold the value and compare the temp to each of n constants, or worse, using a map, they do a blocking hit to the database to query the same value n times.

    This is done at the core of a very deeply nested loop (in upper layers of function calls, so it's not intuitively obvious at this level).

    I optimized the system to query this one value along with all the other data that's queried for the message, at one time. The funcToQueryOneIntFromTheDb() call got replaced with a local getter. Needless to say, this pushed the messages to the downstream system a whole lot more quickly.

    The downstream folks got the same messages we got - both from the upstream system. Our system acts as a kind of pipe-filter before passing it on. The downstream system was supposed to update the record they already had with the record we sent them. Since our system was to take some amount of time (greater than zero) to process, they would always have a later timestamp on the messages from us than on the corresponding message from the common upstream system.

    Not quite.

    The downstream folks started complaining that we were sending messages to them with timestamps earlier than timestamps on the corresponding messages from the upstream system.

    ?

    Turns out the clocks on the machines were not being synchronized. By speeding up our system, I shortened the time interval between receipt and broadcast sufficiently such that the done-timestamp on our box was before the done-timestamp on the upstream system.

    This broke all kinds of things (sorting, reporting, ...).

    The clock-synchronization problem has reared its head before, and clearly the SAs have no clue how to do it properly. The solution?

    Well, it worked for the other speedups, so put in a configurable sleep before setting the timestamp and sending the message downstream.

    Wait, can't I just do something like: setTimestamp(<now>+30seconds)?

    No, that would be falsifying data.

    So making our system just stop and die for a minute is better?

    I offered to build a small class that uses Java's Timer features so that I could just have a thread wake up periodically and send whatever messages were still sitting around waiting for time to pass, but was told absolutely not because it all has to be done as part of the wrapper transaction.

    I don't know whether to laugh or cry.



  • Try both... that's what I'm doing now.... :'D



  • Agreed. Both laugh and cry. OMFG. Is this place for real or is snoofle the most magnificent writer of IT fiction on the planet?

    Don't bother answering. I've seen mirror images of a few of the things he's posted occurring right here where I work.

    Crap like this would make me want to eat my offspring. Assuming I had any offspring to eat. I could eat other people's offspring but that would just be weird.



  • You don't copy code snippets like that into an email and send it to the entire dev list accompanied by a comment such as "BAHAHAHAHA"?

    Because we do that.

    It helps— and not just in a venting way. It actually helps to improve overall code quality.

    We do get sad since pretty much every single bit of code we see from third parties now looks horrible and dumb to us.


  • ♿ (Parody)

    @dhromed said:

    You don't copy code snippets like that into an email and send it to the entire dev list accompanied by a comment such as "BAHAHAHAHA"?

    Because we do that.

    It helps— and not just in a venting way. It actually helps to improve overall code quality.

    Pride is one of the most dangerous things to have in a developer, at least to the extent that it prevents him from learning from criticism when he does something stupid. And everyone does. This sort of thing works to either drive out the types who aren't willing to learn from their mistakes or improves the overall effectiveness of the team (not to mention the code).



  •  I told you at the last sleep thread, snoofle. Once you get to optimize something again, you should just add the sleeps, and make the computation take the same time as it did before.

    No reason to wait untill it creates problems. Be proactive.

    (Now, more seriously, why can't you just synchronize the clocks?)



  • From what we know about their servers, probably adding a time sync service would cause them to spontaneously combust.


  • ♿ (Parody)

    @Mcoder said:

    Now, more seriously, why can't you just synchronize the clocks?

    They're on a budget! NTP servers don't just grow on trees, you know.



  • @Mcoder said:

    why can't you just synchronize the clocks?
    *I* can't; the SAs could, if they knew how. Apprently they don't, and they won't take guidance from us lowly developers.

    You, Good Sir, have proposed common sense, and this company will have none of that!



  • @boomzilla said:

    when he does something stupid. And everyone does.
    I disagree; I did not write any stupid code while I wrote this comment. Your statement is clearly false.



  • @snoofle said:

    @Mcoder said:

    why can't you just synchronize the clocks?
    *I* can't; the SAs could, if they knew how. Apprently they don't, and they won't take guidance from us lowly developers.

    You, Good Sir, have proposed common sense, and this company will have none of that!

     

    Synchronizing the clocks may be common sense, and may be a good idea, but it won't do more than work around this utterly broken design. Code that uses timestamps for anything more complicated than identifying log entries needs very careful scrutiny. Code that uses timestamps derived from multiple sources to decide what's up to date and what's not needs no such scrutiny - it needs tossing out and replacing with something based on sequence numbers.

     



  • If downstream systems need to be able to reconstruct the order of messages properly this seems to call for Lamport timestamps or a vector clock. Basically an advanced version of sequence numbering.

    But if the powers that be can't even be convinced to synchronize their server clocks getting to implement something like this might very well be impossible.



  • I see nothing broken in a design which uses timestamps to determine if an update is applicable to a record. 

     Ntp is an excellent method for synchronising a collection of services across multiple machines (ensuring the same ordering of events, detecting delayed reporting of events seen via a different path, etc.) is easily implemented using timestamps. Unless your servers are on a network which absolutely must not have internet connectivity _and_ you can not afford, for space, power of budgetary reasons to run a GPS ntp source, then why add inordinate complexity and a multitude of failure modes in trying to have systems to issue sequence numbers.

     Any organisation whose sysadmins are not capable of getting ntpd to work on their clients has an HR problem - they are hiring incompetents. It's not magic, almost any problem you are ever likely to encounter will have pages of hits in Google from others who've arelread crossed that bridge.

     




  • Periodically:

    - Ping downstream server, note round-trip time

    - Ask downstream server "What's the time?"

    - Get response, subtract half of RTT, compare with system time- this is how far the clocks are desynchronised

    On sending messages:

    - If downstream server is running slow, wait for this amount of time before timestamping/sending messages

    - If downstream server is running fast, don't wait at all (not necessary)

     

    Result: you built the system the SA's asked for with more or less the best performance it could have, and got to exercise your brain about as well as a medium-difficulty sudoku whie distracting yourself from the cavalcade of witless fuckery that seems to surround you.



  • Hmm... depending on the language, there should be a class that lets you update the system time.  So what you can do, is if you get a message that is later than your system time, update your system's time to be 1 millisecond ahead of it.  So you now have a ninja way of syncing the clocks and a perfect wtf surprise for the next programmer that inherits your code after you leave.


  • Discourse touched me in a no-no place

    @orange_robot said:

    Periodically:

    - Ping downstream server, note round-trip time

    - Ask downstream server "What's the time?"

    - Get response, subtract half of RTT, compare with system time- this is how far the clocks are desynchronised

    On sending messages:

    - If downstream server is running slow, wait for this amount of time before timestamping/sending messages

    - If downstream server is running fast, don't wait at all (not necessary)

    Your triangular wheel resembles the round wheel of NTP.... just.



  • @PJH said:

    Your triangular wheel resembles the round wheel of NTP.... just.
     

    In three points!



  • @PJH said:

    @orange_robot said:

    Periodically:

    - Ping downstream server, note round-trip time

    - Ask downstream server "What's the time?"

    - Get response, subtract half of RTT, compare with system time- this is how far the clocks are desynchronised

    On sending messages:

    - If downstream server is running slow, wait for this amount of time before timestamping/sending messages

    - If downstream server is running fast, don't wait at all (not necessary)

    Your triangular wheel resembles the round wheel of NTP.... just.
     

    If your managers tell you they don't want wheels, give them a Circular Transportation Facilitation Device that you just invented.  IMHO "don't reinvent the wheel" is a lower priority commandment than "make software that doesn't suck".

     



  • @jes said:

    I see nothing broken in a design which uses timestamps to determine if an update is applicable to a record. 

     Ntp is an excellent method for synchronising a collection of services across multiple machines (ensuring the same ordering of events, detecting delayed reporting of events seen via a different path, etc.) is easily implemented using timestamps. Unless your servers are on a network which absolutely must not have internet connectivity _and_ you can not afford, for space, power of budgetary reasons to run a GPS ntp source, then why add inordinate complexity and a multitude of failure modes in trying to have systems to issue sequence numbers.

     Any organisation whose sysadmins are not capable of getting ntpd to work on their clients has an HR problem - they are hiring incompetents. It's not magic, almost any problem you are ever likely to encounter will have pages of hits in Google from others who've arelread crossed that bridge.

     

     

    The problem here is that you still have limited accuracy when you synchronize clocks over a network. As your code becomes faster / sends messages faster you will at the same time need more precise synchronization. If you use a distributed sequence numbering scheme you side-step the whole clock-synchronization and accuracy issue and make your system more robust.

    I admit that it's more complex than using system timestamps. What you use depends on the expected timings between messages (no need to do this if responding to a message takes >100ms for example) and on how problematic occasional incorrect results are.



  • Why exactly does the proxy have to add a timestamp?



  • @boomzilla said:

    Pride is one of the most dangerous things to have in a developer, at least to the extent that it prevents him from learning from criticism when he does something stupid.
     

    Not sure on that front.

    Someone having pride in what they do, I understand. A developer exhibiting a stubborn mindset that their code cannot be improved in any way is dangerous.

    Fundamentally, for someone to improve, there's got to be acceptance that things are not as good as they could be. Plenty of programmers take pride in improving themselves and the quality of their work; I'd argue that those who ignorantly believe theirs to be the opitimal solution isn't pride.


  • Discourse touched me in a no-no place

    @witchdoctor said:

    The problem here is that you still have limited accuracy when you synchronize clocks over a network.
    You can get millisecond accuracy over a local network with NTP. (And 10's of milliseconds over the internet.)



  • Hmmm....

    @snoofle said:

    I optimized the system to query this one value along with all the other data that's queried for the message, at one time.
     

    You really meant:

    @snoofle said:

    I changed the code to make fuller use of the processor and cause the understressed CPU fans to barf again.

    Now for the next bit:

    @snoofle said:

    @Mcoder said:

    why can't you just synchronize the clocks?
    *I* can't; the SAs could, if they knew how. Apprently they don't, and they won't take guidance from us lowly developers.

    You, Good Sir, have proposed common sense, and this company will have none of that!

     

    Something to hit them with: if they need to report intrusion detection attempts or security violations, then logs need to be accurately timestamped. Without some NTP in place, forensics won't trust logfiles. Can you slap management with some legal compliance?

     

     


  • ♿ (Parody)

    @Cassidy said:

    @boomzilla said:

    Pride is one of the most dangerous things to have in a developer, at least to the extent that it prevents him from learning from criticism when he does something stupid.

    Not sure on that front.

    Someone having pride in what they do, I understand. A developer exhibiting a stubborn mindset that their code cannot be improved in any way is dangerous.

    Fundamentally, for someone to improve, there's got to be acceptance that things are not as good as they could be. Plenty of programmers take pride in improving themselves and the quality of their work; I'd argue that those who ignorantly believe theirs to be the opitimal solution isn't pride.

    Yes, like I said (emphasis added). Maybe pride isn't the right word. A better way of putting it is that they take criticism of their code as criticism of their person.



  • @snoofle said:

    @Mcoder said:
    why can't you just synchronize the clocks?
    I can't; the SAs could, if they knew how. Apprently they don't, and they won't take guidance from us lowly developers.

    You, Good Sir, have proposed common sense, and this company will have none of that!
    I wonder if you set up a script to auto-refresh the built-in time sync command's documentation (and all OSes have one) they'd notice.



  •  @PJH said:

    @witchdoctor said:
    The problem here is that you still have limited accuracy when you synchronize clocks over a network.
    You can get millisecond accuracy over a local network with NTP. (And 10's of milliseconds over the internet.)

     

    I didn't know that. So in a local network you'd only need to worry about this when you get >1000 messages per second with interdependencies that you need to accurately sequence.

    Ok, I admit that in the vast majority of cases time synchronization will be enough. 



  • @boomzilla said:

    @Cassidy said:

    @boomzilla said:

    Pride is one of the most dangerous things to have in a developer, at least to the extent that it prevents him from learning from criticism when he does something stupid.

    Not sure on that front.

    Someone having pride in what they do, I understand. A developer exhibiting a stubborn mindset that their code cannot be improved in any way is dangerous.

    Fundamentally, for someone to improve, there's got to be acceptance that things are not as good as they could be. Plenty of programmers take pride in improving themselves and the quality of their work; I'd argue that those who ignorantly believe theirs to be the opitimal solution isn't pride.

    Yes, like I said (emphasis added). Maybe pride isn't the right word. A better way of putting it is that they take criticism of their code as criticism of their person.

     

    It's not so much that it isn't the right word as that it's two contradictory words rolled into one.

    What you're talking about is hubris.  It's about arrogance, competition and enmity, and can be summed up by the phrase "I am better than you."  It's known as one of the classical Deadly Sins for a very good reason.

    What Cassidy's talking about, which is also known as "pride," is something completely different: recognition of self-improvement.  It can be summed up by the phrase "I am better than I used to be," and it leads people to improve not only themselves, but everything that they're a part of.  Hubris, by contrast, inspires people to grow taller, as it were, by cutting down those around them.

    It's a shame our language uses the same word for diametrically opposed concepts.  It makes it needlessly difficult to have an effective conversation about them.

     



  • @boomzilla said:

    Yes, like I said (emphasis added). Maybe pride isn't the right word. A better way of putting it is that they take criticism of their code as criticism of their person.

    Okay... now you've emboldened those words, I can see them. Guess we're barking up the same tree after all.

    @Mason Wheeler said:

    Hubris/pride

    That.

    @Mason Wheeler said:

    It's a shame our language uses the same word for diametrically opposed concepts.  It makes it needlessly difficult to have an effective conversation about them.

    But makes for great flame fodder on forums, mind.


  • Discourse touched me in a no-no place

    @witchdoctor said:

     @PJH said:

    @witchdoctor said:
    The problem here is that
    you still have limited accuracy when you synchronize clocks over a
    network.
    You can get millisecond accuracy over a local network with NTP.
    (And 10's of milliseconds over the internet.)

     

    I didn't know that.

    What are your perceptions with NTP then? (This isn't a dig at you personally - I'm interested in how people who haven't dealt with NTP perceive how 'magic' happens)

    I'm guessing this sort of thing hasn't crossed your desk, so you have some preconceived idea of what NTP does - if you can do it without looking it up, how do you think it works?


  • @PJH said:

    @witchdoctor said:

     @PJH said:

    @witchdoctor said:
    The problem here is that
    you still have limited accuracy when you synchronize clocks over a
    network.
    You can get millisecond accuracy over a local network with NTP.
    (And 10's of milliseconds over the internet.)

     

    I didn't know that.

    What are your perceptions with NTP then? (This isn't a dig at you personally - I'm interested in how people who haven't dealt with NTP perceive how 'magic' happens)

    I'm guessing this sort of thing hasn't crossed your desk, so you have some preconceived idea of what NTP does - if you can do it without looking it up, how do you think it works?

    Without having read the documentation I was thinking it periodically updates the system clock to a reference time. But with network lag and slightly different speeds on different clocks that would never get you to 1ms precision.

    So now that I think about it it needs to do a few more things:

    - handle network lag (maybe two packets with time stamps and measure the difference between the expected time of arrival and the actual one?)

    - More adjustments to the system clock than just setting the time (is there an API for that? I don't know without looking things up)

    - Most likely a few more things I'm still missing

    Edit: I do remember that I read some things about this a few years ago, but I didn't know which precision you get from it.



  • @witchdoctor said:

    So now that I think about it it needs to do a few more things:
    NTP has two components - one that synchronizes the clock (which it does while measuring the latency between itself and the server it's synchronizing with), and another that does drift correction (the client measures how fast the local clock desyncs with the remote one, and provides corrections for this, allowing it to make less requests over the network). Clock adjustment is also not done by changing the time directly (except maybe at startup, and only if the clock is too badly out-of-sync), but by speeding up or slowing down the system clock until it gets in sync. This way you don't get jumps, and the clock never goes backwards.



  • @ender said:

    @witchdoctor said:
    So now that I think about it it needs to do a few more things:
    NTP has two components - one that synchronizes the clock (which it does while measuring the latency between itself and the server it's synchronizing with), and another that does drift correction (the client measures how fast the local clock desyncs with the remote one, and provides corrections for this, allowing it to make less requests over the network). Clock adjustment is also not done by changing the time directly (except maybe at startup, and only if the clock is too badly out-of-sync), but by speeding up or slowing down the system clock until it gets in sync. This way you don't get jumps, and the clock never goes backwards.

    Ah, so I wasn't too far off in what I remembered but did get a few details wrong. This is why designing protocols in a forums post would have been a bad idea :P



  • @jes said:

    Ntp is an excellent method for synchronising a collection of services across multiple machines (ensuring the same ordering of events, detecting delayed reporting of events seen via a different path, etc.) is easily implemented using timestamps. Unless your servers are on a network which absolutely must not have internet connectivity and you can not afford, for space, power of budgetary reasons to run a GPS ntp source, then why add inordinate complexity and a multitude of failure modes in trying to have systems to issue sequence numbers.

    Whoever said your internal network NTP servers have to have the right time?  They don't.  They just need to agree with each other, close enough for NTP's purposes.  You can get that by having, say, six NTP servers, each of which is configured to use the other five for NTP.  Then you manually sync any of those servers that haven't gotten in line with the others just from having NTP servers defined, and you're done.  You could do this with fewer NTP servers, too, but the fewer servers you have, the more dodgy it'll be.  At two NTP servers, it's quite broken, as NTP fundamentally needs multiple servers, and each of those servers would only have one.  Even beyond the NTP protocol issues, the two machines would dance around each other's idea of what the correct time it is - when server A moves back to meet up with server B, server B moves forward to meet up with server A.  They might get close enough for Snoofle's purposes, but it would be far less than ideal.

    That having been said, they apparently never do anything sensible, except, on occasion, accidentally hire someone who knows something as a contractor.  As such, the two NTP server self-syncing setup might be the only style of NTP they'd accept...

    @jes said:

    Any organisation whose sysadmins are not capable of getting ntpd to work on their clients has an HR problem - they are hiring incompetents. It's not magic, almost any problem you are ever likely to encounter will have pages of hits in Google from others who've arelread crossed that bridge.

    I used to work for an organization which cobbled their own time synchronization solution together, "because NTP was too hard."  After I was there for about a year, I looked into what it would take to do actual NTP, because their solution broke so often it wasn't funny...  Well, at least, it wasn't at the time.  Now, it'd be hilarious, if I could remember the details.  It turned out, Setting up NTP was far easier than setting up what they'd eventually cobbled together.

    @witchdoctor said:

    So in a local network you'd only need to worry about this when you get >1000 messages per second with interdependencies that you need to accurately sequence.

    Actually, so long as it's still pairs of messages, and the pairs always come in at > 2 milliseconds apart (because source B gets its data from source A about the same time source A sends its data to the client), you could theoretically handle billions of messages per second with interdependencies without having a real sequencing problem.  It's only if there's a real race condition that you'd have timing issues still.



  • @tgape said:

    @witchdoctor said:
    So in a local network you'd only need to worry about this when you get >1000 messages per second with interdependencies that you need to accurately sequence.

    Actually, so long as it's still pairs of messages, and the pairs always come in at > 2 milliseconds apart (because source B gets its data from source A about the same time source A sends its data to the client), you could theoretically handle billions of messages per second with interdependencies without having a real sequencing problem.  It's only if there's a real race condition that you'd have timing issues still.

     

    I admit it, I'm a bit paranoid about anything running in parallel. I prefer things where you can throw whatever you want at it and it doesn't break because especially in a place like in the OP I can easily imagine someone actually adding something that has a race condition that needs to be handled by explicit sequencing.

     



  • @jes said:

    I see nothing broken in a design which uses timestamps to determine if an update is applicable to a record.

    Then I hope nobody ever puts you in charge of a project sensitive to event ordering.

    @jes said:

    Ntp is an excellent method for synchronising a collection of services across multiple machines

    Doesn't matter how good NTP is, or how good the network is; there will always be some residual uncertainty in the clock sync, and that uncertainty will always give rise to race conditions. Timestamps are simply the wrong tool for keeping track of event ordering.

    @jes said:

    why add inordinate complexity and a multitude of failure modes in trying to have systems to issue sequence numbers.

    If you seriously believe that sequence numbering solutions like Lamport timestamps or even vector clocks are more complicated than NTP, then I'm afraid you are TRWTF.

    Honestly, some days I wonder why computer scientists bother inventing round wheels when there are so many developers who cling so lovingly to their self-invented square ones.

     

     



  • @flabdablet said:

    @jes said:

    I see nothing broken in a design which uses timestamps to determine if an update is applicable to a record.

    Then I hope nobody ever puts you in charge of a project sensitive to event ordering.


    Well, since you know everything, then you'll know that I have done exactly that, did use NTP and the project was quite successful - the software I developed remained in production for over 12 years

    @flabdablet said:


    @jes said:

    Ntp is an excellent method for synchronising a collection of services across multiple machines

    Doesn't matter how good NTP is, or how good the network is; there will always be some residual uncertainty in the clock sync, and that uncertainty will always give rise to race conditions. Timestamps are simply the wrong tool for keeping track of event ordering.


    Those of us who actually practice software engineering are aware of both the practicalities and the limitations. If events which have to be distinguished by ordering[[ are known to occur at intervals greater than the uncertainty of ntp synchronised clocks, then NTP is an excellent solution. If not, then a competent developer will not use NTP.

    @flabdablet said:


    @jes said:

    why add inordinate complexity and a multitude of failure modes in trying to have systems to issue sequence numbers.

    If you seriously believe that sequence numbering solutions like Lamport timestamps or even vector clocks are more complicated than NTP, then I'm afraid you are TRWTF.

    Honestly, some days I wonder why computer scientists bother inventing round wheels when there are so many developers who cling so lovingly to their self-invented square ones.


    Sometimes I wonder why arrogance seems to be a requirement for aspiring developers. More experienced ones learn their trade and select the tools to fit the requirements, both present and expected future ones. 

    Yes, I do believe that where ntp's resolution is sufficent to meet requirements (and snoofle's original posting did not suggest that it wasn't), then using a well engineered, well understood, widely deployed system which is available on most platforms, requires nothing more than simple configuration to set up and keep running and provides a reliable, quite reasonably accurate clock easily accessible within most programming languages sounds like a good idea. That there are other techniques available is not in dispute. That they are more complicated to integrate into a software system seems to me to be likely to be true. Neither of the techniques you mention are embedded at the lowest level of support libraries, their use will require significant intrusive changes in every application which forms part of the system. Gettimeofday() and its equivalent are available and require trivial work to incorporate.

    But of course, you had to make your unfounded claims in the hopes you would demonstrate a wider knowledge of systems than someone who posted a quite reasonable response and who may in fact, have an equal level of knowledge to yours without the encumberance of a vastly inflated ego. 

     



  • @flabdablet said:

    If you seriously believe that sequence numbering solutions like Lamport timestamps or even vector clocks are more complicated than NTP, then I'm afraid you are TRWTF.

    I understand NTP quite well but I have absolutely no idea what are those things you talk about. I tried to read the Wikipedia article but when I saw the funny symbols like that sideway anarchist logo I gave up.

    If this is a competition to explain a simple solution that even an uneducated overpaid consultant like me can understand and maintain, jes wins. If the competition is about name-dropping complicated stuff that only recent CS majors or people with severe social disorders can understand and maintain, then congratulations, you are the King of Unmaintainable Complicated Stuff.


  • Discourse touched me in a no-no place

    @jes said:

    the software I developed remained in production for over 12 years
    We have a winner for this particular DSW!!



    Incidentally, is your 12 year old software still fit for purpose?



  • @PJH said:

    @jes said:
    the software I developed remained in production for over 12 years
    We have a winner for this particular DSW!!




    Incidentally, is your 12 year old software still fit for purpose?

    It was in service until the company was acquired and the services migrated into the new owner's systems. As it was written to address business and network requirements of the original company's operations, it is unlikely to have any use to other companies with different service models.

     

     

     

     

     



  • @jes said:

    It was in service until the company was acquired and the services migrated into the new owner's systems. As it was written to address business and network requirements of the original company's operations, it is unlikely to have any use to other companies with different service models.

    "No" would have been shorter.



  • @blakeyrat said:

    @jes said:
    It was in service until the company was acquired and the services migrated into the new owner's systems. As it was written to address business and network requirements of the original company's operations, it is unlikely to have any use to other companies with different service models.

    "No" would have been shorter.

    Even shorter.



  • @blakeyrat said:

    @jes said:
    It was in service until the company was acquired and the services migrated into the new owner's systems. As it was written to address business and network requirements of the original company's operations, it is unlikely to have any use to other companies with different service models.

    "No" would have been shorter.

     

     

    'No' would have been inaccurate. It was still fit for the purpose for which it was designed, the requirements it fulfilled ceased to exist. Should someone actually recreate a system with similar enough requirements, then yes, it is still a viable solution. So 'Yes' would also have been a correct answer.

    I only mentioned it in the first place as a counter to the claim that the use of NTP for sequencing is somehow, by definition, a WTF. It wasn't brilliant software, we had no Paula Beans to help with it. It was robust and in over a decade of servive it was successfully extended to meet new requirements, which implies it wasn't so badly written that only the author could maintain it. 

    The discussion is over the suitability, in some situations, of NTP as a sequencing mechanism.

     



  • @jes said:

    'No' would have been inaccurate.

    I AM A ROBOT IT IS NOT POSSIBLE FOR ME TO BE LESS THAN 100% ACCURATE AT ALL TIMES BEEP BEEP BEEP WHAT IS THIS THING CALLED DICKWEED

    @jes said:

    So 'Yes' would also have been a correct answer.

    And it also would have been much shorter.

    @jes said:

    The discussion is over the suitability, in some situations, of NTP as a sequencing mechanism.

    I wanna talk about robots. BEEP BEEP BEEP



  • @blakeyrat said:

    @jes said:
    'No' would have been inaccurate.

    I AM A ROBOT IT IS NOT POSSIBLE FOR ME TO BE LESS THAN 100% ACCURATE AT ALL TIMES BEEP BEEP BEEP WHAT IS THIS THING CALLED DICKWEED

    @jes said:

    So 'Yes' would also have been a correct answer.

    And it also would have been much shorter.

    @jes said:

    The discussion is over the suitability, in some situations, of NTP as a sequencing mechanism.

    I wanna talk about robots. BEEP BEEP BEEP

     

     I'm busy on my laptop in the basement struggling with these crappy games that don't install the way I want them to. And crappy IDEs. And I hate the way the window decorations look in Google Chrome, because they don't look like theones in whichever version of Windows I'm running this week. But I'll be sure to look up dickweed in my mirror.

     



  • @jes said:

    I'm busy on my laptop in the basement
     

    Every time someone's talking about their basement I envision this damp, dank cellar with grim, concrete walls; slightly mossed over and you can hear a slow drip of water echoing in a shadowy corner. Rats scurry in all directions as you descend into this dark abode of the nethers.



  • @dhromed said:

    Every time someone's talking about their basement I envision this damp, dank cellar with grim, concrete walls; slightly mossed over and you can hear a slow drip of water echoing in a shadowy corner. Rats scurry in all directions as you descend into this dark abode of the nethers.

    LOOK INVENTORY



  • @dhromed said:

    @jes said:

    I'm busy on my laptop in the basement
     

    Every time someone's talking about their basement I envision this damp, dank cellar with grim, concrete walls; slightly mossed over and you can hear a slow drip of water echoing in a shadowy corner. Rats scurry in all directions as you descend into this dark abode of the netherlands.

    FTFY.



  • @Xyro said:

    LOOK INVENTORY

    The tattered and torn remains of your clothes have but one functional pocket that might hold three small items at best. It currently holds a $10 USB soundcard (1 unit), and a VGA-to-DVI converter (1 unit).



  • GO NORTH

    LOOK EXITS



  • Whoops, the big heavy door slid closed when you stepped through. A dinky bulb flickers on overhead, bathing everything in a... well more like wetting things mildy. You can make out a desk and a very old computer. There's a few items on the desk.


Log in to reply