GNU social JP
  • FAQ
  • Login
GNU social JPは日本のGNU socialサーバーです。
Usage/ToS/admin/test/Pleroma FE
  • Public

    • Public
    • Network
    • Groups
    • Featured
    • Popular
    • People

Conversation

Notices

  1. Embed this notice
    Dave Rahardja (drahardja@sfba.social)'s status on Tuesday, 02-Jan-2024 14:33:11 JST Dave Rahardja Dave Rahardja

    The Y2K bug is a great illustration that a well-handled potential disaster looks like “nothing happened” in retrospect. The fact that Y2K seemed to be a non-event is a testament to how seriously people took this emergency, and how everyone buckled down and averted a worldwide infrastructure disaster.

    I started working at Honeywell Aerospace (AlliedSignal back then) in 1998, and by that time people were already working on Y2K issues. We were in the GPS navigation business, and there were real issues that would have caused aircraft navigation to go awry unless they were fixed.

    People buckled down, found the bugs, ran simulations, got FAA sign-offs, and deployed the fixes to all affected aircraft well before Y2K. Thanks to the effort, “nothing happened”. But I assure you (bad) things would have happened if we did nothing. https://infosec.exchange/@tychotithonus/111670219441506220

    In conversation Tuesday, 02-Jan-2024 14:33:11 JST from sfba.social permalink

    Attachments

    1. No result found on File_thumbnail lookup.
      Royce Williams (@tychotithonus@infosec.exchange)
      from Royce Williams
      @robertatcara As someone who personally discovered and fixed Y2K bugs that would have had significant real world impact, it is disturbing to hear someone propagate this myth [that it was a "big fuss about nothing"]. And it is a myth. This is what really happened: https://time.com/5752129/y2k-bug-history/ The testing methodology insured that these impacts were not hypothetical. At my company, the testing was performed by *actually rolling the clock forward* to test systems to see what would happen. For example, I discovered that every ATM in the state of Alaska operated by my company would have locked up until a PROM chip was swapped. Someone had to fly all over the state to proactively swap the chip beforehand, to avoid significant customer impact. And that was just one story. I personally oversaw investigation and fixes for other hardware and software at that company that would have failed. And that was just my company. I spoke with others in IT at that time with similar stories. And that was just the people I knew. So no, it wasn't "a big fuss about nothing" - and saying so is both dangerously revisionist, and disrespectful of the work it took to prevent real impacts.
    • Haelwenn /элвэн/ :triskell: and Doughnut Lollipop 【記録係】:blobfoxgooglymlem: like this.
    • Doughnut Lollipop 【記録係】:blobfoxgooglymlem: repeated this.
    • Embed this notice
      Paul Wermer, CC BY-NC-SA 4.0 (paulwermer@sfba.social)'s status on Tuesday, 02-Jan-2024 14:33:56 JST Paul Wermer, CC BY-NC-SA 4.0 Paul Wermer, CC BY-NC-SA 4.0
      in reply to

      @drahardja there is a distressing tendency to reward those who respond to a disaster, while ignoring those who do the difficult work of preventing a disaster. The latter is so much harder to see, and also so much more challenging...

      In conversation Tuesday, 02-Jan-2024 14:33:56 JST permalink
    • Embed this notice
      Daniel Bowen (danielbowen@mastodon.social)'s status on Tuesday, 02-Jan-2024 19:09:35 JST Daniel Bowen Daniel Bowen
      in reply to
      • AJ Sadauskas

      @ajsadauskas @drahardja The idea that it wasn't a real problem is infuriating to those who worked on it.
      It's also a myth that nothing went wrong. Some bugs slipped through, and (mostly minor) issues did occur in 2000.
      This article has some examples - and I know I received a bill that said payment was due on 3rd March 1900.
      http://news.bbc.co.uk/2/hi/science/nature/585013.stm

      In conversation Tuesday, 02-Jan-2024 19:09:35 JST permalink

      Attachments

      1. Domain not in remote thumbnail source whitelist: news.bbc.co.uk
        BBC NEWS | Science/Nature | Y2K bug fails to bite
        The world has welcomed the new millennium without suffering any major millennium bug problems - at least so far.
    • Embed this notice
      AJ Sadauskas (ajsadauskas@aus.social)'s status on Tuesday, 02-Jan-2024 19:09:36 JST AJ Sadauskas AJ Sadauskas
      in reply to

      @drahardja Here's the Reserve Bank of Australia's report on all the work that was done across the financial services industry to prepare for Y2K: https://www.rba.gov.au/fin-services/resources/y2k-preps.pdf

      It's worth noting the Australian financial year ends on 30 June. So a lot of changes had to be in place by then (in case there were problems caused by financial year 00 appearing in any systems).

      There was also a bit of a dry run in January 1999, when the euro was introduced (something a lot of articles leave out).

      "There was significant progress during the June 1999 quarter, with more than half of the banks reporting at end-June that all critical systems had been completely renovated and tested. Most of the remaining banks finalised testing during July and August. The few remaining systems where testing is yet to be finalised are systems where any problems would have little or no impact on retail bank accounts or the payments system.

      "A comprehensive program to test the Year 2000 readiness of the Australian payments system, managed by the Australian Payments Clearing Association (APCA), was successfully completed, on time, by 30 June 1999 and no Year 2000 problems were reported by test participants. Because of this effort, the Australian public can be
      confident that their usual method of making non-cash payments, such as ATMs, EFTPOS and credit cards, will continue to work as usual over the New Year period.

      "Credit unions have approached Year 2000 preparations from an industry viewpoint. There has been a high level of cooperation between individual institutions and
      considerable assistance from industry special service providers.

      "The June 1999 returns indicated that the very large majority of building societies and credit unions had completed the testing and implementation phase of their Year 2000
      project by end-June 1999. Where there has been some slippage in testing timetables,
      this has been largely due to external service providers, an issue that was addressed by
      additional testing periods in July and August. FI Scheme supervisors have encouraged
      institutions to impose a freeze on changes to critical applications over the two main
      periods of risk."

      Non-Y2K updates to systems were also frozen at many financial institutions:

      "APRA has also written to institutions suggesting that they should consider setting
      periods in the latter part of 1999 and early 2000 (including the period around
      29 February 2000) during which changes to critical systems will only be undertaken
      if deemed absolutely necessary. This is to ensure that any changes do not introduce errors into systems that have already been tested. Most institutions have put in place a freeze period on changes to critical applications."

      In conversation Tuesday, 02-Jan-2024 19:09:36 JST permalink

      Attachments


      clacke repeated this.
    • Embed this notice
      Lea de Groot 🇦🇺 (leadegroot@bne.social)'s status on Tuesday, 02-Jan-2024 19:09:44 JST Lea de Groot 🇦🇺 Lea de Groot 🇦🇺
      in reply to
      • EVERYTHING'S COMPUTER

      @drahardja @be interesting - i was working on business systems that were medium old and had been coded with the classic “if year > 21 1900+year else 2000 + year” and reading your post i just realised that year has finally passed! And *man* the y2k fixes were tedious and boring!

      But they surely replaced those systems by now. Right? RIGHT. Lol :)

      In conversation Tuesday, 02-Jan-2024 19:09:44 JST permalink
      Haelwenn /элвэн/ :triskell: likes this.
    • Embed this notice
      Neil G4DBN (g4dbn@mastodon.radio)'s status on Tuesday, 02-Jan-2024 19:09:46 JST Neil G4DBN Neil G4DBN
      in reply to

      @drahardja My team worked for two years on identifying and eliminating shitty applications written by idiot coders who had zero foresight. The business had over 300 apps and a huge shadow IT problem. By the time we hit Y2K, we'd wiped out almost half of the apps and most shadow IT apart from the crappy local databases. Embarrassing the crap out of the hobby coders who thought they knew what they were doing, and holding them accountable for being a significant business risk was mildly satisfying

      In conversation Tuesday, 02-Jan-2024 19:09:46 JST permalink
      Haelwenn /элвэн/ :triskell: likes this.
    • Embed this notice
      LisPi (lispi314@udongein.xyz)'s status on Tuesday, 02-Jan-2024 19:12:02 JST LisPi LisPi
      in reply to
      • Neil G4DBN
      @g4dbn @drahardja What puzzles me is why they thought it was a good idea to micro-optimize time-keeping in the first place.

      Or considering just how absurdly finnicky time gets when one gets into the depths of it, why they improvised something instead of using one of the standards by folks who bothered to try and deal with all the edgecases & annoyances.
      In conversation Tuesday, 02-Jan-2024 19:12:02 JST permalink
    • Embed this notice
      Neil G4DBN (g4dbn@mastodon.radio)'s status on Tuesday, 02-Jan-2024 19:12:04 JST Neil G4DBN Neil G4DBN
      in reply to

      @drahardja Every time some cretin mentioned that Y2K was a hoax, the entire team would respond and suggest that they take their uninformed opinions and go elsewhere. Even 20 years later, we were easily triggered and responded with overwhelming rage. I've almost moved on and now just add them to the idiot pile and treat them with due caution. Two years of our lives wasted on fixing the work of idiots. Marvellous. See also C/C++ coders who didn't understand bounds checking. Idiots everywhere!

      In conversation Tuesday, 02-Jan-2024 19:12:04 JST permalink
      Haelwenn /элвэн/ :triskell: likes this.
    • Embed this notice
      'ö-Dzin Tridral 🏴󠁧󠁢󠁷󠁬󠁳󠁿 (tridral@toot.wales)'s status on Tuesday, 02-Jan-2024 22:50:42 JST 'ö-Dzin Tridral 🏴󠁧󠁢󠁷󠁬󠁳󠁿 'ö-Dzin Tridral 🏴󠁧󠁢󠁷󠁬󠁳󠁿
      in reply to

      @drahardja I had a similar experience. I started work at Cardiff University in 1999. Everyone wasooking at systems there and fixing two-digit year problems. We got it done and, of course, 'nothing happened'.

      It was called a 'millennium bug' but really it's a century problem. So I'm wondering if we will have the same problem in 2099/2100.

      In conversation Tuesday, 02-Jan-2024 22:50:42 JST permalink
    • Embed this notice
      Neil G4DBN (g4dbn@mastodon.radio)'s status on Tuesday, 02-Jan-2024 22:50:59 JST Neil G4DBN Neil G4DBN
      • clacke
      • LisPi

      @clacke @drahardja @lispi314 I wrote code in the early 1980s that took full notice that two-digit year fields were a liability and that some folks who were in the datasets were possibly *born in the 1800s* and that the dataset might endure past the end of the 1900s or require forward calculations into the then-distant 2000s. Agreed there were some systems that had so little memory that date compression was needed, but we used binary fields for time, not truncated text dates.

      In conversation Tuesday, 02-Jan-2024 22:50:59 JST permalink
    • Embed this notice
      Haelwenn /элвэн/ :triskell: (lanodan@queer.hacktivis.me)'s status on Friday, 05-Jan-2024 14:31:34 JST Haelwenn /элвэн/ :triskell: Haelwenn /элвэн/ :triskell:
      in reply to
      • 'ö-Dzin Tridral 🏴󠁧󠁢󠁷󠁬󠁳󠁿
      @tridral @drahardja 2099 maybe not, I think we somehow learned our lesson when it comes to the decimal representation.

      Unix and related on the other hand didn't, and just slightly increased the bitsize of time_t each time it became problematic and we're getting some Y2038 issues already with dates set in the future but it's going to be such a mess when it'll roll over.
      See: https://en.wikipedia.org/wiki/Year_2038_problem
      In conversation Friday, 05-Jan-2024 14:31:34 JST permalink

      Attachments

      1. Domain not in remote thumbnail source whitelist: upload.wikimedia.org
        Year 2038 problem
        The year 2038 problem (also known as Y2038, Y2K38, or the Epochalypse) is a time formatting bug in computer systems with representing times after 03:14:07 UTC on 19 January 2038. The problem exists in systems which measure Unix time – the number of seconds elapsed since the Unix epoch (00:00:00 UTC on 1 January 1970) – and store it in a signed 32-bit integer. The data type is only capable of representing integers between −(231) and 231 − 1, meaning the latest time that can be properly encoded is 231 − 1 seconds after epoch (03:14:07 UTC on 19 January 2038). Attempting to increment to the following second (03:14:08) will cause the integer to overflow, setting its value to −(231) which systems will interpret as 231 seconds before epoch (20:45:52 UTC on 13 December 1901). The problem is similar in nature to the year 2000 problem. Computer systems that use time for critical computations may encounter fatal errors if the Y2038 problem is not addressed. Some applications that use future dates have already encountered the bug. The most vulnerable systems are those which are infrequently...
    • Embed this notice
      John McDowall (jmcd@mastodon.social)'s status on Friday, 05-Jan-2024 18:49:03 JST John McDowall John McDowall
      in reply to
      • Nick Lockwood

      @drahardja @nicklockwood Reminds me of the Futurama episode when Bender meets (maybe) God.

      In conversation Friday, 05-Jan-2024 18:49:03 JST permalink

      Attachments


      1. https://files.mastodon.social/media_attachments/files/111/686/961/026/982/032/original/ea6c5270a8f3075f.jpeg
    • Embed this notice
      aardvark (aardvark@ioc.exchange)'s status on Friday, 05-Jan-2024 18:49:06 JST aardvark aardvark
      in reply to

      @drahardja “I never got smallpox, so that vaccine probably didn’t work”

      In conversation Friday, 05-Jan-2024 18:49:06 JST permalink
    • Embed this notice
      Dave Rahardja (drahardja@sfba.social)'s status on Friday, 05-Jan-2024 18:49:10 JST Dave Rahardja Dave Rahardja
      in reply to
      • 🇨🇦🇩🇪🇨🇳张殿李🇨🇳🇩🇪🇨🇦

      @zdl Which nations are those, specifically?

      In conversation Friday, 05-Jan-2024 18:49:10 JST permalink
    • Embed this notice
      🇨🇦🇩🇪🇨🇳张殿李🇨🇳🇩🇪🇨🇦 (zdl@mastodon.online)'s status on Friday, 05-Jan-2024 18:49:11 JST 🇨🇦🇩🇪🇨🇳张殿李🇨🇳🇩🇪🇨🇦 🇨🇦🇩🇪🇨🇳张殿李🇨🇳🇩🇪🇨🇦
      in reply to

      @drahardja Where were the disasters in the nations that didn't take Y2K anywhere near as seriously?

      In conversation Friday, 05-Jan-2024 18:49:11 JST permalink

Feeds

  • Activity Streams
  • RSS 2.0
  • Atom
  • Help
  • About
  • FAQ
  • TOS
  • Privacy
  • Source
  • Version
  • Contact

GNU social JP is a social network, courtesy of GNU social JP管理人. It runs on GNU social, version 2.0.2-dev, available under the GNU Affero General Public License.

Creative Commons Attribution 3.0 All GNU social JP content and data are available under the Creative Commons Attribution 3.0 license.