WelcomeWelcome | FAQFAQ | DownloadsDownloads | WikiWiki

Author Topic: 2k38 compliancy  (Read 2718 times)

Offline destroyedlolo

  • Jr. Member
  • **
  • Posts: 50
    • destroyedlolo's website
2k38 compliancy
« on: January 19, 2023, 02:00:32 AM »
Hello,

Today on reddit, someone raises the upcoming problem of 32bits time_t.

My current projects with TCL is a very long term archiving system, speaking about decades. Mostly to store my familly photos, important documents or such.

Is current 13.1 TCL for 32b system already 2k38 safe ? If not, what about upcoming 14.xx ?

Thanks

Laurent

Offline Juanito

  • Administrator
  • Hero Member
  • *****
  • Posts: 14634
Re: 2k38 compliancy
« Reply #1 on: January 19, 2023, 02:14:35 AM »
Nothing special has been done in tinycore, so it’s 2k38 prepared-ness is that of the source from which it is built.

Offline destroyedlolo

  • Jr. Member
  • **
  • Posts: 50
    • destroyedlolo's website
Re: 2k38 compliancy
« Reply #2 on: January 19, 2023, 03:19:05 AM »
As per this information I found : https://stackoverflow.com/questions/14361651/is-there-any-way-to-get-64-bit-time-t-in-32-bit-programs-in-linux/60709400#60709400,

Using 5.6+ kernel and recent libc, it should be "de facto" migrated. But I duno if it's applying to the libc used by TCL ?

Offline Juanito

  • Administrator
  • Hero Member
  • *****
  • Posts: 14634
Re: 2k38 compliancy
« Reply #3 on: January 19, 2023, 03:31:19 AM »
The link says glibc >2.32

tc-13 is 2.34
tc-14 is 2.36

..but your apps would still need recompiling.

Offline destroyedlolo

  • Jr. Member
  • **
  • Posts: 50
    • destroyedlolo's website
Re: 2k38 compliancy
« Reply #4 on: January 19, 2023, 03:38:23 AM »
How major release are made (especially 13.xx and 14.xx) : are U rebuilding everything from scratch or do you keep some binaries from previous release ?

Offline Juanito

  • Administrator
  • Hero Member
  • *****
  • Posts: 14634
Re: 2k38 compliancy
« Reply #5 on: January 19, 2023, 05:09:08 AM »
The toolchain is built from scratch and the kernel is compiled with the new toolchain with each major release.

See, for example: http://www.tinycorelinux.net/14.x/x86_64/release/src/

The majority of the extensions are copied over from the previous major release.

Offline gadget42

  • Hero Member
  • *****
  • Posts: 670
Re: 2k38 compliancy
« Reply #6 on: January 19, 2023, 05:38:12 AM »
enjoyed perusing the OP hotlink:
https://www.reddit.com/r/linux/comments/10fqx1t/today_is_y2k38_commemoration_day/

definitely thought-provoking moreso than entertaining

another fun one:
https://jvns.ca/blog/2023/01/18/examples-of-problems-with-integers/

20230119-0745am-modified-added another fun link
« Last Edit: January 19, 2023, 05:45:34 AM by gadget42 »
The fluctuation theorem has long been known for a sudden switch of the Hamiltonian of a classical system Z54 . For a quantum system with a Hamiltonian changing from... https://forum.tinycorelinux.net/index.php/topic,25972.msg166580.html#msg166580

Offline GNUser

  • Hero Member
  • *****
  • Posts: 1378
Re: 2k38 compliancy
« Reply #7 on: January 19, 2023, 07:53:29 AM »
Hi, destroyedlolo.
My current projects with TCL is a very long term archiving system, speaking about decades. Mostly to store my familly photos, important documents or such.

64-bit linux has been 2k38 ready for a while. 32-bit linux has been ready since kernel version 5.6. See here:
https://en.wikipedia.org/wiki/Year_2038_problem

Technology changes fast and hard drives, USB drives, etc. are susceptible to bit rot, making archiving a difficult job.

For family photos we went having them professionally printed then making photo albums. For family videos we went with making video DVDs and burning them on M-DISCs, which supposedly last forever. Note: only some DVD burners can make M-DISCs (e.g., LG brand) but majority of players (all I've tried) can play them just like a normal DVD.
https://en.wikipedia.org/wiki/M-DISC

For both pictures and videos, we also put everything on a USB solid state drive formatted with ext4 and on a different USB solid state drive formatted with ntfs.

What we did is still not a guarantee that grandchildren and great-grandchildren will be able to access this stuff, of course. I think the photos will outlive the usefulness of the DVDs and USB devices, but we made a gamble on these technologies and hope they will still be available in antique shops of the future.

Good luck :)
« Last Edit: January 19, 2023, 08:10:40 AM by GNUser »

Offline Rich

  • Administrator
  • Hero Member
  • *****
  • Posts: 11305
Re: 2k38 compliancy
« Reply #8 on: January 19, 2023, 08:07:47 AM »
Hi destroyedlolo
If you want to verify whether your 32 bit kernel/glibc will handle
64 bit time, see this:
https://stackoverflow.com/questions/71599103/compiling-old-c-code-y2038-conform-still-results-in-4-byte-variables

