22 ms·
2038: Only 21 years away
- grabcocque 10y agoAnd IPv6 penetration will have hit 20%.
- sly010 10y agoAnd will be the year of the Linux Desktop.
- deathanatos 10y agoYou jest, but global IPv6 penetration is at ~16%. It rose ~6% last year, so if linear growth is presumed (and it's actually been growing closer to exponentially, as would be expected) we should hit 20% late this year. I'm hopeful that we'll see some decent pickup of it since AWS finally started offering it. This is global adoption; some countries, including the United States, have already hit 20%. [1]: https://www.google.com/intl/en/ipv6/statistics.html https://www.google.com/intl/en/ipv6/statistics.html
- 1maginary 10y ago>The graph shows the percentage of users that access Google over IPv6. I'm finding it really hard to believe, as someone in Guatemala, that 6% of requests to Google here are made over IPv6. Is there any way to gain more insight? e.g. what ISPs are responsible?
- runeks 10y agoMobile carriers. In the US, 55% of mobile traffic is IPv6: http://m.slashdot.org/story/315213 http://m.slashdot.org/story/315213
- p1mrx 10y agoThat level of detail isn't published, but most of Guatemala's IPv6 traffic is coming from http://bgp.he.net/AS52362 http://bgp.he.net/AS52362 and http://bgp.he.net/AS23243 http://bgp.he.net/AS23243 Edit: APNIC has similar data published here: https://stats.labs.apnic.net/ipv6/GT https://stats.labs.apnic.net/ipv6/GT
- 1maginary 10y agoI appreciate the links! Exactly what I was after.
- marcosdumay 10y agoWhat's up with that huge weekly variation?
- OJFord 10y agoI'm guessing, but could it be offices running IPv6 while employees go home to IPv4? (With non-square edges due to mornings and evenings.)
- mastax 10y agoIt looks like it's correlated with the weekend. I guess workplace computers are more likely to use IPv4? It makes sense on the surface. Workplaces have little to no incentive to use IPv6 since they either have a huge block of IPv4 space or run NAT or both. Also they tend to rely more on enterprise network appliances which have bad IPv6 support in my experience. IPv6 is more of a boon to consumer applications since carrier-grade NAT is a nuisance and otherwise you need an IP per customer.
- marcosdumay 10y agoMakes sense.
- deathanatos 10y agoEvery employer except one that I've worked for had IPv4 only. None of them had public IP blocks; they were all NAT'd. > Also they tend to rely more on enterprise network appliances which have bad IPv6 support in my experience. This I would believe. > IPv6 is more of a boon to consumer applications since carrier-grade NAT is a nuisance and otherwise you need an IP per customer. It would have been a slight boon at work, too. HR perennially makes me grab documents/data off my home machine, and I cannot wait for the day when I can just `ssh` to a domain name. My .ssh/config aliases are getting pretty good, but it still adds considerable latency to pipe everything through a gateway. (Alternatively, I could run SSH on non-standard ports, but I've yet to get to mucking around with the port-forwarding settings for that.) There were also times when we needed to do stuff like employee laptop-to-laptop communications, and the network just wouldn't deal with it. I was never sure if this was NAT, or just that Corp Net liked to drop packets. (It seemed rigged to drop basically anything that didn't smell like a TCP connection to an external host. ICMP wasn't fully functional, which of course makes engineering more fun when you're having your personal desktop at home do pings or traceroutes for you, but that doesn't help if the problem is on your route.)
- elastic_church 10y agothats motivational
- deleted 10y ago[deleted]
- gnopgnip 10y agoIt is already over 50% in the US.
- pbhjpbhj 10y agoThe stat for Google in the citation (https://www.google.com/intl/en/ipv6/statistics.html#tab=per-country-ipv6-adoption&tab=per-country-ipv6-adoption https://www.google.com/intl/en/ipv6/statistics.html#tab=per-...) shows 30%; where do you get the 50% adoption from?
- sobani 10y agothanks to runeks [https://news.ycombinator.com/item?id=13925396 https://news.ycombinator.com/item?id=13925396] according to https://mobile.slashdot.org/story/16/08/20/2059216/ipv6-achieves-50-reach-on-major-us-carriers https://mobile.slashdot.org/story/16/08/20/2059216/ipv6-achi... it's only the US mobile carriers that are over 50%.
- archgrove 10y agoThis is (serious) a part of my retirement planning. I'll be mid-50s when this hits, and have enough low level system knowledge to be dangerous. In about 15 years, I'll start spinning up my epochalypse consultancy, and I'm expecting a reasonable return on investment in verifying systems as 2038 compliant.
- Aloha 10y agoThere is a certain amount of snark embedded in this post, but its not a bad idea at all - I'll be in much the same boat at that time - perhaps I can borrow the same idea...
- archgrove 10y agoIt wasn't intended to be sarcastic. I suspect there will be a lot of businesses (especially finance) interested in verifying that the "ancient" Linux system they setup to replace their mainframe 25 years "ago" is safe. I lived through the Year 2000, and watched the same thing happen there. With suitable groundwork, there will be a willing and wealthy market looking for people to assuage their fears - a service I see myself as happy to provide. Much as it was in the "Millennium bug" area, a lot of the effort in getting the business is PR spadework, but I've got 15-20 years of prep time to position myself suitably. I also hope to provide a slightly more useful service than many Millennium consultancies did at the time.
- tyingq 10y agoDatabases too. MySQL has a 2038 bug in their UNIX_TIMESTAMP function. select unix_timestamp('2038-01-19') returns 2147472000 select unix_timestamp('2038-01-20') returns 0
- pbhjpbhj 10y agoSurely these sorts of errors in major systems are already being/have already been addressed - for healthcare for example a search for which members of a GP's practice are going to be pensioners in 2040 is going to error badly? Strikes me that the time to address them was shortly after the millennium bug.
- coltonv 10y agoIs there a reason why they decided to store time as seconds from 1970? In a 32-bit integer nonetheless. It seems like basic logic would have lead the original designers to make it at least 64 bits so that you'd never overflow it (with a 64 bit time we'd be good til the year 292277026596). 64 bits would also allow you to also cover the entirety of history, all the way back to 13.7 billion years ago when the Universe came into existence, but instead the UNIX time format is shackled to be within ~68 years of 1970.
- jandrese 10y agoBack in the 70s RAM was expensive, and 68 years is long enough that they figured they would have a solution in place long before it became an issue. When your machine has a 16 bit processor and a few dozen kilobytes of RAM you look to save wherever you can. 64 bit number support was primitive and quite slow as well.
- slededit 10y agoYou are operating under the assumption the extra 4 bytes was an insignificant cost. This was not true for much of early UNIX history.
- BinaryIdiot 10y ago> Is there a reason why they decided to store time as seconds from 1970? Pretty sure it was related to space being an issue. In every place where you needed to save time you likely didn't want to use more space than you had to. This was also a driving factor as to why years were stored with only the last two digits. In 2017 we have no problem store-wise making it a 64-bit integer. But in the 90s and earlier? I think it would have been a hard sell to make a change that would future proof them beyond 2038 especially when so many play the short term money game.
- phicoh 10y agoThe C version of Unix was written for a 16-bit processor (pdp-11). The C compiler simulated 32-bit operations but nothing bigger. 64-bit operations only got wide spread way later when 16-bit systems were no longer relevant and 32-bit systems got 'long long'. Note that POSIX allows time_t to be 64-bit. And as far as I know, that's what OpenBSD does.
- mring33621 10y agoMore gravy for Initech!
- lazyjones 10y agoMeh, we'll just redefine time_t as (signed) seconds since 2000 or so and subtract 30 years in seconds from all timestamps ... ;-)
- antirez 10y agoUsing a 64 bit timestamp will only move the problem 292 million years forward, so probably the best solution is to use a variable length field.
- jpm_sd 10y agoGood idea. Our Qeng Ho descendants will thank us. [0] [0] https://en.wikipedia.org/wiki/A_Deepness_in_the_Sky#Interstellar_culture https://en.wikipedia.org/wiki/A_Deepness_in_the_Sky#Interste...
- hunterjrj 10y agoUp vote for the Deepness reference! What a great novel, and I suspect the concept of a "programmer archaeologist" would be of interest to many here...
- Nition 10y agoA Fire Upon The Deep is a fantastic book as well.
- placeybordeaux 10y agoI loved both of these, any recommendations for other similar books?
- Nition 10y agoThe only one I can think of that's remotely in the ballpark would be Dune. The creativity in AFUTD is hard to match.
- hunterjrj 10y agoBlindsight by Peter Watts.
- jraines 10y agoI'm a big fan of both and I recently loved Diaspora by Greg Egan. It's a bit more heavy on math/physics references but it's still amazing writing and an epic piece of world (and universe) building.
- gbrown_ 10y ago> statx() will serve as the year-2038-capable version of the stat() family of calls Does this seem horrible to anyone else? Why not fix stat()? Does this syscall have to be so highly preserved even when it will be broken? One of the advantages of the OpenBSD approach of being able to make intrusive changes saw their time_t made 64-bit in the 5.5 release in 2014. https://www.openbsd.org/55.html https://www.openbsd.org/55.html Admittedly this is much harder for Linux as they can't make the change an verify in a single place due to the separation of kernel and userland/ the fact Linux has many distros.
- Aissen 10y agoIn Linux kernel land, the golden rule is to never break the userspace ABI. Yes, it might happen, but it's never intentional, unless there's no other choice (glaring security issue for instance).
- gbrown_ 10y agoI know and understand the reasoning for this, I just don't like it. I am a BSD fan, so I indulge in a land where such ABI breaks are possible. In a fantasy land I would like to see the Linux community coming up with a way to deal with ABI breaks. Not that I think such breaks are to be taken lightly but they are sometimes necessary. Such as this case.
- masklinn 10y agoThe problem is because Linux is just a kernel (not an entire system like BSDs) the syscall ABI is the actual kernel API. If you break it, you break the world. On BSDs, or Window, or most every OS, there's a base "userland" library (e.g. libc) which serves as the kernel API and hides whatever ABI specific syscalls use, Linux doesn't have that.
- gbrown_ 10y agoI know, I'm saying it would be nice if the Linux kernel could set up a method for breaking ABI's in a planned fashion. I'm not saying it would be easy.
- iamgopal 10y agoCall me stupid, but I think computing will be much different to worry about this. ( single chip os or iot to the level that each hardware component is separate, or something else...)
- abritinthebay 10y agoYes, they thought that in the 70s too. Not stupid, just naive
- ryan-c 10y agoI'm pretty sure that's exactly what they figured when they designed it in the first place, and here we are many decades later, still living with it.
- gregmac 10y agoThere are still lots of systems from the 70's and 80's running today. There are many PDP and VAX systems that run parts of the US military, such as missile defense and nuclear ICBM systems. Many airlines and insurance agencies also run on mainframes from that era. Even if they don't run the actual hardware, they're likely to be running the same software and OS on an emulator running inside modern hardware. It's simply too expensive and risky to rewrite all the software on a new platform.
- sedachv 10y agoYou can buy new PDP-11 and VAX hardware to run Unibus/Q-bus based industrial control systems today: http://logical-co.com/ http://logical-co.com/
- Aardwolf 10y ago21 years ago was 1996. How different is computing now compared to 1996? Do you consider 2017 vs 2038 to probably have more difference or less difference than 1996 vs 2017? If more difference, do you expect technology to accelerate faster in the next 21 years than the last 21 years, and why?
- 10y ago
- gregmac 10y agoI wonder how much attention this will get from the general public and non-technical managers? After all, programmers predicted doom for Y2k, and then "nothing happened". This is almost the same situation, except I assume slightly less understandable to a non-programmer (you have to understand seconds-since-1970 and why we'd do that instead of storing the date as text, powers of 2 and the difference between 32 and 64-bit).
- gmac 10y agoYeah, I worry that between the less obvious failure mechanics and the sense that Y2K was overblown (probably, ironically, because it was effectively mitigated), the epochalypse may not be all that nice.
- mrkgnao 10y ago> BSD-based distributions have the advantage of being able to rebuild everything from scratch, so they do not need to maintain user-space ABI compatibility in the same way. I don't understand, not knowing much about BSD. Is this an LTS/support thing? Can someone explain?
- cbr 10y agoGenerally people build BSD packages from source instead of installing binaries. (I think; I've not used BSD.)
- protomyth 10y agoThe only time I build from source (ports) on FreeBSD is because the package maintainer picked "crappy"[1] options. On OpenBSD, I can generally find the flavor of port that has the options I want. If I cannot I resort to ports. 1) for my definition of crappy, not compiling PostgreSQL support is the most common for me
- clarry 10y agoOpenBSD user since 2009. I have never compiled a package from source. But they can break the ABI because they do not want to maintain compatibility with old proprietary binaries. It's a source world, in the sense that any software can and will be recompiled if and when needed. That doesn't mean every user has to compile their own system.
- madphrodite 10y agoI've used both, most bsd users have. Prefer packages but ports is useful for custom builds and desktop systems.
- gbrown_ 10y agoBSD's don't tend to have distros. So for example OpenBSD has a ports tree maintained by the ports team for OpenBSD. The operating system is free to break ABI's from release to release as the ports tree is audited, fixed, and recompiled for the new release. The Linux kernel can't freely do this as then the ABI break is placed on various distro maintainers and software authors because there is no clear point in time they can say ABI $FOO will break on date $BAR.
- curiousDog 10y agoI plan to touch base with Alex Jones, George Noory etc and start selling 2038-survivor-alpha-male vitality pills in 10 yrs.
- dang 10y agoWe detached this comment from https://news.ycombinator.com/item?id=13923113 https://news.ycombinator.com/item?id=13923113 and marked it off-topic.
- pkulak 10y agoIs 2038 the end of a signed int? If so, can't we just make it unsigned and buy ourselves another 70 years or so? I don't know how much of an issue not being able to represent time before 1970 is, but for timestamps that doesn't seem like it would be an issue.
- Zitrax 10y agoThat would break systems that relies on time stamps earlier than 1970 though. int main(void) { time_t epoch = -100; printf("%s", asctime(gmtime(&epoch))); } The above would for example print a time in 1969.
- jayflux 10y agohttps://en.wikipedia.org/wiki/Year_2038_problem https://en.wikipedia.org/wiki/Year_2038_problem explains pretty well why that wouldn't work and other solutions tried
- Practicality 10y agoHere I thought it was a post on the singularity. It might be ironic if all the AI starts running into all sorts of 2038 bugs and this ends up being a huge issue.
- njharman 10y agoMy retirement, only 18 years away. I'm real sorry I'm gonna miss this mess, NOT!
- geoffreyhale 10y agoY2K
- halcyondaze 10y agoAs a layman here, can someone explain this what the significance of the year 2038 is to me?
- IshKebab 10y agohttps://www.google.co.uk/?q=2^31+seconds+%2B+1970+years https://www.google.co.uk/?q=2^31+seconds+%2B+1970+years
- zie 10y agoNothing significant except that the storage spot for unix will fill up. Unix used to use a 32bit variable to store time in seconds since the epoch of 1970, so it will overflow in the year 2038. Most modern Unix systems have fixed the problem already, but Linux has a harder time than the others, and is still working on their fix.
- soundwave106 10y agohttps://en.wikipedia.org/wiki/Year_2038_problem https://en.wikipedia.org/wiki/Year_2038_problem Short summary: Many systems (including Unix) store time as a signed 32 bit int, with the value 0 representing January 1st 1970 00:00:00. This number will overflow on 03:14:07 UTC on 19 January 2038.
- halcyondaze 10y agoSo a more serious Y2K?
- soundwave106 10y agoIt is Y2K-ish; it's "different" so I'm not sure about seriousness. I'm thinking it simultaneously could be easier and more difficult, the standard "it depends" type answer. :) Y2K is more of a formatting / digit representation problem than a pure data type overflow. The solution for Y2K was to switch the representation of year from 2 to 4 digits, along with coding and logic changes to go along with this. For Unix / Linux, the solution for the 2038 problem involves changing time_t from 32 bits to 64 bits. At a higher level (eg what's in your C++ code), instinctively I don't think this in itself would involve as many code changes (maybe some data type changes, but probably less logic changes than Y2K, that's my guess). I believe several platforms have already moved towards 64 bit time_t by default... some support this by default even on 32 bit systems, such as Microsoft Visual C++ -- https://msdn.microsoft.com/en-us/library/3b2e7499.aspx https://msdn.microsoft.com/en-us/library/3b2e7499.aspx Since this involves a data type overflow issue, though, we're dealing more with platform specific / compiler / kernel type issues. I don't know, for instance, how easily 32 bit embedded type systems could handle a 64 bit time_t value. I understand that there are some technical issues with Linux kernels (mentioned in some of the comments) that prevent them from moving to a 64 bit time_t irregardless of platform (time_t should always be okay on 64 bit platforms, it's the 32 bit platforms that will have the issue...) The good news is we have 21 years to think about it...
- DoodleBuggy 10y agoY2K round 2
- shurcooL 10y agoIs software written in Go (that uses "time" package) going to be affected?
- jayflux 10y agoNo, https://golang.org/pkg/time/#pkg-constants https://golang.org/pkg/time/#pkg-constants Not unless you explicitly use the Unix method
- Taniwha 10y agoThis is not a problem for 20 years from now, I've already had to find and fix 2038 bugs ... there was an openssl bug (now fixed) in which cert beginning and ending date math was done in 32-bits ... certs with an end date from a little after 2038 would fail when compared with the current time. Fortunately for me there was already a fixed OpenSSL already available once I'd found the bug in it.
- rbanffy 10y agoWe should stock up on IBM 5100's
- goodplay 10y agoI Wonder how DRM anti-circumvention laws will mix with this; You have a locked-down device you use, depend on, and know is defective, but you are not allowed to hack the device to fix it.
- pagade 10y agoWhat about NTP epoch which has 2036 problem?
- carapace 10y ago(Does anybody remember that time traveler?)
- amelius 10y agoY2K didn't cause any serious blips on the stock market, so 2038 will probably pass without many even noticing.
- deleted 10y ago[deleted]
- AndrewKemendo 10y agoCan someone ELI5 this please? The only thing that seems comparable that I know of was the "Y2K bug" - but reading through this it seems like this is actually a big problem - as opposed to the techno-illiterate panic of Y2K. That work, he said, is proceeding on three separate fronts I can't read that without thinking of the turbo encabulator.
- minikites 10y agoI'll let somebody else handle the explanation but Y2K wasn't a "techno-illiterate panic", a ton of people worked a ton of hours to fix and update the code for Y2K and it's a testament to their labor that there were no major issues.
- deleted 10y ago[deleted]
- magpi3 10y agoIt was a combination of both. I still remember my dad coming home from a talk that he considered the "best yet" on the Y2K issue. The speaker warned that traffic lights would stop working. Maybe someone more techno-literate than me can explain why that would be a genuine concern, but from my perspective at the time it seemed like the guy was making money from fear mongering.
- Spooky23 10y agoFortunately, my retirement system has a project active right now to address this, and I will be retired in late 2032.
- miesman 10y agoWith any luck I'll be dead by then.
- jayflux 10y agoThis maybe a stupid question, but could we not use Bignum as a datatype to solve this? or would it be too computationally expensive?
- runeks 10y agoUsing a 64 bit unsigned integer with nanosecond resolution gives us 585 years (2^64/1e9/60/60/24/365) after 1970 to come up with a new format. This, combined with using some other format to describe dates before 1970, seems like a sensible solution to me.
- steffan 10y agoDespite the cause being the end of the UNIX epoch in 2038, problems will become apparent a much sooner. Like the Y2K issue - in ~2031 (or sooner), systems that track expiration dates or contract terms will start to run into dates past 2038. As 2038 approaches, more systems will be affected (there are relatively fewer expiration dates 7 years out vs. 5 or 3). The effects of this problem are closer than they seem - only 14 years away or less
- spencermountain 10y agofor the others curious, seems javascript handles dates with 64-bit floating points, which have a maximum of 9007199254740991. The highest date I could make with node+chrome was 'Dec 31 275759', which cozies-up pretty close to that (8639977899599000)
- jamescgrant 10y agoI wanted to figure out the importance of that value you found, so I went and did some further research. It turns out the greatest date you can create in Javascript is Date(8640000000000000). Interesting! From the ECMAScript Spec [1]: The actual range of times supported by ECMAScript Date objects is slightly smaller: exactly –100,000,000 days to 100,000,000 days measured relative to midnight at the beginning of 01 January, 1970 UTC. This gives a range of 8,640,000,000,000,000 milliseconds to either side of 01 January, 1970 UTC. [1] http://ecma-international.org/ecma-262/5.1/#sec-15.9.1.1 http://ecma-international.org/ecma-262/5.1/#sec-15.9.1.1
- Walkman 10y agoThe problem is not with developers or tech savvy people. Everyome will know about this by then and solutions will be applied. The problem is with end users, who will only realize this after the shit hits the fan and their fridge will go crazy or there will be a car crash.
- tgsovlerkhgsel 10y agoThis assumes that any of today's technology will survive 21 years...
- 5ilv3r 10y agoMy jeep is 27 and has an intel CPU. so.... yep.
- opportune 10y agoBut since those products were made by developers and tech savvy people, wouldn't it be their fault for releasing a product capable of doing that? It's literally their jobs to do so. Just as doctors and lawyers don't just assume patients/clients will know everything about their fields, why should we?
- granfalloon 10y agoSo what are we calling this one, Y2K38? I've heard people talk about the risk to cars, but what other kinds of embedded systems will still be in use after 20 years? Maybe certain industrial machines?
- deleted 10y ago[deleted]
- snvzz 10y agoThis is a good reason to run anything but Linux, particularly on 32bit hardware. All BSDs have, as far as I'm aware of, solved this years ago.
- throwaway2048 10y agoonly netbsd and openbsd, still an issue on freebsd.
- sixdimensional 10y agoOn a side but related note, I don't understand why many programming languages and databases don't have a positive and negative infinity date placeholder/token value that is standardized and cross platform. Negative infinity date is "past", positive infinity date is "future". This would solve the common problem of what date to use when you are trying to talk about unknown date in the future or unknown date in the past, rather than using weird placeholders like 9999-12-31 or 1900-01-01 or other magic numbers.
- rwallace 10y agoThere are lots of scenarios where you need to represent an unknown/indefinite date, but this can be done with null; are there any reasonably common scenarios where you need to distinguish between unknown past and unknown future in the same context?
- sixdimensional 10y agoI agree, null is often chosen as an option. But null is also not a value by definition so then it becomes hard to do a range check when using say, a start and end date. Also, what is the difference between a date in the future and null? Semantics I think-a token future date has an explicit value, whereas if you use NULL, the use of that as a future date has a new implicit value that depends on context. I know maybe it sounds pedantic or perhaps out there but I think that token dates that are fixed and specified as positive or negative infinity gives a mathematical value that can then be reasoned with formulaically, just like we do with calculus. We keep running into finite limits which is what keeps causing problems such as Y2K, Y2K38, the beginning of Unix time (1970-1-1) - maybe if we treated the beginning and end of time as infinity some new method of reasoning about dates would become more apparent. I'm not sure as I haven't gone all the way down the rabbit hole with this idea yet.
- sixdimensional 10y agoAnother thought - if you treat a date as a relative variable related to a frame of reference (example, what if you defined the future to be a token value of today + N days, which means it is always calculated as a dynamic future date ahead of today), maybe we could reason about relative past and present using relative variable dates? Or maybe this is just crazy talk.
- Jach 10y agoLet's move to Urbit's 128 bit system: https://github.com/urbit/urbit/blob/master/include/vere/vere.h#L762 https://github.com/urbit/urbit/blob/master/include/vere/vere... /* Urbit time: 128 bits, leap-free. ** ** High 64 bits: 0x8000.000c.cea3.5380 + Unix time at leap 25 (Jul 2012) ** Low 64 bits: 1/2^64 of a second. ** ** Seconds per Gregorian 400-block: 12.622.780.800 ** 400-blocks from 0 to 0AD: 730.692.561 ** Years from 0 to 0AD: 292.277.024.400 ** Seconds from 0 to 0AD: 9.223.372.029.693.628.800 ** Seconds between 0A and Unix epoch: 62.167.219.200 ** Seconds before Unix epoch: 9.223.372.091.860.848.000 ** The same, in C hex notation: 0x8000000cce9e0d80ULL ** ** New leap seconds after July 2012 (leap second 25) are ignored. The ** platform OS will not ignore them, of course, so they must be detected ** and counteracted. Perhaps this phenomenon will soon find an endpoint. */
- paxswill 10y agoNewton (Apple's old PDA) had a similar problem in 2010 [0]. In short, while the base system and C++ interfaces used 32-bit unsigned ints with a base of 1904-01-01, NewtonScript uses 30-bit signed ints, with a working base of 1993-01-1, overflowing in 2010. The fix was a binary patch that changed the time bases. 0: http://40hz.org/Pages/Newton%20Year%202010%20Problem http://40hz.org/Pages/Newton%20Year%202010%20Problem
- userbinator 10y agoIt's interesting to see that Apple's... shortsightedness/planned obolescence is nothing new. The Apple Lisa, released in 1983, was apparently not designed to survive beyond 1995: http://www.macworld.com/article/2026544/the-little-known-apple-lisa-five-quirks-and-oddities.html http://www.macworld.com/article/2026544/the-little-known-app... (scroll down)
- jwatte 10y agohttps://news.ycombinator.com/item?id=7678847 https://news.ycombinator.com/item?id=7678847
- kebman 10y agoHey guys! I just invented a new form of music! :D Epochalypso!
- fgandiya 10y agoSpeaking of the 2038 bug, I'm impressed with Paul Ryan's rhetoric [0] “I asked CBO to run the model going out and they told me that their computer simulation crashes in 2037 because CBO can’t conceive of any way in which the economy can continue past the year 2037 because of debt burdens,” said Ryan. I love politicians. [0]-http://www.cnsnews.com/news/article/ryan-debt-track-hit-800-percent-gdp-cbo-cant-conceive-any-way-economy-can-continue-past http://www.cnsnews.com/news/article/ryan-debt-track-hit-800-...
- madphrodite 10y agoWill be 70 and happily oblivious.
- equalunique 10y agoSurprisingly, when Googling for 2038 & FreeBSD, the 2nd highest recommended search result was: 2038年問題 freebsd I do not speak, write, or search for things using Chinese characters. Seems as though this problem must have been heavily Google'd for by Chinese speakers - why else would it have popped up in my search recommendations? Btw: Google Translate tells me 年問題 means "year problem" Perhaps this information was important for ensuring the safety of Kylin, which started out as a sort of Chinese DARPA-style project to get the state off of MS Windows. Kylin was announced in 2006. It was supposedly based on FreeBSD 5.3. Strange thing is, Kylin later became known to use the Linux kernel (with a Ubuntu influence). - Google search recommendations, which should be based on a recent volume of searches, if they did suggest anything about Kylin development, should yield "2038年問題 linux" rather than "2038年問題 freebsd" - Maybe some of those FreeBSD-Kylin systems are still being heavily used. Or perhaps there are a lot of embedded systems being produced in China which use FreeBSD.