24 декабря Архивач восстановлен после серьёзной аварии. К сожалению, значительная часть сохранённых изображений и видео была потеряна. Подробности случившегося. Мы призываем всех неравнодушных помочь нам с восстановлением утраченного контента!
В 2038 году... Представьте, сейчас 19 января 2038 года, и когда вы встаете, вы обнаруживаете, что в
Представьте, сейчас 19 января 2038 года, и когда вы встаете, вы обнаруживаете, что ваш mariadb не запускается , ваши программы на python2 перестают компилироваться , memcached ведет себя неправильно, ваши резервные копии имеют странные метки времени и rsync ведет себя странно .
И все это потому, что в какой-то момент разработчики UNIX объявили time_t тип 32-битным целым числом со знаком, отсчитывающим секунды от 01 января 1970 года, так что 0x7ffffffff или 2147483647 является максимальным значением, которое может быть представлено. И это дает нам
Но не отчаивайтесь, так как я работал над воспроизводимыми сборками для openSUSE , я собирал наши пакеты на несколько лет вперед, чтобы увидеть их влияние, и недавно изменил тесты с +15 на +16 лет, чтобы изучить эти проблемы. 2038 год. По крайней мере, те, которые появляются в наших тестах времени сборки x86_64.
Надеюсь, к тому времени 32-битные системы будут свернуты, потому что у них будут свои дополнительные проблемы.
Многие исправления уже отправлены, и наверняка последуют другие, так что, надеюсь, 19 января 2038 года пройдет так же без происшествий, как и 01 января 2000 года.
>>275006986 (OP) Что за шизофрения. Не может компьютер от смены времени просто перестать работать ебаный ты даун. Хоть в 2228 году запусти пк все будет работать
Шиз... 1. Попробуй до 2023 дожить. 2. Покажи программу, которая вышла до 2006 года (16 лет назад), и которой ты до сих пор пользуешься, не обновляя её. 3. Переводишь в 2038 году часы на 1999, 2010 или 2021 год - и пользуешься дальше.
>>275006986 (OP) >mariadb не запускается >программы на python2 перестают компилироваться >memcached ведет себя неправильно Не пользуюсь этой парашей. мимо питухон бэкендер
Просто значение переменной обнулится и система выдаст дату: 01 января 1970 года. Когда батарейка в биосе садится дата сбивается, и ничего страшного не происходит.
>>275008814 В 2038 году у всех будут нейроинтерфейсы, не пизди. Не забывай, что мы уже живём при хрущёвском коммунизме, всем ещё 20 лет назад Горбачёв выдал по 2 квартиры каждому, Путин сделал Россию первой мировой экономикой, Чечня стала мировым туристическим объектом и так далее.
>>275014115 >Меняю на 2022 год. Все. Никаких больше ошибок. Спорю на твоё очко, что если ты сейчас поставишь 2010 год и зайдёшь хоть на гугл, хоть на двач, то получишь ошибку.
>>275014218 Не приплетай больше - кринжево получается. Ты вообще помнишь, что было в 2006? Мегабитный интернет по ADSL. А тот VR, что сегодня обыденность и навевает зевоту, знали только по "Газонокосильщику". И если ты намереваешься в 2038 в силу тех или иных обстоятельств отставать в развитии, внутренне или внешне... то зачем тебе это всё? Переведи календарь на 2021 год - и готово. Гармония формы с содержанием.
>>275014115 >Меняю на 2022 год И лососнёшь на том, что завязано на https://, включая игори, мессенджеры и просто браузеринг. все TLS-рукопожатия будут фейиться из-за просроченных сертификатов из будущего, формально они тоже будут просроченными, у них срок действия ограничен верхней и нижней границей. Как имаджиниуется в 2038 без интернетиков, хз.
>>275015404 >Ты вообще помнишь, что было в 2006? Да. Я пекабоярин с 1992 года. >А тот VR, что сегодня обыденность и навевает зевоту, знали только по "Газонокосильщику". На вселенные Цукерберга будем смотреть так же, инфа сотка. >И если ты намереваешься в 2038 в силу тех или иных обстоятельств отставать в развитии S-образная кривая развития? Нет, не видел.
>>275016359 Следствие того, что на 32-битной системе time() возвращает 32-битный time_t. И стебаться тут надо над твоим незнанием предмета, о котором споришь.
>>275016558 Формально разрядность проца никак не влияет на разрядность вычислений. Любой 16-битный 286-й прекрасно считает 32 и выше разрядную математику. Те же фракталы с 2048 и выше битностью считабтся на 32битно шинде. Изначальная мессага "Поставь на своём роутере 2039 год. Там 32-битный проц." вызывает бурление. Наиболее ВЕРОЯТНО, что там на 32битном проце будет 32битный линух, но это не точно.
>>275006986 (OP) > ваши программы на python2 перестают компилироваться Чел, ты... Да и это говно мамонта уже прекратили поддерживать, и уже выпиливают из основных реп арча например
Остальное нормально поддерживается и обновляется, так что все банально пофиксят
>>275016942 Говорю же я гумунитарий. Знаю ток что на роутере кнопочка перезагрузки есть. А зачем ему дата нужна и где она я не ебу Знал бы хоть 4000 год заебашил.
>>275016558 Если за 16 лет никто не почешется заменить время на 64 битное, когда все условия созданы, то переведёшь на 2021 год часы своего роутера (и я всё ещё не против узнать, зачем они в нём): https://lwn.net/ml/linux-kernel/[email protected]/
>>275006986 (OP) Если ты интересовался этим дерьмом, то должен был слышать о проблеме 2000-ых. Тогда была чуть не истерия. Ну там много чего было, не только в айти. Всякие шизы ждали не то прилёта инопланетян, не то конца света, судного дня... И вот перескочили отметку 2к, а компы как работали, так и работают. То же и с сабжем.
>>275017262 > и я всё ещё не против узнать, зачем они в нём Для существования всех сетевых устройств в одних временных рамках. Это важно и для поиска ошибок и безопасности, ну и в целом отслеживания состояния сети
>>275017303 А зачем это обычному двачеру то? С какой целью? Я если честно даже незнаю что значит эти ебучие 32 64 и 86 бит. Нахуя мне это. Но в то что-то может сломаться от смены времени я убейте не поверю вам.
>>275017786 1970 только, но в целом ты прав. И не на всех, а только на тех, где еще не пофиксили. Так что раздрай будет, но 99% до 38 года скорее всего пофиксят, под удар попадут совсем уж слоупоки
>>275017612 Я уже нашёл ошибку - использовать в 2038 году сетевое устройство с линупсом, на котором ядро и прочее ПО не менялось с 2019 года. AI-пентесты будут таких единорожек как танк на гусеницы наматывать.
Похуй всем, никто даже сейчас 32 битным говном не пользуется, в 2038 и подавно не будут, если там что-то даже на серверах имеет такую проблему, к 2038 уже всё обновят. На интерес 1% дебилов-ретроградов, конечно же, всем похуй.
>>275018934 В дебилане осталось 100 проц, там штабильность это национальная идея. Ну и во всех деривативах, и зависящих от пакетной базы, если только те целенаправленно не выпилили
>>275006986 (OP) >Представьте, сейчас 19 января 2038 года, и когда вы встаете, вы обнаруживаете, что mariadb вашего барина не запускается , программы на python2 вашего барина перестают компилироваться , memcached ведет себя неправильно, резервные копии вашего барина имеют странные метки времени и rsync ведет себя странно . Проблемы барина. Мне дома все это говно не нужно.
>>275016719 >Формально разрядность проца никак не влияет на разрядность вычислений. Любой 16-битный 286-й прекрасно считает 32 и выше разрядную математику. Спасибо, кэп. Но я пытаюсь донести, что на 32-битном линухе проще всего получить время вызовом time(NULL), который вернёт 32-битное значение. Как можно получить 64-битное время на 32-битном линухе одной командой? >Наиболее ВЕРОЯТНО, что там на 32битном проце будет 32битный линух, но это не точно. Видел один раз роутер с VxWorks, но я под него ничего не писал и не собираюсь.
>>275006986 (OP) Что мешает за день до этого происшествия перемотать время в системе на 1 января 1970? Нахуй в 2038 пользоваться 32-битным говном мамонта?
>>275026543 >почему нет? Может потому что это говно в 2038 благополучно умрёт? На самом деле, такой же бред, как и проблема 2000. Вангую, к 38 году либо не останется ничего 32-битного, либо будет запилен какой-нибудь костыль.
>>275026050 Тебе не понятно, что сложнее, если никогда не программировал на ассемблере. Тогда ЦП были даже не 32-битными, а 16-битными. 64-битные типы... это были очень нишевые программистские трюки. И лишние два байта на структуру, когда данные упаковывались до побитового кодирования и BCD - невероятная роскошь.
>>275026734 Не, ну это-то как раз все понятно, значит все-таки производительность. Справедливости ради, с позиции сегодняшнего время это уже надо разъяснять ИМХО.
Представьте, сейчас 19 января 2038 года, и когда вы встаете, вы обнаруживаете, что ваш mariadb не запускается , ваши программы на python2 перестают компилироваться , memcached ведет себя неправильно, ваши резервные копии имеют странные метки времени и rsync ведет себя странно .
И все это потому, что в какой-то момент разработчики UNIX объявили time_t тип 32-битным целым числом со знаком, отсчитывающим секунды от 01 января 1970 года, так что 0x7ffffffff или 2147483647 является максимальным значением, которое может быть представлено. И это дает нам
>date -u -Iseconds -d@2147483647
>2038-01-19T03:14:07+00:00
Но не отчаивайтесь, так как я работал над воспроизводимыми сборками для openSUSE , я собирал наши пакеты на несколько лет вперед, чтобы увидеть их влияние, и недавно изменил тесты с +15 на +16 лет, чтобы изучить эти проблемы. 2038 год. По крайней мере, те, которые появляются в наших тестах времени сборки x86_64.
Надеюсь, к тому времени 32-битные системы будут свернуты, потому что у них будут свои дополнительные проблемы.
Многие исправления уже отправлены, и наверняка последуют другие, так что, надеюсь, 19 января 2038 года пройдет так же без происшествий, как и 01 января 2000 года.
https://bugzilla.opensuse.org/show_bug.cgi?id=1203310
https://build.opensuse.org/request/show/1003076
https://github.com/memcached/memcached/pull/927
https://github.com/borgbackup/borg/issues/6996
https://github.com/WayneD/rsync/issues/366