Create a file called  test2038.c:
Code: [Select]
#include <sys/types.h>
#include <sys/stat.h>

#include <stdio.h>
#include <unistd.h>

int main(void)
{
    struct stat sb;

    printf("sizeof time_t: %zu\n", sizeof(time_t));
    printf("sizeof stat timestamp: %zu\n", sizeof(sb.st_atime));

    return 0;
}
Don't call it  time.c  like the author did,  time  is a busybox function.

Install the compiler:
Code: [Select]
tce-load -w -i compiletc
Compile and run the program:
Code: [Select]
tc@E310:~/y2038$ gcc -D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64 test2038.c -o test2038
tc@E310:~/y2038$ ./test2038
sizeof time_t: 4
sizeof stat timestamp: 4
tc@E310:~/y2038$
I ran this under TC10 and it shows 32 bit times. The  sizeof  results will be 8 for 64 bit times.

Offline curaga

  • Administrator
  • Hero Member
  • *****
  • Posts: 10992
Re: 2k38 compliancy
« Reply #9 on: January 19, 2023, 09:26:08 AM »
You should use 64-bit linux to be sure, that has had 64-bit units for ages.
The only barriers that can stop you are the ones you create yourself.

Offline destroyedlolo

  • Jr. Member
  • **
  • Posts: 50
    • destroyedlolo's website
Re: 2k38 compliancy
« Reply #10 on: January 19, 2023, 12:45:53 PM »
Hi all,

Let me present to you my solution:

In addition to printed books, I need numerical backup, as not all are printed  (and printing a video is not very ... efficient  ;) ).

I now have more than 20 years of digital photos and videos, and some are important to us (wedding where we splurged ;D, birth and important moments of children, ...).

Based on an archiving study I did at work (I'm infrastructure/solution architect), I identified the following potential issues  :

- resolutions : my first camera did 640x480 and, fortunately, 1080p photos, Videos only in 640x480 which looks like a post stamp now.
-> But the technology evolve, nothing can be done here (but upscaling which is a bit limited which such low resolution)

- data format : In the '90 Amiga's IFF was very common, only little software support it now.
-> for that, the day JPEG and MPG4 become obsolete, I'll convert ...

- last problem is media sustainability.
-> For the moment, data are mirrored on 4 machines using different OS (2x TCL, 1 Gentoo, 1 NetBSD) to avoid bugs / virus. They are all very old and obsolete machines, now too slow or energy consuming for other usage. It's here 32bits enters the game. The most powerful one is a P4.
If one fails, I don't care, as I have 3 others ones ...
In addition, when a storage technology become obsolete, I add a new machine with a more recent one.
Initially, it was SCSI disks (I deprecated them as disks are quite too small / too expensive), then IDE, and now SATA. I have at least 2 machines, being able to read at least 2 formats.

Now, there is the problem of data rot : for that, I created a daemon that associate a numeric signature for every file. It is able to detect file creation, deletion and modification/corruption. As running on all mirror, I'm able to identify which one is safe, which one is corrupted.
Even if it is already doing the job, development is still on going ... I need at least implement inotify then I'll issue a TCL package.

Comments, ideas on my solution or any help (coding, docs for Mer-De-Glace) are obviously welcome :)


Offline gadget42

  • Hero Member
  • *****
  • Posts: 670
Re: 2k38 compliancy
« Reply #11 on: January 19, 2023, 10:20:32 PM »
a little more if you've got the time(pun intended):
https://rachelbythebay.com/w/2023/01/19/time/
The fluctuation theorem has long been known for a sudden switch of the Hamiltonian of a classical system Z54 . For a quantum system with a Hamiltonian changing from... https://forum.tinycorelinux.net/index.php/topic,25972.msg166580.html#msg166580

Offline curaga

  • Administrator
  • Hero Member
  • *****
  • Posts: 10992
Re: 2k38 compliancy
« Reply #12 on: January 19, 2023, 11:10:10 PM »
For corruption, there's methods like par2, which create additional data, but are able to fix small corruption errors.
The only barriers that can stop you are the ones you create yourself.

Offline destroyedlolo

  • Jr. Member
  • **
  • Posts: 50
    • destroyedlolo's website
Re: 2k38 compliancy
« Reply #13 on: January 20, 2023, 03:50:17 AM »
For corruption, there's methods like par2, which create additional data, but are able to fix small corruption errors.

Most of the time, when data started to be corrupted, it's highlighting a beginning of larger issue (hardware failure, SSD loosing its electrical charge, hd demagnetization, ...). So it's why I would prefer to be warned about it and relying on other mirror than corrective actions.
I mean, this kind of data are "sleeping", very very infrequent access and no urgency. So having to start another machine to access them is not really an issue  ;)

Offline patrikg

  • Wiki Author
  • Hero Member
  • *****
  • Posts: 684
Re: 2k38 compliancy
« Reply #14 on: January 20, 2023, 08:51:13 AM »
Are you printing this checksum's to paper to avoid data rut, with the checksum ??
And if not how do you preserve the checksum not being data rut ??