2k38 compliancy

[destroyedlolo]

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

[Juanito]

Nothing special has been done in tinycore, so it’s 2k38 prepared-ness is that of the source from which it is built.

[destroyedlolo]

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 ?

[Juanito]

The link says glibc >2.32

tc-13 is 2.34
tc-14 is 2.36

..but your apps would still need recompiling.

[destroyedlolo]

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 ?

[Juanito]

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.

[gadget42]

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

[GNUser]

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

[Rich]

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.

[curaga]

You should use 64-bit linux to be sure, that has had 64-bit units for ages.

[destroyedlolo]

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 , 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

[gadget42]

a little more if you've got the time(pun intended):
https://rachelbythebay.com/w/2023/01/19/time/

[curaga]

For corruption, there's methods like par2, which create additional data, but are able to fix small corruption errors.

[destroyedlolo]

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 

[patrikg]

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 ??