Firefox отображает полосы ввода черным цветом, уравнения - светло-серым
То, что вы видите - это распространенная "ошибка", известная как проблема 2038 года, она же ошибка Y2K38, которая все еще присутствует в 32-битных серверах Linux.
Примерно к 2000 году мы осознали, что кроме ошибки y2k/миллениума, будет еще одна ошибка, связанная со временем. (да, я был частью команды по "предотвращению" y2k)
Поскольку эпоха Unix - это 32-битный секундный счетчик, который начинался 1 января 1970 года и был только знаковым 32-битным целым числом, он имел (и все еще имеет в некоторых системах) верхний предел 03:14:07 UTC 19 января 2038 года. https://en.wikipedia.org/wiki/Year_2038_problem
В последних реализациях он был расширен до 64 бит.
Начиная с NetBSD версии 6.0 (выпущенной в октябре 2012 года), операционная система операционная система NetBSD использует 64-битный time_t как для 32-битной, так и для 64-битных архитектур. Приложения, которые были скомпилированы для более старого NetBSD с 32-битным time_t, поддерживаются через уровень двоичной уровень совместимости, но такие старые приложения все равно будут страдать от [13]
OpenBSD, начиная с версии 5.5, выпущенной в мае 2014 года, также использует 64-битное время для 32-битных и 64-битных архитектур. time_t как для 32-битной, так и для 64-битной архитектуры. В отличие от NetBSD, здесь нет слоя двоичной совместимости. Поэтому, приложения, ожидающие 32-битный time_t, и приложения, использующие что-либо отличное от time_t для хранения значений времени. отличные от time_t для хранения значений времени, могут сломаться.[14]
Linux использует 64-битный time_t только для 64-битных архитектур; чистый 32-битный ABI не изменяется из-за обратной совместимости.[15] Существует ведутся работы, в основном для встроенных систем Linux, по поддержке 64-битного time_t на 32-битных архитектурах
В качестве фольклорной истории и довольно продуманной мистификации, Джон Титор был отправлен назад во времени, чтобы получить мейнфрейм, чтобы помочь исправить проблемы наследия в будущем из-за ошибки 2038, и предсказал американскую гражданскую/ядерную войну под управлением Хиллари Клинтон в параллельной нашей реальности.
http://www.strangerdimensions.com/2011/10/03/john-titor-the-ibm-5100/
История Джона Титора началась в 2036 году. Титор принадлежал к команде из семи человек, отобранных для путешествия во времени. Он пережил невообразимые ужасы в мире, разрушенном эгоизмом, цинизмом и коррумпированным правительством, опустошенном ядерной войной. Что еще хуже, то немногое, что осталось от их технологий, было под угрозой. под угрозой из-за надвигающейся ошибки тайм-аута UNIX в 2038 году.
См. также https://en.wikipedia.org/wiki/9223372036854775807
Системы, использующие 32-битный тип, подвержены проблеме 2038 года. поэтому многие реализации перешли на более широкий 64-битный тип, с максимальным значением 263-1, соответствующим моменту времени 292 миллиарда лет от настоящего времени.
Итак, возвращаясь к вашему вопросу о ntpdate.
О пределе 2038 года. Проблема в том, что time_t был (есть) 32-битным signed int. Т.е. 32-битным целым числом с последним битом, предназначенным для сигнала. Поэтому, по сути, вы можете хранить только числа (то есть количество секунд между -0x7fffffff и +7fffffff (+2147483647). Таким образом, +2147483647 ограничивает представление временного интервала до 1 января 1970+2147483647 секунд, что означает, что ntpdate может хранить в вашей системе даты только до 03:14:07 UTC 19 января 2038 года.
Что касается дат после 2038 года, то проблема в том, что кодовые процедуры, преобразующие строки во внутреннее представление (time_t/32-битное целое число), заворачиваются или просто сбрасываются на день/0 секунду в зависимости от реализации библиотеки.
По поводу верхнего предела года. time_t в вашей системе является знаковым целым числом, поэтому библиотека делает проверку верхнего предела как значение беззнакового целого, что при +4294967295 секунд после 1 января 1970 года даст ей верхний предел где-то в районе 2106 года. В зависимости от реализации, проверка может действительно выполняться в строке больше или поведение обусловлено свойствами 32-битного целого числа, проверяя только код ntpdate.
INT_MAX (32 бита) = 2147483647
UINT_MAX (32 бита) = 4294967295 (0xffffffff)
От https://en.wikipedia.org/wiki/Year_2038_problem
Например, изменение time_t на беззнаковое 32-битное целое число, которое расширит диапазон до 2106 года, негативно повлияет на программы, которые хранят, извлекают или манипулируют датами до 1970 года, поскольку такие даты представлены отрицательными числами
В качестве последней сноски, имейте в виду, что в системе может отсутствовать соответствие y2k38 как в коде системы/ОС, так и в часах RTC.
На уровне ОС, переход на 64-битный linux (если архитектура позволяет) исправит это сейчас, или, надеюсь, 32-битный Linux исправит это в ближайшем будущем.
Что касается RTC в старых машинах, это означает, что вы получите искаженные данные после 2038 года, по крайней мере, в журналах, пока ntpd не включится и не исправит системную дату.
Я решил проблему, просто выполнив шаги, предложенные в записи ArchWiki, на которую Фокс ссылается в комментариях (Спасибо! ). В файл css пользовательского контента в моем каталоге firefox
~/.mozilla/firefox/xxxxxxxx.default/chrome/userContent.css
, я добавил следующий текст:
input:not(.urlbar-input):not(.textbox-input):not(.form control):not([type='checkbox']):not([type='radio']), textarea, select {
-moz-appearance: none !important;
background-color: white;
color: black;
}
#downloads-indicator-counter {
color: white;
}
, который после перезапуска Firefox решил проблему для меня.
Урок, который я извлек из этого, заключается в том, что в следующий раз нужно сначала проверить ArchWiki.
Вы можете переопределить тему gtk, используемую Firefox:
- перейдите к
about:config - создать строковый ключ
widget.content.gtk-theme-override - установите значение для любого названия светлой темы, например
Adwaita:light - перезапустите Firefox, чтобы применить