Đồng hồ Linux sẽ thất bại vào ngày 19 tháng 1 năm 2038 3:14:08?

23

Tôi có một chút lo ngại về điều này. Nó được gọi là "vấn đề năm 2038". Hạt nhân Linux hoặc Ubuntu đã sẵn sàng để xử lý ngày sau này chưa, kể từ ngày 12.04?

time

— ThePiercingPrince
nguồn

8

Bạn đã thử đặt đồng hồ của mình thành một cái gì đó như ngày 19 tháng 1 năm 2038 3:14:07 và đợi một giây chưa?

— gertvdijk

2

Giả sử vấn đề này tồn tại và chưa được khắc phục. 12.04 sẽ không được hỗ trợ mãi mãi, vì vậy bạn và tất cả những người khác sẽ được phân phối cập nhật cho đến khi điều này xảy ra, vì có nhiều năm giữa. Cập nhật thật dễ dàng. Một trong những cập nhật này chắc chắn sẽ chứa một bản sửa lỗi. Vì vậy, không có lý do để quan tâm, nhưng đây thực sự là một câu hỏi thú vị.

— xác nhận

3

Lỗi đã được sửa.

— ThePiercingPrince

Đồng hồ hệ thống sẽ không (dù sao cũng không phải là hạt nhân hợp lý); một số cấu trúc dữ liệu (và các chương trình sử dụng nó) có thể biểu hiện hành vi bất thường. Theo tôi, đây sẽ là một vấn đề với các thiết bị nhúng - những thiết bị ít có khả năng chạy mã hiện tại hơn nhiều.

— Piskvor

1

@hmayag: Tôi không nghĩ "máy nướng bánh mì", giống như "bộ điều khiển đèn giao thông". Những thứ đó chắc chắn hơn một chút so với thiết bị điện tử tiêu dùng và có thể dễ dàng vượt quá tuổi thọ đó (với sự thay thế một phần , nhưng có thể không cần nâng cấp) - IIRC, có một số vấn đề với thiết bị điện tử những năm 1980 chỉ sau Y2K.

— Piskvor

13

Không, nó sẽ không thất bại. Trong trường hợp xấu nhất, theo quan điểm của một lập trình viên, nó sẽ hoạt động như mong đợi: nó sẽ được đặt lại cho đến ngày 1901-12-13 20:45:51:

nhập mô tả hình ảnh ở đây

Điều này trong trường hợp bạn sẽ không cập nhật các bản phân phối hiện tại của mình cho đến khi điều này xảy ra. " Cập nhật rất dễ dàng. Một trong những cập nhật này chắc chắn sẽ có bản sửa lỗi. " Như chocobai nói.

Tôi nhớ rằng đó là vấn đề / câu hỏi tương tự với các máy 16 bit trước năm 2000 và cuối cùng, nó không có vấn đề gì.

Một giải pháp từ Wikipedia:

Hầu hết các hệ điều hành được thiết kế để chạy trên phần cứng 64 bit đã sử dụng time_tsố nguyên 64 bit đã ký . Sử dụng giá trị 64 bit đã ký giới thiệu một ngày hoàn thành mới lớn hơn gấp hai mươi lần so với tuổi ước tính của vũ trụ: khoảng 292 tỷ năm kể từ bây giờ, lúc 15:30:08 vào Chủ nhật, ngày 4 tháng 12, 29.277.026.596. Khả năng tính toán vào các ngày bị hạn chế bởi thực tế làtm_yearsử dụng giá trị int 32 bit đã ký bắt đầu từ năm 1900 trong năm. Điều này giới hạn năm tối đa là 2.147.485.547 (2.147.483.647 + 1900). Mặc dù điều này giải quyết vấn đề khi thực hiện các chương trình, nhưng nó không giải quyết được vấn đề lưu trữ giá trị ngày trong các tệp dữ liệu nhị phân, nhiều trong số đó sử dụng các định dạng lưu trữ cứng nhắc. Nó cũng không giải quyết được vấn đề đối với các chương trình 32 bit chạy dưới các lớp tương thích và có thể không giải quyết được sự cố đối với các chương trình lưu trữ giá trị thời gian không chính xác trong các biến của các loại khác time_t.

