7 ms·
I love how Unix concepts have been around so long that their initial representations and assumptions of time will soon break. I wonder if the engineers at the t
by bArray 7y ago
I love how Unix concepts have been around so long that their initial representations and assumptions of time will soon break. I wonder if the engineers at the time thought that programmers in the future will run into such issues. Perhaps 64 bit time will also cause some headaches in the far future!
I was also trying to think of other computing implementations/assumptions that have shown their age. We've see a decrease in support for 32 bit CPUs, we ran out of addresses in IPv4, much security became obsolete - any others that come to people's minds?
- adrianN 7y agoBooting a modern CPU is a bit like time traveling through all eras of CPU architecture.
- close04 7y agox86 at least. Is it the same on ARM, MIPS, PPC, etc?
- JdeBP 7y agoOnly in the Intel Architecture and only then if one is bootstrapping in the old way. It is quite possible for a machine with EFI firmware, and no need of compatibility support, to go straight from the initial unreal mode to protected mode, never entering real mode.
- Baeocystin 7y agoOntology recapitulates phylogeny. :D
- JdeBP 7y agoPossibly at the time. Definitely, a mere 20 years in. I for one wrote a 32-bit C++ standard library in the early 1990s, and I used a 64-bit time_t. It ran on top of 32-bit OS/2, which was already keeping time internally using a 64-bit integer. I published two toolkits of command-line utilities, including a replacement DATE command, that used it. * http://jdebp.uk./FGA/keeping-time-in-os2.html http://jdebp.uk./FGA/keeping-time-in-os2.html I wasn't alone in this, by any means. Other library writers were implementing this. Solaris went 64-bit in the 1990s, as did IRIX. Windows NT had a 64-bit (albeit different) time format from the 32-bit start. TAI64NA was invented in 1997. * https://cr.yp.to/libtai/tai64.html https://cr.yp.to/libtai/tai64.html Thinking about this in the 2010s and 2020s is somewhat late. Indeed, even AIX 5.3 in 2004 was comparatively late.
- StillBored 7y agoAIX was late to the game for sure, but I don't think it was quite that late. It was more like AIX 4.3, that added the ability to run 64-bit code on a 32-bit OS. As part of that effort all the syscalls were double defined, one for older 32-bit only applications and another for 64-bit applications running on the 32-bit OS. By AIX 5, there was a native 64-bit kernel as well. Pretty sure that between those events the header files were tweaked so all newly built applications were using the 64-bit time_t calls unless a compatibility flag was defined.
- JdeBP 7y agoIt was 5.3 that gained the 64-bit time API. Prior to that, there was only 32-bit time_t, even on 64-bit AIX. See Redbook SG247463 section 5.19 ("Date APIs past 2038").
- toyg 7y agoTraditional BIOS; The original MSFAT filesystem; The Master Boot Record; Windows9x limits on RAM size; ... a lot of what I learnt while messing with Linux 20 years ago simply does not apply anymore.
- c2h5oh 7y agoMy first pc had it's 40mb hard drive divided into partitions because DOS 3.3 with FAT12 only supported positions up to 32mb.. Just a couple years later there was the whole LBA trickery to get around 528mb limit ide io and BIOS irq 13.. Year or two later it was 2.1gb because BIOSes used 12 bits for cylinder count... Next couple years brought 3 or 4 separate limits still under 10gb stemming mostly from shit fixes for the ones mentioned above.. All of that happened in the 90s. There was more later. Unix is changing time representation for the first time after all those years..
- selckin 7y agocurrently my nas can't create partitions for my new 16TB disks
- raverbashing 7y agoThe advice is old but still valid. If you can avoid big partitions, do so. Formatting, backing up, data recovery. It's at those moments that smaller partitions give you much less trouble than the bigger ones
- StillBored 7y agoPresumably because its running a 32-bit linux kernel? That is a problem too (hit me recently too with a MD device), but the solution has been to switch to a 64-bit kernel.
- moviuro 7y ago- We have way more pixels than what we could have ever guessed in the 1990s (800x600 -> 4k 4096x2160) [0] - Bandwidth got from 56kbps to ~10s of Gbps (Ethernet, USB, Display and the like) - Even current systems can't handle the number of CPU threads we have available [1] [0] https://en.wikipedia.org/wiki/Display_resolution#/media/File:Vector_Video_Standards8.svg https://en.wikipedia.org/wiki/Display_resolution#/media/File... [1] https://arstechnica.com/gadgets/2020/02/amd-threadripper-3990x-is-here-64-cores-128-threads-3990/ https://arstechnica.com/gadgets/2020/02/amd-threadripper-399...
- einpoklum 7y agoIn the 1990s you had a bunch of places with arrays of monitors, which together showed images with 4k horizontal pixels. Also - you really couldn't imagine a 5x increase in the pixel density per axis? As for bandwidth - 100 Mb/sec Ethernet was introduced in 1995, and it was clear that this wasn't nearly the end of the line for bandwidth.
- bluGill 7y agoIn 1995, fiber was already common for those with more data needs than that slow ethernet could go.
- csunbird 7y agoIn the future, we may need to scale up the time resolution, for example we may need time resolution up to 1 yoctosecond, because everything is faster. 64 bits wont be enough, so we will have that problem for sure.
- mcny 7y agoA yoctosecond is 110^-24 seconds or there are 110^24 yoctoseconds in a second. Of course, things will change in the future but I don’t see processors getting any faster than 5ish GHz without some breakthrough in technology? What applications/hardware might first be able to go beyond a septillionth of a second?
- steerablesafe 7y agoTo be fair we have a lot of time for that breakthrough in the time frame 64bit time currently allows.
- earthboundkid 7y agoc / 1 cm ≅ 30 GHz. No one is going to make a processor faster than that.
- brutt 7y agoLOL. Of course, it's possible to make faster processor than 30GHz. Even 1THz is possible with modern tech, but architecture will be completely different: millions of super-simple super fast single-atom processors connected via photon-based internet like network. Our brain is much more powerful than current processor, while using much weaker tech, so it's doable.
- close04 7y ago> photon-based internet like network If propagation delay is the concern (talking about high frequency) then electrons over copper do a better job than photons over fiber. (grain of salt, future dedicated photonic interconnect may have better performance). > Our brain is much more powerful than current processor Again, if we're talking about frequency (30GHz, 1THz) the brain is faster due to the way it's organized not because it operates at high frequencies. > Even 1THz is possible with modern tech [...] super fast single-atom processors Not in any meaningful way and we certainly aren't anywhere near "single-atom processors". Perhaps your comment meant to say that sometime in the future we won't need high frequency because we'll change the way we design processors, not that we can build 1THz CPUs because our brain is more powerful then them. It's possible to do a lot with "modern technologies", even cure cancer or solve world hunger etc., we just either haven't actually found a way to do some of those things, or at least not a feasible, useful way. This renders the statement a bit meaningless. We've had THz transistors for a decade now. There are dozens of reasons you don't see them in general purpose CPUs though.
- eru 7y agoLeap seconds are a big hassle. It's not even clear that they are worth bothering with individually. (We could wait until we have a whole minute worth of them before applying any.) https://en.wikipedia.org/wiki/Leap_second https://en.wikipedia.org/wiki/Leap_second It's all too easy to write software that doesn't take leap seconds into account.
- zozbot234 7y agoJust use TAI and you can legitimately ignore those. Leave it to presentation layers to convert between TAI and UTC when appropriate.
- MisterTea 7y ago> I wonder if the engineers at the time thought that programmers in the future will run into such issues. Given that Unix was developed at Bell labs in the late 60's I'd say the thought of Unix being a thing in 2038 never would have occurred to them. Even in the 80's they petered out with Unix research stopping at v10 and developed plan 9, which still has a 2038 bug we need to work out.
- Joeri 7y agoI wonder how long we will drag these old codebases along. I always liked vernor vinge’s concept of a programmer archeologist thousands of years in the future having to build up arcane knowledge about millenia-old code to get things done. Take the Traders' method of timekeeping. The frame corrections were incredibly complex - and down at the very bottom of it was a little program that ran a counter. Second by second, the Qeng Ho counted from the instant that a human had first set foot on Old Earth's moon. But if you looked at it still more closely ... the starting instant was actually about fifteen million seconds later, the 0-second of one of Humankind's first computer operating systems.
- acheron 7y ago"In the 24th century...." https://abstrusegoose.com/323 https://abstrusegoose.com/323
- bloopernova 7y agoWhich novel is that? I have some of his novels in my to-read list, and that sort of detail makes me want to bump them to the top.
- aaron_m04 7y agoA Deepness in the Sky