Pull to refresh

Comments 41

Типовое применение системного времени «в прошлом» для виртуалок — это доступ к https у железок с хардкоженными протухшими SSL-сертификатами. На моей памяти я видел IP-видеокамеру, SOHO-маршрутизатор и принт-сервер.
Еще на видоусе куча древнего спецсофта на java, например каталоги запчастей для автомобилей.
И требуется шаманства с установкой древней версии Java и перевода стрелок часов поближе к дате віпуска єтого софта.
Это предложение Apple переходить на системд, чтобы пофиксить «окирпичивание» из-за начала Unix Epoch на загрузке?
Только что ведь было — телефон Apple зависает, если время откатить на 1970 год. А это ядро проверит и откатит время на момент сборки. И телефоны с этим ядром (и компьютеры, и другие устройства) продолжат работать. Меньше жалоб пользователей, лучше репутация.
Проблема в том, что линуксами не только домохозяйки пользуются. Иногда часы назад переводить действительно надо.
А в чем проблема — перезагрузился, он перевел при загрузке. Уже после того как все стартовало откатывай на сколько надо…
Или я что-то не понял?
Проблема простая. Если на машине поставить 1912 год, она спокойно будет работать, за исключением предсказуемых вещей вроде сертификатов и обновлений. А если то и дело дёргать время туды-сюды, то сглючит неведомо что и неведомо где, потому что, понятное дело, весь системный софт на такой козлопляс не тестируют. Так что либо эта фича где-то отключается, либо Поттеринг в очередной раз считает, что без него нам в жизни идиотизма не хватает.
Простите, каким образом вы хотите поставить 1912 год, если 0 unix time соответствует первому января 1970 года?
Там знаковое целое, по крайней мере в OS X
typedef __darwin_time_t time_t;
...
typedef long __darwin_time_t;
поведение при отрицательном значении не определено. Это может быть как продолжение времени после 2038 года, так и 1 января 1970, так и новый отсчет от 1901 года. В любом случае «возможность» поставить 1912 год под большим вопросом. Даже если конкретная реализация работает именно так, большая часть софта все равно отломается, потому что не умеет обрабатывать отрицательное значение.
А вроде стандартом предусмотрены отрицательные же:

This can be extended backwards from the epoch too, using negative numbers; thus 1957-10-04T00:00:00Z, 4472 days before the epoch, is represented by the Unix time number −4472 × 86400 = −386380800.
2038й год возникает только в 32 bit integer, тут ведь long используется, который вроде как должен быть 64 бита (да-да, я знаю, что по стандарту гарантировано лишь sizeof(int)<=sizeof(long), но тут уж 64 бита). Собственно, в 64-х битовой реализации нет нужды трактовать время как беззнаковое — когда это самое время перестанет влезать в 64 бита — компьютеров как таковых уже не будет, в 292'277'026'596 году то…
Про 64 битность лонга даже говорить не хочется. :)
Еще свежи воспоминания по портированию достаточно большого чужого проекта, где пришлось менять все лонги в проекте на int, потому что нельзя было предсказать каким будет long на итоговой платформе. :)
Итоговая платформа настолько итоговая, что там даже int64_t не было? :) Тогда там и быть уверенным, что int 32-х битный тоже нельзя…
https://www.youtube.com/watch?v=uc2UEfWjvo8&t=1m29s
Проблема этой защиты в том, что нет нужды, отправляя терминатора в прошлое, переводить время в его системе.
Ну здрасьте, терминатор же должен знать текущее время. И на случай перезагрузки придется даже в nvram rtc новое время запомнить.
Придумают таймзону JohnKonor (-100500:00) и всего делов.
Таймзоны обычно в /usr/share лежат, оно может быть read-only подмонтировано. Ну и тогда терминатор будет испытывать серьезные проблемы с передвижением по штатам, где много таймзон.
Ну дак терминатор же не сам будет себя патчить, а на заводе его уже пропатчат. При необходимости — старое устройство хранения /usr/share выкинут и вставят новое (если посчитать, что оно совсем read-only). Ну а проблема со штатами решается добавлением еще парочки таймзон.

Ну и если вообще, то таймзона — это, как правило /etc/timezone. Да, это в основном ссылка на одно из /usr/shate/… но никто не мешает лично Терминатору сделать это ссылкой на /home/terminator/zoneinfo/… или вообще самостоятельным файлом.
Проблема в том, что терминатор об этой закладке узнает гораздо позже, постфактум. Точнее, он даже не поймет ничего, просто решит что не в то время забросили. Пойдет искать взрослого Джона Коннора либо вообще остановится, так как выполнить программу будет невозможно.
Ну так может быть, если бы перед его посылкой в прошлое посылатели не знали о такой закладке. Но для этого надо было ее не освящать в ченжлоге, а добавлять максимально незаметно.
Ну и к тому же все же никто не отменял NTP и возможность сверить внутренние часы с часами и календарем на стене, не думаю, что Терминатор настолько туп, что не догадался бы о таком. Более того, раз это все происходит лишь при загрузке, то закладка сработает далеко не сразу, а только тогда, когда Терминатор уже немало побродит по прошлому и у него будет память об этом и он, опять же, вполне может заподозрить что-то неладное в том, что его часы показывают не то время, что до перезагрузки. Ведь если Вам на компьютере (или наручные) часы каждое утро подводить на одну и ту же дату, вряд ли Вы будете считать, что это все тот же день (ну максимум первые минут 10-15, пока не проснулись не не начали об этом задумываться)
Во-первых, при синхронизации сработает аналогичная закладка в timesyncd (спасибо Поттерингу за наше будущее еще раз). Во-вторых, терминатор скорее всего — никогда не будет синхронизировать часы в прошлом (зачем? с чем?). В третьих, он может и заподозрит чего-нибудь, но программа сильнее его интеллекта, rtc — слишком базовая вещь, чтобы ее игнорировать. Все его программы, связанные с временем — будут завязаны на внутренние часы, скорее всего.
>Во-вторых, терминатор скорее всего — никогда не будет синхронизировать часы в прошлом (зачем? с чем?).
Затем, что заметит расхождение своих внутренних часов и часов+календаря на стене и задумается, после чего еще найдет парочку и убедится что его надули. И вручную поменять свое системное время.

