Ничего удивительного. Много где и у нас, а в Европе так особенно DOS все еще используется! Даже используют OS/2 (её итерации на современном железе) из-за определенных программ написанных еще в прошлом веке и инфраструктуры на них завязанной. Многое узкоспециализированное оборудование/устройства или даже ПО - намертво «прикручено» к ОС своего времени. Например у Майкрософта есть специальная программа (ESU) по получению платных обновлений безопасности для старых ОС. Когда предприятие или например армия США оплачивает труд программистов над работой по выпуску обновлений к ОС с истекшим жизненным циклом. Например XP или 7ка для терминалов. Даже на висту по-сути выходят обновы, только их не так просто скачать… В общем кратко - проще и дешевле поддерживать работу инфраструктуры или оборудования на старой ОС, чем полностью менять всё на новое.
Ну, не знаю. Я думаю, что даже для старых 32 битных систем можно выкатить патч на использование дополнительной 32 битной переменной для хранения количества переполнений. Но сначала перевести переменную даты в unsigned, чтобы а) добавить ещё некоторое количество времени после 19 января 2038 года б) при переполнении переменная уходила в 0, а не в минус. У нас в колледже на программировании такие задачи были, т.е. мы буквально должны были реализовывать на любую числовую переменную расширение long из c++
Проблема в процессоре. x86 конечно может прочитать 64 бита памяти. Но это не просто. Есть решения аппаратные и программные. Аппаратные есть не во всех x86 но в более "свежих" всёже имеются. При помощи этих инструкций можно с довольно малыми потерями действительно выполнять операции. Но все же потери будут от 2-ух раз медленнее и более. Проблемы с обращением к памяти, так как процессору надо одним тактом обращаться к адресу числа. Если в неподготовленный процессор прилетит 64бита, он не знает что с ним делать. По этому нельзя просто взять расширить переменные до 64бит и надеяться что процессор сможет это понять. Второй способ программный, как вы в примере колледжа предлложили. Не совсем понял как именно вы решали (сам я без образования, даже информатики не было в школе, учился на курсах). Но предположу вариант в виде создания структуры в которой будет несколько переменных которые буду представлять из себя разные части одного беспрерывного битового потока. И создание функционала для работы с этим новым типом данных. Но блин, даже предложенное изменение на беззнаковый, это изменение основного кода, что вообще без автора делать, занятие не бладорное вот вообще, 99% что будешь в дебаге долго и муторно ловить эту переменную по всему коду. Заплатка в виде нового типа, может и сработает, но это тоже сколькож работы, да и для оптимизации это явно не на пользу. Но... А сколько ме известно Современные ЯП и так умеют преобразовывать int64 в понятный для x86, но как это работает я не очень знаю. Да и один фиг нужно изменять исходники программ.
Я уже сталкивался с этим, в Московской Электронной Школе. Когда я зашел в дневник несколько дней назад, то у меня выскочила ошибка: «данные актуальны на 1 января 1970 года 3:00».
@ скорее всего относится. Отсчёт времени начался же с 1 января 1970 года в 3:00. Значит разработчики что-то сделали, что превысило лимит unix времени. Это повлекло за собой откат времени до 1970 года.
Ну, ничего удивительного. Ведь виндой без активации можно спокойно пользоваться без особых ограничений(кроме надписи и невозможности смены обоев и темы).
Программисты настолько ленивые, что вместо того, чтобы забить сразу большой объем под дату, или сделать иное решение, просто отодвигают проблему на 30-40 лет вперед, когда не им нужно будет с этим разбираться
@@keno_q ну так отодвигание проблемы на 30 лет и на несколько миллиардов это большая разница, согласись. И 64 бита под дату это где большое количество памяти? В 60-х?
@@shitposting_box Ну так я и сказал, что теперь это уже не проблема. Но если брать 64 бита, то как бы во всех 64-х разрядных столько и выделено, то есть проблема актуальна исключительно для 32-я разрядных систем (ну и с меньшей разрядностью тоже, но я сомневаюсь, что такие есть).
У меня есть идея для твоего видео: Расскажи ВСЮ историю и эволюцию виндовс словами, начиная с первой сборки windows 1.0, заканчивая с windows server 2022, чтобы сильно не заморачиваться, можно разделить видео на несколько частей, либо на отдельные эпизоды. Такое может занять ровно год.
У меня на старом 486 была проблема 2000-го года, когда BIOS при каждой перезагрузке переводил год на несколько лет вперёд или назад. Пришлось даже в автозагрузке программу запускать, которая исправляла это.
@Daniel Myslivets , а попробуй в каком-нибудь дистрибутиве Linux поставить эту дату в 292 миллиарда лет, и ещё: почему обсуждать нет смысла, тоже же интересно, что будет с системой!
Интересное видео. Пользуюсь Windows 7, пишу код на ассемблере. Знаю из опыта, что в ОЗУ по адресам 0x7FFE0014 и 0x7FFE0018 ведется отсчет даты по 1/10000000 секунде. На момент написания этого комментария по моим подсчетам там еще порядка 58070 лет в запасе, поэтому для Windows здесь вряд ли может быть проблема.
Это ж как "проблема 2000", когда люди тоже пророчили конец всем ПК (и даже больше того). Доходило даже до "инструкций по выживанию". Чрод, пока я это писал, автор сам дошёл до этой темы. Ну да ладно, Микрософты найдут способ этого избежать. Не случилось же армагеддона в 2000-м.
@@Fedor_Shtykov а не случился армашедон блогодоря 1 человеку которого называли шизиком и паранойком а после 2000 года обвиняли в обмане и мошенничестве
Я в 1999 году знал, что проблема 2000, скорее всего, фейк, потому что авторы фейка не знали о различии кода и данных, а я уже знал, хоть и мелкий был. Авторы писали, будто компьютер воспримет дату как команду на отключение, что есть полный бред. Однако, если вспомнить «лучшие практики» по написанию кода... Если в одной части программы возникает ошибка, то её не обрабатывают, а тупо кидают исключение. Либо программа просто падает от этой ошибки. Так, не очень давно в Сети появились обои, которые выводят из строя Android-смартфоны. Тупо в картинке не тот цвет, но программа, вместо того чтобы поправить цвет, падает с ошибкой. Если эта картинка на фоне, то падает весь андроид. Позорище просто, а не «лучшие практики».
8:22. Такая, на первый взгляд, мелочь, но очень приятная. Текст "Интересный факт: [и так далее]" находится ровно над субтитрами видео, и ничего не перекрывается! Такая забота о зрителях чрезвычайно приятна
Я как специалист, который видел многое в жизни, могу сказать что для России в частности это проблема. Дело в том что все ещё много где используется старое специализированное ПО, созданное под старое железо и старые ОС. Ну много кто видел в школах, пту и вузах старые компы на Windows Xp где все когда-то делали задания. Эти компьютеры используются также и на производстве, в научных исследованиях, в делопроизводстве и документообороте, в типографии и т.д. Как с этим быть? Сделать скрипт который будет исправлять проблему или тупо ждать изменения ситуации на рынке? Скорее всего ничего из этого.
Можно раз в 28 лет (4*7) скручивать -спидометр- календарь ровно на 28 лет назад, чтобы числа месяца и дни недели совпадали с текущим годом. На вставку даты в тело документа повесить скрипт. И до 1 марта 2100-го (невисокосного) года всё будет тип-топ. "А к тому времени кто-нибудь из нас троих обязательно умрёт - или я, или эмир, или ишак." (ц) Ходжа Насреддин. Правда, консольные команды 'ncal -e' и 'ncal -o' всё равно будут возвращать неправильную дату Пасхи. Ну да и пох▒й, Бога нет. ))))))
@@fediapupkin2983 , дружище, себя то я каждый день в зеркале вижу и могу руками потрогать, а вот Бог твой на глаза мне что-то ни разу не попадался, хоть и живу давно. Я считаю, что Иисус Иосифович Давидсон-Христос существовал на самом деле, был обычным человеком, и его УБИЛИ оккупанты, на восстание против которых он поднимал свой народ. А "воскрес" самозванец, в котором даже ученики, съевшие с Иисусом пуд соли, не признали Учителя. Потом они, правда, быстро сообразили, что получится хороший Пи-Ар народного движа, и таки официально признали чужака. Соцсетей тогда не было, и как на самом деле выглядит Спаситель мало кто знал. Иначе предатель Иуда властям не понадобился бы. А Днюху Христа я совершенно искренне праздную, бо пацан был правильный и умер за правое дело.
@@ЯрославИгошин-ъ2э , а почему не получится-то? Программа, хоть пиратская, хоть легальная, запрашивает время у операционной системы, и если синхронизацию системного времени заблокировать, то никаких конфликтов возникнуть не должно.
Что значит верите ли в проблему? Вера - предмет иррациональный и безумный по сути своей. Проблема обминусения дат существует. Главное понять насколько распространены старые системы, подверженные этой проблеме и насколько мы от них зависим. Скажем, насколько стары и непропатчиваемы программы управления автомобильным/авиаоцинным движением, или атомными реакторами, или старые спутники или что там ещё производилось десятки лет назад. Это без всякой веры может стать *реальной* проблемой.
В своих приборах, в ПО микроконтроллеров я так и использую time_t. Несколько лет назад я переобъявил time_t на unsigned long и доработал функции работы с времененем для работы в беззнаковом пространстве и тоже самое сделал программист на ПК для партнёрского ПО моих приборов когда время приборов затаскивается в Win. Новая граница отодвинулась до 2106 года, до которого нам уж точно не дожить.
Старые компы и так почти не работают, по причине отсутствия всяких SSE инструкций для проца, библиотек и невозможности у становить современное ПО, поэтому вообще параллельно, у кого вообще в 2038м году останется живой ПК с такой системой исчисления? 1- Старые компы ещё должны как то до этой даты дожить; 2- Не велика потеря если появится программный сбой; 3- Даже дожившие компы вообще будудт не дееспособные по меркам 2038 года, какая разница если таким старым компом даже сейчас пользоваться нельзя?
Древние контроллеры, спутники, системы ПВО и т.д. и т.п., что создано при царе Горохе и юзается до сих пор. Слышал на каких-то то ли судах то ли электростанциях обновления данных на 8-дюймовых дискетах присылают. И это в 20х годах 21го века.
Разного рода промышленная, военная, космическая электроника, медицинское оборудование. На заводах до сих пор можно встретить работающие станки начала 20 века. Это всё работает, выполняет свои функции и замена этого стоит много денег. Никто не будет менять станок ЧПУ, работающий под дос или вин 3.1 из-за какой то там мелочи с датами, просто тупо переведут дату и всё. Просто будет немного больше неудобств.
почти во всех организациях за старые ПК держатся мёртвой хваткой потому что программы на них платные, установка платная и просто так взять перенести программу с одного ПК на другой не нарушая лицензионное соглашение не выйдет
Боюсь, что график зависимости видосов от подписок скорее будет похож на график функции корня, поскольку рано, или поздно ты достигнешь своего придела видосах
А я всё-таки считаю проблему актуальной. Сколько компов на CISC процессорах, с набором команд х86 до сих пор используется в этом мире, взять хотя бы бесчисленное количество заводов со станками ЧПУ.
@DanielM , 4:28, you made a typo in subtitles, in the word windows where its "Windoiws 2.0" / Вы сделали ошибку в субтитрах на 4:28, у вас там виндоивс 2.0
"На каждой железнодорожной станции есть автомат для выдачи билетов работающий на Windows" >На видео контекстное меню из линукс (судя по всему либо xfce либо lxqt) Критически важная инфраструктура, на винде. Как же.
Проблема надуманна и негативных последствий будет даже меньше, чем в 2000. К 2038 все актуальные программы и ОС будут 64 битными, да они уже сейчас такие, а если где-то заваляется раритетный ПК, например в каком-нибудь старом информационном табло на ЖД вокале, показывающем отправление и прибытие поездов, то можно будет откатить дату на несколько лет и забыть о проблеме на эти самые несколько лет.
Проблемы нет. ага, а потом вспоминаешь что некоторые компании (и банки, и аэропорты всякие) до сих пор сидят на старом железе и по. В японии до сих пор дискеты кое-где юзают😆
По мне так я просто переключю календарь на 2010-й там и дни недели совпадают с 2036 и соотношение года к высокосному, главное не забыть под новый 36 год переклячить дату, и не заходиьь в интернет😅
10:32 автор же понимает, что 64х битные архитектура, ОС и приложения ну вообще никак не связаны с данной проблемой? И это не причина, почему проблемы не будет. При нужном предусмотрении, можно и на 8ми битных процессорах продолжать прекрасно жить, причем это будет довольно маленькое (хоть и важное) предусмотрение.
Весь ролик пытался понять как взаимосвязана архитектура процессора, разрядность ОС и длинна хранящегося значения? Что мешает в 32х битной системе использовать более длинное значение в 64, 128 или 256?)
Насколько я понял проблема в основном для баз данных, в структуре которых нет (наверное нет, я не програмист) места для этого. То есть ячейка памяти только одна и для архитектуры 32 бит размер её - 32 бит. А в процессорах с архитектурой 64 бит и ячейка соответственно 64 бит. То есть старое железо вычитает некорректную дату создания файла созданого позднее 2038 с новых БД и запишет, при создании или редактировании файла дату 1970г. А новый проц, хотя на 2038 далеко не новый, на архитектуре 64 бита "увидит" дату 1970 . Хотя я могу ошибаться, кто знает лучше пускай поправит, буду знать как правильно.
@@valdemardodus6562 да нет. Проблема в значении, а не в том, где оно хранится, в БД или памяти. Очевидно, что структура int32 имеет свое максимальное значение и длину, и если явно указано, что мы храним значение в переменной int32, то максимум вот такой и это никак не зависит от архитектуры железа. В случае 64-битного или даже 128-битного железа максимальное значение int32 всегда будет одинаковым для всех и никак не изменится. Так что если для хранения какого-то числа (время или что-то другое) выбрано int32, то ошибка на всех системах и архитектурах будет проявлять всегда. Так же это справедливо и в обратную сторону про int64. С этим типом данных точно так же могут работать системы и старое железо, как 32-битные, так и 16-битные процессоры. Просто это число будет занимать больше памяти и обработка будет чуть медленнее, что в целом не будет заметно для пользователя. Так что проблема в целом высосана из пальца. Да, старый софт, для которого не будет патча, исправляющего проблему, может работать некорректно. Но к 2038-му году об этой проблеме даже не вспомнят, т.к. программы из нулевых будут неактуальны, новый софт будет лишен этого недостатка, а те "старые" программы которые будут нужны, будут исправлены.
Very enjoyable video, I liked seeing you test out Unix time in various OSes. Sorry if this comment can't be understood due to language barrier. The Y2K38 bug is a real problem that exists. Like with Y2K, it could've been a disaster if people didn't put in the effort to prevent it from happening, but fortunately people did. It's just that now that it's not a problem anymore, people take its absence for granted (though some of the scare around it was in fact quite exaggerated). It's worth noting that Unix time is the way it is because it's signed, which is what lets it show negative numbers; if it wasn't, the 32-bit version could display up to 4,294,967,295 seconds since Jan 1 1970 00:00, which would be Feb 07 2106 06:28:15. But the 60s weren't that long ago, so obviously people wanted to be able to display dates before 1970.
В 2000 году я работал в маленькой фирме, где были еще ПК на 80386 и руководство их менять не собиралось. Сделал крошечную программульку, которая запускалась перед запуском NC и предлагала подкорректировать дату вручную. Введенная дата запоминалась в BIOS и всё было в порядке. Согласен, что неудобно, но лучше так, чем никак
Никак не могу понять, за каким лядом во времени юникс учитывается знак. Без учёта знака было бы не 2 миллиарда секунд а четыре, что отодвинуло бы время наступления проблемы в два раза дальше (136 с копейками лет).
Существует много оборудования помимо компьютеров, серверов. Это промышленные контроллеры с 32-битной (чтоб подешевле) архитектурой и всего лишь эмуляцией операций с dword на "высоком уровне". Под капотом всё те же 32 бита. Много таких устройств уже сняты с производства и поддержки производителей, но продолжают работать, и наверняка очень много такой техники сумеет дожить до 2038 года. Это потребует серьёзной модернизации оборудования, либо способно привести к отказам
Так это вы ещё simbian s60 не подключали к интернету на современных сим-картах, где надо обновлять сертификаты безопасности, но ты не можешь подключиться потому что сертификаты устарели😂.
Я думаю в полной мере эта проблема будет касаться не обычных домашних пк, а чего-то более корпоративного. Например, те же банковские системы могут работать даже под DOS, и это ведь не шутка и преувеличение. Думаете через 14 лет что-то сильно изменится? Да вообще нет. Там может быть критический софт написанный вообще на каких-то фортранах, кобол и других древних языках специалистов под которых просто уже не существует. И вот такое вот легаси которое почти не возможно нормально обновить - пострадает или нужно будет вложить ахулиард денег на фикс бага. ЗЫ: Я кстати никогда не понимал, почему тип t_time является именно signed int 32 переменной, а не unsigned int 32. Использование uint 32 позволит расширить в два раза диапазон не в ущерб памяти отказавшись от чисел со знаком -. Ведь зачем unix time иметь отрицательные числа которые не используются? А так критическая дата смещается до 2106 года)
@@leviofanh поломка этих легаси кодов единственный способ заставить компании обновлять такое старье, так что не вижу ничего плохого в том что они забагуются.
@@ashstarwind9595 Этот современный подход, выкинуть, заменить, легаси говно... А зачем это делать? Ты можешь сказать? Что бы потратить ахулиард денег в трубу? Что бы наплодить багов? Есть некая система, она крайне важная, критичная и от нее зависит очень многое. Эта система развивалась на протяжении десятков лет, отточена и работает. Теперь встаёт закономерный вопрос: Зачем трогать то, что работает? Ты просто со своей потребительской колокольни думаешь, что это "так просто" и всем вокруг просто "лень". Так вот нет, это вообще не так просто. Это огромные, я бы даже сказал ГИГАНТСКИЕ вложения. И все это ради чего? Что бы система не числилась как "легаси"?
@@ashstarwind9595 Этот современный подход, выкинуть, заменить, легаси говно... А зачем это делать? Ты можешь сказать? Что бы потратить ахулиард денег в трубу? Что бы наплодить багов? Есть некая система, она крайне важная, критичная и от нее зависит очень многое. Эта система развивалась на протяжении десятков лет, отточена и работает. Теперь встаёт закономерный вопрос: Зачем трогать то, что работает? Ты просто со своей потребительской колокольни думаешь, что это "так просто" и всем вокруг просто "лень". Так вот нет, это вообще не так просто. Это огромные, я бы даже сказал ГИГАНТСКИЕ вложения. И все это ради чего? Что бы система не числилась как "легаси"?
Для тех, кто не понял, почему 2147483647. 2147483647 - это 2 в 31 степени минус 1 (так как остальные 2147483648 значений используются для записи нуля и отрицательных значений от -2147483648 до -1)
Эм, ну типа просто тип чисел меняешь и до какого-нибудь 2096 опять ждёшь и поменяешь на большее Также и в 1999 году сделали Ну и почти все приложения не рекомендуют работать в 32 бита
Я как-то раз слышал о таком и якобы в 2038 году компьютеры будут иметь сбой, но я честно говоря не знаю, на самом деле будет такое или нет, потому что мой знакомый отдал мне свой компьютер и там был Виндовс 11 и в календаре показывала 2251 год :) (точно уже не помню, но вроде этот год и показала)
Насколько я помню, проблема Y2K BAG была довольно опасной. Хотя не, ВЕСЬМА ОПАСНОЙ. Т.к. система автоматом ставила дату 1900 и т.д. некоторые банки перестали считывать карты, думая что они просроченные, некоторым заключённым повысился срок, те же проблемы с самолётами, крч проблема была везде, где многое контролировалось через пк, в том числе и ядерка. Самое забавное в том, что этот "армагедон" предсказали ещё за 20 лет и более, но начали с ней разбираться за пару месяцев :_)
Проверил на живом компьютере на 98 винде: включается, перезагружается, Мозила открывается, в интернет выходит, программки запускаются, игры и бенчмарки работают, текстовые документы сохраняются и открываются. Паинт не может сохранить картинку, выдает ошибку чтения из памяти. Некоторые игры не могут сохранить игровой прогресс и вылетают. Дата создания файлов работает и показывает "настоящее" время создания, то есть 19 января 2038 год 03:57:23 например.
Собственно, почему вызодит 238 миллиарда лет, обьясню: 2,147,000,000 это лимит int32 (тип данных для 32 битных процессоров) Но с выходом 64 битных это значение увеличилось до int64 (почитайте про лимит long типа данных), это примерно 9 квинтиллионов , что в человеческом времени 238 млрд лет, но Если использовать unsigned long (в 2 ра3а больше, чем long), то это значение увеличится в 2 раза (476млрд лет), откуда я жто знаю? я программист
@BladeBrawlXV я думаю кому интересно это вполне знают. Ну по крайней, вопросов подобных тут не встретил. Двоичной системе уже давно в школах учат. Ни кто правда там не понимает зачем она нужна и я не понимаю зачем грузят, но учат едва ли не первыми темами.
У меня проблема 2038 года заключается - как до этого года дожить
в военкомат не ходи, доживешь )
с таким посылом лучше и не доживай
@@crazy_paleontologist ухты, палео, здарова))
@@ВасяПупкин-ь9г8р зря
Увидел моченого в комментах жди беды. Народная примета.@@neizvesten.n
ребят, я из 2038 года, скоро новый год!
с новым 1901 годом вас!
@@toasterwithv8engine Вообще то при переполнии должно быть 1900 а не 1901. Поэтому дата не правильная.
@@orange_cpp душно
Ну так то счисление идёт с 1970. Почему 1900?
С 1970-м*
Ждем проблему 292 миллиардного года
Ну что ж, подождем
дети детей 292 милиарда раз только увидят это
Что-то мне подсказывает что 64 битных операционных систем там точно не будет. Как впрочем и солнечной системы
Через 3 миллиарда лет Земли не станет просто физически, так что это не проблема
сразу вспомнил как вчера лазил в биосе старого ноута. там дата начала гарантии была "00/00/2000"
Хахахахаххахаахахха
0/0/00 получается, прикол
а у меня год "рождения" бабушкиного ноута в биосе - 00.00.0000
@@kl1x-ddnetИисус из мира ноутов
У меня в биосе 2008
Древние люди в 2038...
Ага
... при помощи обычной советской...
смекалки и гаечным ключом...
2038 год по китайскому календарю 😂
@@Vasxi2005 реально древние... Сейчас же 7535 примерно, после первой 1000 лет считать по сути перестал😹
если что, 2038 год ближе, чем 2010!
@@TrairMain если что, любой год ближе чем те которые уже были
если что, любой год ближе чем те которые уже были
@@w1llszxd не надо два раза повторять
не надо два раза повторять
@vntbxy лагает ютубчек😈😈😈🔥🔥
Т.е человечеству не стоит сильно бояться Скайнета, он самовыпилится в 2038 году😂
Скайнет сто пудов будет х64, и потому не самовыпилится. Бойся его, кожаный мешок! ХА!.. ХА!.. ХА!..
@@Abdulla_Izrailyevich_von_Stahl мой фуфыкс с термоядерным разгоном остановит его
Камон, пушка которая сбивает дроны не самовыпилится в 2038
@@сиечелкоторыйПО_КА_КАЛ уверен? Были же случаи когда из-за одной циферки целые сети ложились и ОС самолётов тупили.
@@Arlate_ чего? Пушка "Скайнет" сбивает, выключает дроны, погугли что за оружие китайское
Предлагаю выставить это видео 19 января
2038 года)
в 03:14:07 по всемирному времени
Если учитывать новости то проблема 2038 года будет по большей части в Германии) просто вспомнил новость что их поезда все еще работают на виндовс 3
в россии на заводах многие чпу станки на вин 95,98 работают))
Ничего удивительного. Много где и у нас, а в Европе так особенно DOS все еще используется! Даже используют OS/2 (её итерации на современном железе) из-за определенных программ написанных еще в прошлом веке и инфраструктуры на них завязанной.
Многое узкоспециализированное оборудование/устройства или даже ПО - намертво «прикручено» к ОС своего времени.
Например у Майкрософта есть специальная программа (ESU) по получению платных обновлений безопасности для старых ОС. Когда предприятие или например армия США оплачивает труд программистов над работой по выпуску обновлений к ОС с истекшим жизненным циклом. Например XP или 7ка для терминалов. Даже на висту по-сути выходят обновы, только их не так просто скачать…
В общем кратко - проще и дешевле поддерживать работу инфраструктуры или оборудования на старой ОС, чем полностью менять всё на новое.
@@processor_moshniy ну круто что работают)) но это станок чпу на заводе, а не железнодорожная система всей страны)
@@mifolog777 ну и такие станки стоят на всех заводах явно не одной и той же модели но все же
@@Raya-Prime248 ну дык от выхода из строя станка явно погибнет меньше людей, чем от вышедшего из строя поезда...
Когда тебя уведомляют о проблеме 2038 года в 24, должно становиться страшно.
Но сейчас интересно! С днём рождения канала, Даня!🎉
Это же момент безопасности
@@bayigor5 Ну про проблему 2000 тоже знали за долго до этого
1991 уже решали её
О 2к также говорили
Всех с наступающим
Ну, не знаю. Я думаю, что даже для старых 32 битных систем можно выкатить патч на использование дополнительной 32 битной переменной для хранения количества переполнений. Но сначала перевести переменную даты в unsigned, чтобы
а) добавить ещё некоторое количество времени после 19 января 2038 года
б) при переполнении переменная уходила в 0, а не в минус.
У нас в колледже на программировании такие задачи были, т.е. мы буквально должны были реализовывать на любую числовую переменную расширение long из c++
а unsigned long long поможет?
@@SergeyVolkov ну в проприетарную программу вряд ли что-то запихнёшь, нужна альтернатива unix штампу времени
@@ashlamобычного лонга достаточно с головой, даже если он подписанный будет
Проблема что некоторый старый софт уже без исходников и патч придётся делать под каждую версию отдельно
Проблема в процессоре. x86 конечно может прочитать 64 бита памяти. Но это не просто. Есть решения аппаратные и программные.
Аппаратные есть не во всех x86 но в более "свежих" всёже имеются. При помощи этих инструкций можно с довольно малыми потерями действительно выполнять операции. Но все же потери будут от 2-ух раз медленнее и более. Проблемы с обращением к памяти, так как процессору надо одним тактом обращаться к адресу числа. Если в неподготовленный процессор прилетит 64бита, он не знает что с ним делать. По этому нельзя просто взять расширить переменные до 64бит и надеяться что процессор сможет это понять.
Второй способ программный, как вы в примере колледжа предлложили. Не совсем понял как именно вы решали (сам я без образования, даже информатики не было в школе, учился на курсах). Но предположу вариант в виде создания структуры в которой будет несколько переменных которые буду представлять из себя разные части одного беспрерывного битового потока. И создание функционала для работы с этим новым типом данных. Но блин, даже предложенное изменение на беззнаковый, это изменение основного кода, что вообще без автора делать, занятие не бладорное вот вообще, 99% что будешь в дебаге долго и муторно ловить эту переменную по всему коду. Заплатка в виде нового типа, может и сработает, но это тоже сколькож работы, да и для оптимизации это явно не на пользу. Но... А сколько ме известно Современные ЯП и так умеют преобразовывать int64 в понятный для x86, но как это работает я не очень знаю. Да и один фиг нужно изменять исходники программ.
Я уже сталкивался с этим, в Московской Электронной Школе. Когда я зашел в дневник несколько дней назад, то у меня выскочила ошибка: «данные актуальны на 1 января 1970 года 3:00».
сталкивался с чем? мэш сам по себе кривой, это не относится к проблеме 2038 года
@ скорее всего относится. Отсчёт времени начался же с 1 января 1970 года в 3:00. Значит разработчики что-то сделали, что превысило лимит unix времени. Это повлекло за собой откат времени до 1970 года.
@ ничего не откатывали, там просто код кривой
@@Monserzx экспертное мнение
@ это очевидно, если бы дату сервака откатили сайт бы просто перестал быть доступен ибо сервак не смог бы выйти в интернет
мой пентиум б960 пережил все, живет, и будет жить, какаято простая дата ему не помеха
Помню как я в этом году увидел на кассе самообслуживания надпись активировать Windows😂
Ну, ничего удивительного. Ведь виндой без активации можно спокойно пользоваться без особых ограничений(кроме надписи и невозможности смены обоев и темы).
@@Bluedion у меня всё менялось. Да я через КМС спокойно активировал чтоб надпись не мешала
@@Bluedion WinXP нельзя было
@@Bluedion Не поставить нескучных обоев :c
О наконец то кто то из блогеров стал озвучивать эту проблему!! Это достойно, спасибо тебе за контент!
Программисты настолько ленивые, что вместо того, чтобы забить сразу большой объем под дату, или сделать иное решение, просто отодвигают проблему на 30-40 лет вперед, когда не им нужно будет с этим разбираться
Так ведь любое увеличение объёма это отодвигание проблемы на n лет. Нафиг надо столько памяти тратить? Хотя сейчас уже можно себе такое позволить.
@@keno_q ну так отодвигание проблемы на 30 лет и на несколько миллиардов это большая разница, согласись. И 64 бита под дату это где большое количество памяти? В 60-х?
@@shitposting_box Ну так я и сказал, что теперь это уже не проблема. Но если брать 64 бита, то как бы во всех 64-х разрядных столько и выделено, то есть проблема актуальна исключительно для 32-я разрядных систем (ну и с меньшей разрядностью тоже, но я сомневаюсь, что такие есть).
До 2038 года ещё дожить надо.
Кому надо?
Если 3 мировой не будет будем жить
@@S.T.A.L.K.E.R-o5u Она уже началась !
@@nasefx8562 надеюсь что быстро закончится
@@БрутальныйДядькакому надо тот доживет
Я сегодня удивлён тому что RUclips очень быстро отправил что ролик вышел 😳
У меня есть идея для твоего видео:
Расскажи ВСЮ историю и эволюцию виндовс словами, начиная с первой сборки windows 1.0, заканчивая с windows server 2022, чтобы сильно не заморачиваться, можно разделить видео на несколько частей, либо на отдельные эпизоды. Такое может занять ровно год.
У меня на старом 486 была проблема 2000-го года, когда BIOS при каждой перезагрузке переводил год на несколько лет вперёд или назад. Пришлось даже в автозагрузке программу запускать, которая исправляла это.
"Пока DOS кайфует в 2024, Windows отдыхает в 124 - они совершенно на разных уровнях." цитата Daniel Myslivets
@Daniel Myslivets , а попробуй в каком-нибудь дистрибутиве Linux поставить эту дату в 292 миллиарда лет, и ещё: почему обсуждать нет смысла, тоже же интересно, что будет с системой!
Да кстати
Спустя долгое время, СНОВА ЭКСПЕРИМЕНТЫ!
Интересное видео. Пользуюсь Windows 7, пишу код на ассемблере. Знаю из опыта, что в ОЗУ по адресам 0x7FFE0014 и 0x7FFE0018 ведется отсчет даты по 1/10000000 секунде. На момент написания этого комментария по моим подсчетам там еще порядка 58070 лет в запасе, поэтому для Windows здесь вряд ли может быть проблема.
06.06.2079 smalldatetime
Это ж как "проблема 2000", когда люди тоже пророчили конец всем ПК (и даже больше того). Доходило даже до "инструкций по выживанию".
Чрод, пока я это писал, автор сам дошёл до этой темы. Ну да ладно, Микрософты найдут способ этого избежать. Не случилось же армагеддона в 2000-м.
@@Fedor_Shtykov а не случился армашедон блогодоря 1 человеку которого называли шизиком и паранойком а после 2000 года обвиняли в обмане и мошенничестве
У меня вопрос. А что будут делать люди, которые захотят после 2038 года воспользоваться эмуляторами старой винды?
@@pyongyangesekimchi1804 старую дату ставить
ну, вплоть до виндовс хп есть 64 до битная версия, после хз
А что им помешает просто выставить более раннюю дату?
Тот же вопрос.
Либо вручную поменяют дату, либо в эмуляторе будет настройка для такого. Не сегодня то попозже вставят
2:35 числительные склонять не умеем 😅 видео интересное )
ыыыы, я понял свой просчёт на моменте постпрода))))
будет проблема с корневыми сертификатами. головная боль для контроллеров домена, еxchange server ит.д.
Я в 1999 году знал, что проблема 2000, скорее всего, фейк, потому что авторы фейка не знали о различии кода и данных, а я уже знал, хоть и мелкий был. Авторы писали, будто компьютер воспримет дату как команду на отключение, что есть полный бред. Однако, если вспомнить «лучшие практики» по написанию кода... Если в одной части программы возникает ошибка, то её не обрабатывают, а тупо кидают исключение. Либо программа просто падает от этой ошибки. Так, не очень давно в Сети появились обои, которые выводят из строя Android-смартфоны. Тупо в картинке не тот цвет, но программа, вместо того чтобы поправить цвет, падает с ошибкой. Если эта картинка на фоне, то падает весь андроид. Позорище просто, а не «лучшие практики».
8:22. Такая, на первый взгляд, мелочь, но очень приятная. Текст "Интересный факт: [и так далее]" находится ровно над субтитрами видео, и ничего не перекрывается! Такая забота о зрителях чрезвычайно приятна
Я уже видел это 25 лет назад
как себя будут вести базы данных в 2038 году?
mssql, posgtresql, mariadb.
как будет себя чувствовать clickhouse, vmware vsphere, hyper-v?
Какой то набор букв зачем выписываете? Шифруетесь? Шпион.
Я как специалист, который видел многое в жизни, могу сказать что для России в частности это проблема. Дело в том что все ещё много где используется старое специализированное ПО, созданное под старое железо и старые ОС. Ну много кто видел в школах, пту и вузах старые компы на Windows Xp где все когда-то делали задания. Эти компьютеры используются также и на производстве, в научных исследованиях, в делопроизводстве и документообороте, в типографии и т.д.
Как с этим быть? Сделать скрипт который будет исправлять проблему или тупо ждать изменения ситуации на рынке? Скорее всего ничего из этого.
Можно раз в 28 лет (4*7) скручивать -спидометр- календарь ровно на 28 лет назад, чтобы числа месяца и дни недели совпадали с текущим годом. На вставку даты в тело документа повесить скрипт. И до 1 марта 2100-го (невисокосного) года всё будет тип-топ. "А к тому времени кто-нибудь из нас троих обязательно умрёт - или я, или эмир, или ишак." (ц) Ходжа Насреддин.
Правда, консольные команды 'ncal -e' и 'ncal -o' всё равно будут возвращать неправильную дату Пасхи. Ну да и пох▒й, Бога нет. ))))))
@@Abdulla_Izrailyevich_von_Stahl скорей тебя нет чем Бога !
@@Abdulla_Izrailyevich_von_Stahl ну может быть если программы пиратские это сработает, а если официальные, то просто так не получится.
@@fediapupkin2983 , дружище, себя то я каждый день в зеркале вижу и могу руками потрогать, а вот Бог твой на глаза мне что-то ни разу не попадался, хоть и живу давно.
Я считаю, что Иисус Иосифович Давидсон-Христос существовал на самом деле, был обычным человеком, и его УБИЛИ оккупанты, на восстание против которых он поднимал свой народ.
А "воскрес" самозванец, в котором даже ученики, съевшие с Иисусом пуд соли, не признали Учителя. Потом они, правда, быстро сообразили, что получится хороший Пи-Ар народного движа, и таки официально признали чужака. Соцсетей тогда не было, и как на самом деле выглядит Спаситель мало кто знал. Иначе предатель Иуда властям не понадобился бы.
А Днюху Христа я совершенно искренне праздную, бо пацан был правильный и умер за правое дело.
@@ЯрославИгошин-ъ2э , а почему не получится-то? Программа, хоть пиратская, хоть легальная, запрашивает время у операционной системы, и если синхронизацию системного времени заблокировать, то никаких конфликтов возникнуть не должно.
Что значит верите ли в проблему? Вера - предмет иррациональный и безумный по сути своей.
Проблема обминусения дат существует. Главное понять насколько распространены старые системы, подверженные этой проблеме и насколько мы от них зависим. Скажем, насколько стары и непропатчиваемы программы управления автомобильным/авиаоцинным движением, или атомными реакторами, или старые спутники или что там ещё производилось десятки лет назад. Это без всякой веры может стать *реальной* проблемой.
В принципе, как полумеру можно сделать формат unix time без знака, что увеличит диапазон значений в 2 раза.
не подписанное 64 битное число вот как можно сделать. а там уж такое большое максимальное число будет.
В своих приборах, в ПО микроконтроллеров я так и использую time_t. Несколько лет назад я переобъявил time_t на unsigned long и доработал функции работы с времененем для работы в беззнаковом пространстве и тоже самое сделал программист на ПК для партнёрского ПО моих приборов когда время приборов затаскивается в Win. Новая граница отодвинулась до 2106 года, до которого нам уж точно не дожить.
Долголетия каналу! Лайк сразу! Спасибо за контент!
Старые компы и так почти не работают, по причине отсутствия всяких SSE инструкций для проца, библиотек и невозможности у становить современное ПО, поэтому вообще параллельно, у кого вообще в 2038м году останется живой ПК с такой системой исчисления?
1- Старые компы ещё должны как то до этой даты дожить;
2- Не велика потеря если появится программный сбой;
3- Даже дожившие компы вообще будудт не дееспособные по меркам 2038 года, какая разница если таким старым компом даже сейчас пользоваться нельзя?
Древние контроллеры, спутники, системы ПВО и т.д. и т.п., что создано при царе Горохе и юзается до сих пор. Слышал на каких-то то ли судах то ли электростанциях обновления данных на 8-дюймовых дискетах присылают. И это в 20х годах 21го века.
@@rndofpipowe Добре хоч не на перфокартах
Разного рода промышленная, военная, космическая электроника, медицинское оборудование. На заводах до сих пор можно встретить работающие станки начала 20 века. Это всё работает, выполняет свои функции и замена этого стоит много денег. Никто не будет менять станок ЧПУ, работающий под дос или вин 3.1 из-за какой то там мелочи с датами, просто тупо переведут дату и всё. Просто будет немного больше неудобств.
почти во всех организациях за старые ПК держатся мёртвой хваткой потому что программы на них платные, установка платная и просто так взять перенести программу с одного ПК на другой не нарушая лицензионное соглашение не выйдет
@@ДядяИосиф-б8с куча станков и прочего спец оборудования работают на базе очень древнего железа, менять все это очень дорого и нерационально
Боюсь, что график зависимости видосов от подписок скорее будет похож на график функции корня, поскольку рано, или поздно ты достигнешь своего придела видосах
А я всё-таки считаю проблему актуальной.
Сколько компов на CISC процессорах, с набором команд х86 до сих пор используется в этом мире, взять хотя бы бесчисленное количество заводов со станками ЧПУ.
@DanielM , 4:28, you made a typo in subtitles, in the word windows where its "Windoiws 2.0" / Вы сделали ошибку в субтитрах на 4:28, у вас там виндоивс 2.0
Fixed 💙
"На каждой железнодорожной станции есть автомат для выдачи билетов работающий на Windows"
>На видео контекстное меню из линукс (судя по всему либо xfce либо lxqt)
Критически важная инфраструктура, на винде. Как же.
Проблема надуманна и негативных последствий будет даже меньше, чем в 2000. К 2038 все актуальные программы и ОС будут 64 битными, да они уже сейчас такие, а если где-то заваляется раритетный ПК, например в каком-нибудь старом информационном табло на ЖД вокале, показывающем отправление и прибытие поездов, то можно будет откатить дату на несколько лет и забыть о проблеме на эти самые несколько лет.
хоть кто-то начинает это упоминать, y2k 2.0
1:42 чая и печенек нет, морс подойдёт?
Наверное
За столько лет, мне кажется эту проблему успеют решить, а не как с y2k, когда узнали только-только и нужно было всё экстренно переделывать
ПОмню читал в книге Грахама Гласса, что 2000ый год Юниксу не страшен, что до 2037го он будет нормально работать.
А 2037ой ского.
Проблемы нет. ага, а потом вспоминаешь что некоторые компании (и банки, и аэропорты всякие) до сих пор сидят на старом железе и по. В японии до сих пор дискеты кое-где юзают😆
8:05 пусть только попробуют, это самый удобный музыкальный плеер вообще
Начинаем разработку х128 системы Виндос XNT 300.1 для решения проблемы 292 000 002 038 года)))
По мне так я просто переключю календарь на 2010-й там и дни недели совпадают с 2036 и соотношение года к высокосному, главное не забыть под новый 36 год переклячить дату, и не заходиьь в интернет😅
10:32 автор же понимает, что 64х битные архитектура, ОС и приложения ну вообще никак не связаны с данной проблемой? И это не причина, почему проблемы не будет. При нужном предусмотрении, можно и на 8ми битных процессорах продолжать прекрасно жить, причем это будет довольно маленькое (хоть и важное) предусмотрение.
10:08 debian - stabilno 👍👍👍
поздравляем с юбилеем!
Огромное спасибо)
Как показывает обстановка вокруг, нам было сначала дожить до этого 38
Весь ролик пытался понять как взаимосвязана архитектура процессора, разрядность ОС и длинна хранящегося значения? Что мешает в 32х битной системе использовать более длинное значение в 64, 128 или 256?)
Насколько я понял проблема в основном для баз данных, в структуре которых нет (наверное нет, я не програмист) места для этого. То есть ячейка памяти только одна и для архитектуры 32 бит размер её - 32 бит. А в процессорах с архитектурой 64 бит и ячейка соответственно 64 бит. То есть старое железо вычитает некорректную дату создания файла созданого позднее 2038 с новых БД и запишет, при создании или редактировании файла дату 1970г. А новый проц, хотя на 2038 далеко не новый, на архитектуре 64 бита "увидит" дату 1970 . Хотя я могу ошибаться, кто знает лучше пускай поправит, буду знать как правильно.
@@valdemardodus6562 да нет. Проблема в значении, а не в том, где оно хранится, в БД или памяти. Очевидно, что структура int32 имеет свое максимальное значение и длину, и если явно указано, что мы храним значение в переменной int32, то максимум вот такой и это никак не зависит от архитектуры железа. В случае 64-битного или даже 128-битного железа максимальное значение int32 всегда будет одинаковым для всех и никак не изменится. Так что если для хранения какого-то числа (время или что-то другое) выбрано int32, то ошибка на всех системах и архитектурах будет проявлять всегда. Так же это справедливо и в обратную сторону про int64. С этим типом данных точно так же могут работать системы и старое железо, как 32-битные, так и 16-битные процессоры. Просто это число будет занимать больше памяти и обработка будет чуть медленнее, что в целом не будет заметно для пользователя. Так что проблема в целом высосана из пальца. Да, старый софт, для которого не будет патча, исправляющего проблему, может работать некорректно. Но к 2038-му году об этой проблеме даже не вспомнят, т.к. программы из нулевых будут неактуальны, новый софт будет лишен этого недостатка, а те "старые" программы которые будут нужны, будут исправлены.
Я вот так задумался, а как себя будут вести 32 битные вирусы?
Того - государство в аф...
Того, хряк и скончаются в процессе заражения компа
Так же как и 64 битные.
6:59 скинь ссылку на шестой вегас пж
Very enjoyable video, I liked seeing you test out Unix time in various OSes. Sorry if this comment can't be understood due to language barrier.
The Y2K38 bug is a real problem that exists. Like with Y2K, it could've been a disaster if people didn't put in the effort to prevent it from happening, but fortunately people did. It's just that now that it's not a problem anymore, people take its absence for granted (though some of the scare around it was in fact quite exaggerated).
It's worth noting that Unix time is the way it is because it's signed, which is what lets it show negative numbers; if it wasn't, the 32-bit version could display up to 4,294,967,295 seconds since Jan 1 1970 00:00, which would be Feb 07 2106 06:28:15. But the 60s weren't that long ago, so obviously people wanted to be able to display dates before 1970.
Все новое это хорошо забытое старое. Помню видос про даты на которых комп сойдёт сума
С юбилеем бро! :)
Спасибо))
В 2000 году я работал в маленькой фирме, где были еще ПК на 80386 и руководство их менять не собиралось. Сделал крошечную программульку, которая запускалась перед запуском NC и предлагала подкорректировать дату вручную. Введенная дата запоминалась в BIOS и всё было в порядке. Согласен, что неудобно, но лучше так, чем никак
Никак не могу понять, за каким лядом во времени юникс учитывается знак. Без учёта знака было бы не 2 миллиарда секунд а четыре, что отодвинуло бы время наступления проблемы в два раза дальше (136 с копейками лет).
Интересно, а что будет с древними смарфонами из 2007-2013 годов
19 января - мой день рождения! Значит в 2038 году это будет моим подарком))
Существует много оборудования помимо компьютеров, серверов. Это промышленные контроллеры с 32-битной (чтоб подешевле) архитектурой и всего лишь эмуляцией операций с dword на "высоком уровне". Под капотом всё те же 32 бита. Много таких устройств уже сняты с производства и поддержки производителей, но продолжают работать, и наверняка очень много такой техники сумеет дожить до 2038 года. Это потребует серьёзной модернизации оборудования, либо способно привести к отказам
0:16 курсор приятный дай пж
похоже на Bibata Original Classic
Material чёто там)
2:50 лимит указан для знакового целого 32 бит, для беззнакового целого 32 бит лимит будет 4 ляма с гаком
А потом все в последний момент: "ойойойойой как же так, КтО Же ПодУмАтЬ Бы Мог"
Так это вы ещё simbian s60 не подключали к интернету на современных сим-картах, где надо обновлять сертификаты безопасности, но ты не можешь подключиться потому что сертификаты устарели😂.
Я думаю в полной мере эта проблема будет касаться не обычных домашних пк, а чего-то более корпоративного. Например, те же банковские системы могут работать даже под DOS, и это ведь не шутка и преувеличение. Думаете через 14 лет что-то сильно изменится? Да вообще нет. Там может быть критический софт написанный вообще на каких-то фортранах, кобол и других древних языках специалистов под которых просто уже не существует. И вот такое вот легаси которое почти не возможно нормально обновить - пострадает или нужно будет вложить ахулиард денег на фикс бага.
ЗЫ: Я кстати никогда не понимал, почему тип t_time является именно signed int 32 переменной, а не unsigned int 32. Использование uint 32 позволит расширить в два раза диапазон не в ущерб памяти отказавшись от чисел со знаком -. Ведь зачем unix time иметь отрицательные числа которые не используются? А так критическая дата смещается до 2106 года)
@@leviofanh поломка этих легаси кодов единственный способ заставить компании обновлять такое старье, так что не вижу ничего плохого в том что они забагуются.
@@ashstarwind9595 Этот современный подход, выкинуть, заменить, легаси говно... А зачем это делать? Ты можешь сказать? Что бы потратить ахулиард денег в трубу? Что бы наплодить багов?
Есть некая система, она крайне важная, критичная и от нее зависит очень многое. Эта система развивалась на протяжении десятков лет, отточена и работает. Теперь встаёт закономерный вопрос: Зачем трогать то, что работает?
Ты просто со своей потребительской колокольни думаешь, что это "так просто" и всем вокруг просто "лень". Так вот нет, это вообще не так просто. Это огромные, я бы даже сказал ГИГАНТСКИЕ вложения. И все это ради чего? Что бы система не числилась как "легаси"?
@@ashstarwind9595 Этот современный подход, выкинуть, заменить, легаси говно... А зачем это делать? Ты можешь сказать? Что бы потратить ахулиард денег в трубу? Что бы наплодить багов?
Есть некая система, она крайне важная, критичная и от нее зависит очень многое. Эта система развивалась на протяжении десятков лет, отточена и работает. Теперь встаёт закономерный вопрос: Зачем трогать то, что работает?
Ты просто со своей потребительской колокольни думаешь, что это "так просто" и всем вокруг просто "лень". Так вот нет, это вообще не так просто. Это огромные, я бы даже сказал ГИГАНТСКИЕ вложения. И все это ради чего? Что бы система не числилась как "легаси"?
Возможно к 2099 году MS DOS немного утратит свою популярность. Хорошо что ещё есть время перейти на что-то более современное 😅
;)))
Интересно было посмотреть, спасибо за видос
10:08 самый стабильный дистрибутив
Я уверен, что даже в 2038м году где-то в государственном и бизнес-секторе найдутся компы, которые не обновлялись с доисторических времен 😂😂😂
УРАААА!!!!! СКОРО БУДЕТ АПОКАЛИПСИС!!!!!! 🎉🎉🎉🎉🎉😂😂🤣🤣🤣😜😝😝🤙🤙🤙🤙
С днюхой канала даня! Видео класс!
Спасибо!
@DanielMАООАОАОПОАО МНЕ ОТВЕТИЛ САМ ДАНЯ МЫСЛИВЕЦ СПАСИБО СПАСИБО Я тебя смотрю еще с рождения канала легенда!!!
На тот момент уже все возьмутся за верхнюю головку: "чег... ЮНИКС-ТАЙМ ЗАКАНЧИВАЕТСЯ??? БЕГОМ ДЕЛАТЬ ЮНИКС НАЧИНАЮЩЕЙСЯ С ДРУГОГО ВРЕМЕНИ!!"
@DanielM, про Windows ME и про невышедшие Windows (Windows Cairo, Windows 96 Nashville) видео будут?
Привет! Такое планируется
знаете что еще не доживет до 2038 года?
брайан керниган, автор юникс времени, дедуле уже 82 года
кто знает, может и доживёт. медицина на месте не стоит
Для тех, кто не понял, почему 2147483647. 2147483647 - это 2 в 31 степени минус 1 (так как остальные 2147483648 значений используются для записи нуля и отрицательных значений от -2147483648 до -1)
только вот отрицательные значения записываются включая -2^31
Эм, ну типа просто тип чисел меняешь и до какого-нибудь 2096 опять ждёшь и поменяешь на большее
Также и в 1999 году сделали
Ну и почти все приложения не рекомендуют работать в 32 бита
Я из 2038 года!
Мой вам совет, не пользуйтесь в 2038 году Windows XP и будет вам счастье 😂
Забыл сказать: ещё к 2038 году устареет
Nokia 3310
ыыы)
Классное видео! Сделай видео, какие темы на Windows могут пойти?
Спасибо, интересно 😊
Главное еще дожить до 2038 года и чтобы еще компютер дожил до 2038 года.
Так в 2038 году уже и таких ПК не будет, просто перейдём на что-то поновее... для детей 30х годов ПК уже будет как для нас старый бабушкин телефон
Огромная работа проделана. Спасибо большое за видео. Прям полноценное расследование. Спасибо большое. Очень крутая работа.
Я как-то раз слышал о таком и якобы в 2038 году компьютеры будут иметь сбой, но я честно говоря не знаю, на самом деле будет такое или нет, потому что мой знакомый отдал мне свой компьютер и там был Виндовс 11 и в календаре показывала 2251 год :) (точно уже не помню, но вроде этот год и показала)
11 винда 64 битная, там такого не будет, автор говорил что это будет только на 32 битных пк
@@MonserzxОн об этом не говорил
@@Monserzx у Даниила 32х /86х вообще работала и сам говорит что 32х/ 86х справляются
А как дела в Arm версии Винды? А то на неё будем переходить со временем. Понимаю, всё должно быть, как на 64-хбитной винде, но всё же
Привет! К сожалению, у меня пока нет устройства на полноценной ARM Windows, поэтому проверить пока не могу(
Насколько я помню, проблема Y2K BAG была довольно опасной. Хотя не, ВЕСЬМА ОПАСНОЙ. Т.к. система автоматом ставила дату 1900 и т.д. некоторые банки перестали считывать карты, думая что они просроченные, некоторым заключённым повысился срок, те же проблемы с самолётами, крч проблема была везде, где многое контролировалось через пк, в том числе и ядерка.
Самое забавное в том, что этот "армагедон" предсказали ещё за 20 лет и более, но начали с ней разбираться за пару месяцев :_)
2:58 При отрицательном значении в конце будет 8
Спасибо за видео)
Проверил на живом компьютере на 98 винде: включается, перезагружается, Мозила открывается, в интернет выходит, программки запускаются, игры и бенчмарки работают, текстовые документы сохраняются и открываются.
Паинт не может сохранить картинку, выдает ошибку чтения из памяти.
Некоторые игры не могут сохранить игровой прогресс и вылетают.
Дата создания файлов работает и показывает "настоящее" время создания, то есть 19 января 2038 год 03:57:23 например.
Собственно, почему вызодит 238 миллиарда лет, обьясню:
2,147,000,000 это лимит int32 (тип данных для 32 битных процессоров)
Но с выходом 64 битных это значение увеличилось до int64 (почитайте про лимит long типа данных), это примерно 9 квинтиллионов , что в человеческом времени 238 млрд лет, но
Если использовать unsigned long (в 2 ра3а больше, чем long), то это значение увеличится в 2 раза (476млрд лет), откуда я жто знаю? я программист
@BladeBrawlXV я думаю кому интересно это вполне знают. Ну по крайней, вопросов подобных тут не встретил. Двоичной системе уже давно в школах учат. Ни кто правда там не понимает зачем она нужна и я не понимаю зачем грузят, но учат едва ли не первыми темами.
Total работает в 3,1?! Круто
Данил подскажи пожалуйста где найти xp 64x pro?
я один, когда вижу 2038, то мне в голову приходит detroit: become human ???
С днём рождения канала тогда)