Tôi sử dụng Ubuntu 13.04 trên 64 bit và vì tò mò, tôi đã thay đổi thủ công thời gian thành 2038-01-19 03:13:00. Sau 03:14:08 không có gì xảy ra:

Ngày và thời gian trước 2038-01-19 03:14:08 Ngày và thời gian sau 2038-01-19 03:14:08

Vì vậy, không có gì phải quan tâm về vấn đề này.

Thông tin thêm về:

— Radu Rădeanu
nguồn

9

Nếu nó được đặt lại, nó thất bại bởi vì "fail" Tôi có nghĩa là "không hoạt động hoặc làm việc không chính xác".

— ThePiercingPrince

1

@LinuxDistance Điều này xảy ra theo quan điểm của bạn. Nhưng theo quan điểm của một lập trình viên, nó sẽ hoạt động như mong đợi: nó sẽ thiết lập lại . Điều này cũng tương tự với sự kết thúc của lịch Maya: thế giới đã không thất bại vì điều này.

— Radu Rădeanu

10

Tôi không đồng ý? từ quan điểm của một lập trình viên, đồng hồ không cần thiết lập lại, vì vậy nó sẽ thất bại

— Nanne

3

Thảo luận này trong các ý kiến là imo vô nghĩa. Câu hỏi là "Hạt nhân Linux hoặc Ubuntu đã sẵn sàng để xử lý ngày sau này chưa?". Chà, nó không có khả năng xử lý những ngày như vậy, nên nó thất bại trong bối cảnh của câu hỏi này.

— gertvdijk

2

@gertvdijk " Hạt nhân Linux " hiện tại / thực tế "đã sẵn sàng để xử lý ngày sau này chưa?"

— Radu Rădeanu

7

Bạn có thể kiểm tra xem thời gian máy tính của bạn có bị sập hay không bằng cách sử dụng tập lệnh Perl sau:

#!/usr/bin/perl
use POSIX;
$ENV{'TZ'} = "GMT";
for ($clock = 2147483641; $clock < 2147483651; $clock++) {
    print ctime($clock);
}

Nếu máy tính của bạn sẽ ổn, bạn sẽ nhận được điều này:

Tue Jan 19 03:14:01 2038
Tue Jan 19 03:14:02 2038
Tue Jan 19 03:14:03 2038
Tue Jan 19 03:14:04 2038
Tue Jan 19 03:14:05 2038
Tue Jan 19 03:14:06 2038
Tue Jan 19 03:14:07 2038       <-- Last second in 32-bit Unix systems
Tue Jan 19 03:14:08 2038
Tue Jan 19 03:14:09 2038
Tue Jan 19 03:14:10 2038

Nếu máy tính của bạn giống như của tôi, nó sẽ quấn quanh như thế này:

Tue Jan 19 03:14:01 2038
Tue Jan 19 03:14:02 2038
Tue Jan 19 03:14:03 2038
Tue Jan 19 03:14:04 2038
Tue Jan 19 03:14:05 2038
Tue Jan 19 03:14:06 2038
Tue Jan 19 03:14:07 2038
Fri Dec 13 20:45:52 1901
Fri Dec 13 20:45:52 1901
Fri Dec 13 20:45:52 1901

Nó cũng có thể làm điều này:

Tue Jan 19 03:14:01 2038
Tue Jan 19 03:14:02 2038
Tue Jan 19 03:14:03 2038
Tue Jan 19 03:14:04 2038
Tue Jan 19 03:14:05 2038
Tue Jan 19 03:14:06 2038
Tue Jan 19 03:14:07 2038
Tue Jan 19 03:14:07 2038
Tue Jan 19 03:14:07 2038
Tue Jan 19 03:14:07 2038

— SkylarMT
nguồn

Tôi nghĩ bạn đang thử nghiệm Perl ở đây chứ không phải hệ điều hành thực sự trong lõi. Hoặc là bạn, với việc sử dụng ctime?