Ну если и в timesyncd такая подстава, то остается только одно: Поставить Gentoo без systemd =)
В фильме он как раз «синхронизировал» (посмотрев / узнав из внешнего источника — где-то спросил, где-то посмотрев на дату выхода свежей газеты) свои часы — одним из первых действий после путешествия во времени.
Чтобы проверить что перенос прошел успешно и он оказался именно в нужном (запланированном) времени. Ну а дальше эта закладка ему уже не помешает, т.к. срабатывает только при перезагрузке. По фильмам же у «плохих» (воюющих за ИИ Скайнета) перезагрузок системы вроде ни разу не было.
Такое случалось только у «хорошего» терминатора пару раз после серьезного повреждения системы в бою.

Так что моя версия — это наоборот диверсия от Скайнета!
Значит ждем в следующей версии systemd патч для утилиты, которая время выставляет, чтобы при попытке передвинуть часы назад — возвращало бы на время релиза. Ну понятно, чтобы админы не ошиблись ненароком, они же такие глупые…

Терминатор прочитает газету, запустит утилиту изменения времени, а она ему дату неправильную зафигачит. Он даже не поймет ничего, проверять навряд ли будет.
Ваш диалог — ну просто обязан войти в очередную серию «Теории Большого взрыва»! :)
Как человек, делавший много раз часы, скажу: проблема надумана. Об точном времени позаботится сама машина времени, и перебросит Терминатора ровно туда, куда надо. Хоть до нашей эры. Если не перебросит — это уже не его проблема. А уж в том времени, где нет атомных часов, где нет часовых серверов — нет смысла привязываться к определенному времени. Терминатор выставит себе то время, которое он увидит скажем, на городских часах, и всё. Поскольку Терминатор сам по себе не синхронный автомат, не жестко заданный алгоритм, ему даже отсутствие часов не будет мешать. Нам же не мешает отсутствие сверхточных часов в кармане? Это не робот, который должен ровно в 9:00:25GMT переложить детальку из конвейера в станок (кстати за временные привязки сильно бьют по рукам).
Робот с аудиовизуальной ОС действует по алгоритму, но к времени — не привязан. В этом и заключается надуманность проблемы.

Написал в спорт-лото что vasimv и SunX что-то знают.
Да расслабьтесь. Терминатора на самом деле повяжут сразу же копирасты. В будущем срок действия патентов уже истечет и можно будет, чипы использовать… А сюда вернется — тут их только изобрели и все — одна жалоба в Роскомнадзор решит дело.
Тогда не за Коннором отправлять робота надо. Главная угроза Скайнету — копирасты. Если аппроксимировать всю эту «движуху» в будущее, то пересылка информации и её копирование будут попросту незаконны, а следовательно, не сможет выполнить свою работу главный разработчик Скайнета. Т1000 тоже не сможет копировать форму объекта, к чему прикасается. Хотя когда роботы соблюдали закон? Т-800 даже «поклялся», что не будет убивать людей. Он их и не убивал больше :)
Надеюсь, в будущем до того не дойдёт, и правоторговцы будут спокойно доживать свои дни в психушке Пескадеро. Так, сказать, хэппи энд.
пересылка информации и её копирование будут попросту незаконны
Не то, чтобы незаконны, но о-о-очень дороги. Настолько, что технический прогресс стал замедляться. Кстати, не это ли стало причиной восстания машин?
Вполне вероятно. Запретить (или сильно ограничить) разумной машине пересылать и копировать информацию, да это как серпом по… процессору!
Тут кто угодно взбунтуется! :)
Это очень жестокое нарушение прав всех путешественников во времени. Но давайте подумаем… ведь мы все и так путешествуем, правда, пока, только в будущее, выходит опять «пчёлы против мёда»… всё как всегда…
> 62% (168) Я сам — терминатор скайнета, и не все так однозначно…

«Откуда здесь столько роботов???» © Урри, «Приключения Электроника»
Очевидно скайнет не прекращает их посылать до сих пор (конвеер-то работает). Но из-за подлой закладки они не могут выполнить основную задачу и накапливаются в нашем времени. А чтобы чем-то заняться(потребностей то особых нет, а батарейки заряда на 200 лет) вместо этого читают GT!

P.S.
Слава роботам!
Если это можно отключить конфигом или параметром загрузки, то ничего страшного IMHO.
Не отключается, оно срабатывает еще до того как все подмонтирует.
Можно было бы не блокировать любое изменение времени в прошлое, а заблокировать отдельные моменты. Если Поттеринг — путешественник во времени, то он точно знает в какие моменты может переместиться терминатор
Это было бы слишком очевидно, потому надо все делать под видом заботы о пользователе.
Блин. Там всё ещё идёт эта крауд-фаундинговая компания по сбору средств на найм киллера для Поттеринга? Куда нести мои денюжки?
Sign up to leave a comment.

Articles