— gertvdijk

@gertvdijk Vâng, nó cung cấp đầu ra đầu tiên trên các máy tính được vá và máy tính xách tay Ubuntu của tôi cung cấp thứ hai, trong khi thứ ba là từ máy chủ Debian của tôi. Tôi đã không thực sự viết mã, nó trên Internet ở dạng chính xác như vậy.

— SkylarMT

2

xác nhận. Nếu bạn có một máy 64 bit, thì nó sẽ ổn thôi. Bên cạnh đó ... ai trong chúng ta sẽ có máy chỉ 32 bit vẫn chạy trong năm 2038?

— JRG

1

Tôi đã tìm kiếm điều này để minh họa vấn đề năm 2038 cho đồng nghiệp và 2 năm sau khi đưa ra nhận xét trên, tôi có rất ít nghi ngờ rằng vào năm 2038 chúng ta sẽ có máy 32 bit sẽ thất bại. Ah, tuổi trẻ lạc quan.

— JRG

@James, có thể một số vô tình. Có lẽ sẽ có Linux 32 bit được nhúng trong các thiết bị IoT vào khoảng thời gian đó, chưa được vá. Ngày tận thế? Không. Một số rắc rối ở một số nơi? Chắc chắn rồi.

— Giáo sư Falken hỗ trợ Monica

3

Tôi đã viết và xuất bản một bài báo ngắn về điều này vào năm 1996. Điều này bao gồm một chương trình C ngắn để chứng minh điều đó. Tôi cũng đã có email với David Mills về các vấn đề tương tự với NTP - Giao thức thời gian mạng. Trên máy tính xách tay Ubuntu 14.04 64 bit của tôi, mã perl không thể hiện giới hạn nên các lib 64 bit cơ bản phải được sửa đổi.

Tuy nhiên, việc chạy mã kiểm tra từ lâu của tôi sẽ hiển thị thời gian kết thúc trở lại UNIX Epoch. Vì vậy, không phải tất cả đều tốt với mã 32 bit từ quá khứ.

Bài báo năm 1996 của tôi, Thời gian UNIX sẽ hết vào năm 2038! đã có mặt trên trang web của tôi từ khoảng năm 2000. Một biến thể của tiêu đề "Thời gian UNIX" này đã được xuất bản năm 1998 trong "Năm 2000 Thực tiễn tốt nhất cho máy tính thiên niên kỷ Y2K" ISBN 0136465064.

— oldunixguy
nguồn

2

Linux 64-bit đã sẵn sàng, ít nhất là nếu bạn đang nói về các giao diện hệ điều hành cốt lõi (tất nhiên các ứng dụng riêng lẻ vẫn có thể làm hỏng nó). Theo truyền thống, time_t được định nghĩa là bí danh cho "dài" và "dài" trên linux 64 bit là 64 bit.

Tình huống đối với Linux 32 bit (và lớp tương thích cho các tệp nhị phân 32 bit trên Linux 64 bit) ít màu hồng hơn nhiều. Nó bị hỏng và sửa nó mà không phá vỡ tất cả các nhị phân hiện có không phải là một nhiệm vụ dễ dàng. Toàn bộ API sử dụng time_t và trong nhiều trường hợp, nó được nhúng như một phần của cấu trúc dữ liệu, do đó, không chỉ các API phải được sao chép cấu trúc dữ liệu mà chúng hoạt động cùng.

Ngay cả khi có một số mức độ tương thích ngược, tất cả các nhị phân muốn có thời gian chính xác sẽ cần phải được xây dựng lại để sử dụng giao diện thời gian 64 bit mới.

Đã có một số công việc được thực hiện (ví dụ: https://lwn.net/Articles/643234/ và http://www.sourceware.org/ml/libc-alpha/2015-10/msg00893.html ) nhưng chúng tôi cho biết vẫn còn một chặng đường dài từ một giải pháp đầy đủ. Vẫn chưa rõ liệu sẽ có phân phối 32-bit có mục đích chung là Y2K38 an toàn hay không.

— Peter Green
nguồn