Здравствуйте, B0FEE664, Вы писали:
BFE>и всё. приплыли. BFE>А почему? А потому, что опытные программисты знают как там оно на самом деле устроено и кастят time_t к int.
Здравствуйте, Shmj, Вы писали:
S>А Ubuntu так же себя ведет?
Не знаю. Попробуй.
S>Другие версии Linux?
Debian 10 на все даты уходящие за 2038 год говорил, что формат даты не правильный. А в версии 12 ядро подправили и теперь этот порог можно преодолеть, но к такому остальные части системы не готовы...
Здравствуйте, B0FEE664, Вы писали:
BFE> BFE>sudo date --set="2040-12-13 10:09:08" BFE>sudo hwclock --systohc --noadjfile --utc BFE>
BFE>и всё. приплыли.
Куда приплыли-то? Подробности расскажи.
BFE>А почему? А потому, что опытные программисты знают как там оно на самом деле устроено и кастят time_t к int.
Здравствуйте, Философ, Вы писали:
BFE>>А почему? А потому, что опытные программисты знают как там оно на самом деле устроено и кастят time_t к int. Ф>А time_t в линухе не 8 байт? Почему кастят? Ф>Блин, прибил бы автора слова "int" — не понятно же, какого размера...
Ф>UPD: проверил — действительно 8 байт, как и в винде. А как они это кастят?
Никогда не видели кода:
int n = time(NULL);
?
Ф>Почему кастится?
by designe
Причём с gcc опции -Wall -Wpedantic -Wextra не спасут. Нужно дополнительно -Wconversion и только тогда будет предупреждение.
Но это ещё цветочки.
Я не знаю кто и что в недрах gcc или Linux что-то такое предусмотрел, но приложение в конторе (что я консультирую) падает не доходя до main. Причём с какой-то совершенно невнятной диагностикой про размер файла.
Здравствуйте, Pzz, Вы писали:
BFE>> BFE>>sudo date --set="2040-12-13 10:09:08" BFE>>sudo hwclock --systohc --noadjfile --utc BFE>>
BFE>>и всё. приплыли. Pzz>Куда приплыли-то? Подробности расскажи.
Клиенты решили протестировать девайс.
И первым же делом поменяли дату на вышеуказанную (из интерфейса).
И всё, девайс кажет чёрный экран.
Клиент, что характерно, на другом континенте. На этом никому в голову подобное не пришло.
Шев проекта не рискнул повторить трюк, а мне было интересно.
Результат тот же.
По ssh не зайти, девайса в сети нет (хотя ip на нём фиксированный)
Через последовательный порт видно , что загрузка с ошибками, но проходит.
putty подвисает после каждого нажатия enter, так что каждая команда требует переподключения.
Обратно дату на текущую не изменить: команда завершается с ошибкой.
У многих файлов и каталогов дата поменялась на 2040... и именно это приводит к проблемам. Если поменять даты каталогов /etc и /dev на текущие, то кое-что начинает работать.
Я не стал дальше разбираться, а просто переставил систему с флешки.
BFE>>А почему? А потому, что опытные программисты знают как там оно на самом деле устроено и кастят time_t к int. Pzz>А там в хардварии сколько битов-то?
ARM 64 бита.
Здравствуйте, B0FEE664, Вы писали:
BFE>>>А почему? А потому, что опытные программисты знают как там оно на самом деле устроено и кастят time_t к int. Pzz>>А там в хардварии сколько битов-то? BFE>ARM 64 бита.
Это у процессора. Интересно, сколько битов в том месте железа, куда время пишется.
Кстати, раз это ARM, то вся эта дичь в BSP, или в "общем" коде?
Здравствуйте, Pzz, Вы писали:
Ф>>Блин, прибил бы автора слова "int" — не понятно же, какого размера...
Pzz>Удобного для процессора. На PDP/11 вообще 16 бит было. И на 16-битном 8086 тоже.
Pzz>Автор-то уже помер, поди. Наверное, это был Денис Ричи.
Я слышал, в старые времена железо тормозило на неродной разрядности. Например, задефайнив INT на 16 бит и используя его повсюду, можно было совершенно бесплатно получить просадку производительности на 86 времён, примерно, 9x.
Никогда не любил тестировать подобные штуки, в те времена особенно, но если это так, то это костыль, ныне утративший единственный смысл, который в нём был. Но люди упорно пытаются найти новый (смысл).
I'm a sewer mutant, and my favorite authors are Edgar Allan Poo, H.G. Smells and George R.R. Martin.
Здравствуйте, Alekzander, Вы писали:
A>Никогда не любил тестировать подобные штуки, в те времена особенно, но если это так, то это костыль, ныне утративший единственный смысл, который в нём был. Но люди упорно пытаются найти новый (смысл).
В смысле?
Во времена, когда Си был придуман, были 16-битные компьютеры, они аппаратно складывали за раз два 16-битных числа, а вот чтобы сложить два 32-битных числа, требовалось несколько команд, и были 32-битные компьютеры, их команды за раз оперировали 32-битными числами.
Если использовать int по назначению (например, в качестве счетчика цикла), то обычно вообще все равно, 16 он бит или 32. Поэтому тип, достаточно длинный для подобных применений, но при этом без гарантий относительно конкретной длины (1) имеет смысл (2) очень востребован. Даже и до сих пор.
Здравствуйте, Pzz, Вы писали:
Pzz>Если использовать int по назначению (например, в качестве счетчика цикла), то обычно вообще все равно, 16 он бит или 32...
А что, во время 16-битных регистров мегабайтных файлов ещё не было? Или никто последовательно не вычитывал сотни тысяч элементов структуры? Вроде когда C придумали, уже юникс был — уже должны были быть подобные задачи, тем более Масачусетском универе.
Я не сишник, если что.
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, Pzz, Вы писали:
Pzz>Во времена, когда Си был придуман, были 16-битные компьютеры, они аппаратно складывали за раз два 16-битных числа, а вот чтобы сложить два 32-битных числа, требовалось несколько команд, и были 32-битные компьютеры, их команды за раз оперировали 32-битными числами.
Что происходило с производительностью, если на тех 16-битных компьютерах ты складывал два 8-битных числа?
Допустим, ты портировал код с 8-битной платформы и поэтому точно знал, что диапазона тебе хватит. Получал ли ты выигрыш по скорости, заменив безо всякого прикладного смысла все переменные на 16-битные?
Я, к сожалению, так давно не живу. Почитываю иногда старые статьи, и не уверен, что понимаю их правильно.
I'm a sewer mutant, and my favorite authors are Edgar Allan Poo, H.G. Smells and George R.R. Martin.
Здравствуйте, Философ, Вы писали:
Pzz>>Если использовать int по назначению (например, в качестве счетчика цикла), то обычно вообще все равно, 16 он бит или 32...
Ф>А что, во время 16-битных регистров мегабайтных файлов ещё не было? Или никто последовательно не вычитывал сотни тысяч элементов структуры? Вроде когда C придумали, уже юникс был — уже должны были быть подобные задачи, тем более Масачусетском универе. Ф>Я не сишник, если что.
Здравствуйте, Alekzander, Вы писали:
A>Что происходило с производительностью, если на тех 16-битных компьютерах ты складывал два 8-битных числа?
A>Допустим, ты портировал код с 8-битной платформы и поэтому точно знал, что диапазона тебе хватит. Получал ли ты выигрыш по скорости, заменив безо всякого прикладного смысла все переменные на 16-битные?
Не знаю. Думаю, для разных машин разный ответ.
Но в целом, во времена засилия 16-битных машин памяти было очень мало. Поэтому тратить при работе со строками по 16 бит на символ было бы расточительством; возможность напрямую работать с 8-битными значениями была важна.
Здравствуйте, B0FEE664, Вы писали:
BFE>Никогда не видели кода: BFE>
BFE> int n = time(NULL);
BFE>
BFE>?
Я видел код, в котором в int запихивали указатель. А потом рассчитывали его оттуда достать, в целости и сохранности.
Собственно, даже во времена MS-DOS это было дикостью, потому что int был 16-битным, а far pointer — нет. Но на VAX-е, где родился BSD UNIX, все было 32-битным, очень удобно, пока кому-нибудь не придет в голову такой код куда-нибудь спортировать.
BFE>Я не знаю кто и что в недрах gcc или Linux что-то такое предусмотрел, но приложение в конторе (что я консультирую) падает не доходя до main. Причём с какой-то совершенно невнятной диагностикой про размер файла.
Можно написать функцию, которая исполнится (и упадет) до main-а. В C++ для этого предусмотрены конструкторы статических объектов, для Си в gcc есть специальные расширения.
Ты б дал ему отложить core и посмотрел бы отладчиком на стек...
Здравствуйте, Pzz, Вы писали:
Pzz>Но в целом, во времена засилия 16-битных машин памяти было очень мало. Поэтому тратить при работе со строками по 16 бит на символ было бы расточительством
Речь не про символы, а про счётчики циклов и тому подобное. До сих пор тратить по 16 бит на символ считается расточительством (UTF-8).
Плюс, что тогда было с многозадачностью? Программа начинала требовать больше памяти, но если эта память была увеличена пропорционально разрядности, и никто её больше не тратил, не один ли хрен.
I'm a sewer mutant, and my favorite authors are Edgar Allan Poo, H.G. Smells and George R.R. Martin.
Здравствуйте, Alekzander, Вы писали:
Pzz>>Но в целом, во времена засилия 16-битных машин памяти было очень мало. Поэтому тратить при работе со строками по 16 бит на символ было бы расточительством
A>Речь не про символы, а про счётчики циклов и тому подобное. До сих пор тратить по 16 бит на символ считается расточительством (UTF-8).
Ну если мы можем вычесть из ASCII-символа цифры '0', чтобы получить ее численное значение, значит, 8-битная арифметика в машине предусмотрена.
Другой вопрос, что счетчик цикла с хорошей вероятностью ляжет на регистр, а дальше надо уже архитектуру конкретных процессоров смотреть, чтобы понять, будет ли ему удобнее в 16-битном регистре, чем в его половинке, или это все равно.
A>Плюс, что тогда было с многозадачностью? Программа начинала требовать больше памяти, но если эта память была увеличена пропорционально разрядности, и никто её больше не тратил, не один ли хрен.
Если памяти, скажем, 128 килобайт на всех, то не один хрен.
Килобайт, обрати внимание. В килобайте 1024 байта.
Здравствуйте, Pzz, Вы писали:
Pzz>Если памяти, скажем, 128 килобайт на всех, то не один хрен.
Pzz>Килобайт, обрати внимание. В килобайте 1024 байта.
128 килобайт было ещё у восьмибитного Спектрума. А Спектрум я уже вполне застал. А у промышленных систем, ну вот я загуглил:
PDP–11/70 – 1975.[15] The 11/45 architecture expanded to allow 4 MB of physical memory segregated onto a private memory bus, 2 KB of cache memory, and much faster I/O devices connected via the Massbus.
Другая известная 16-битная система, 80286 — "640К хватит всем". 640, а не 128.
Я думаю, при переносе восьмибитных программ на практике ты всегда влезал в память, если тупо заменял главный int на 16-битный. Если при этом ты избавлялся от тормозов или ещё какого-нибудь говна, связанного с неродной разрядностью, то в этом и был смысл плавающего размера.
I'm a sewer mutant, and my favorite authors are Edgar Allan Poo, H.G. Smells and George R.R. Martin.
Здравствуйте, Alekzander, Вы писали:
A>128 килобайт было ещё у восьмибитного Спектрума. А Спектрум я уже вполне застал. А у промышленных систем, ну вот я загуглил:
A>
A>PDP–11/70 – 1975.[15] The 11/45 architecture expanded to allow 4 MB of physical memory segregated onto a private memory bus, 2 KB of cache memory, and much faster I/O devices connected via the Massbus.
"Allow" != "installed". 128-256 Kb — вполне нормальная сборка для PDP-ки (вернее, я застал советские PDP, СМ/4). В персоналки (Электронока-60) больше 64К не ставили.
A>Другая известная 16-битная система, 80286 — "640К хватит всем". 640, а не 128.
Это уже была прям продвинутая система.
A>Я думаю, при переносе восьмибитных программ на практике ты всегда влезал в память, если тупо заменял главный int на 16-битный. Если при этом ты избавлялся от тормозов или ещё какого-нибудь говна, связанного с неродной разрядностью, то в этом и был смысл плавающего размера.
Что-то я не припомню, чтобы я куда-нибудь переносил 8-битные программы.
16-битные, с MS-DOS на UNIX переносил, как и в обратном направлении.
Здравствуйте, Pzz, Вы писали:
Pzz>Если использовать int по назначению (например, в качестве счетчика цикла), то обычно вообще все равно, 16 он бит или 32.
даа, теперь понятно откуда тонны уязвимостей integer overflow с последующим корраптом памяти...
Здравствуйте, Alekzander, Вы писали:
A>Я слышал, в старые времена железо тормозило на неродной разрядности. Например, задефайнив INT на 16 бит и используя его повсюду, можно было совершенно бесплатно получить просадку производительности на 86 времён, примерно, 9x.
Это во все времена так. Железо умеет работать только с конкретной разрядностью. Всё что другое корректируется компилятором, т.е. софтварно. Вот вам и просадка.
Здравствуйте, Pauel, Вы писали:
A>>Я слышал, в старые времена железо тормозило на неродной разрядности. Например, задефайнив INT на 16 бит и используя его повсюду, можно было совершенно бесплатно получить просадку производительности на 86 времён, примерно, 9x.
P> Это во все времена так. Железо умеет работать только с конкретной разрядностью. Всё что другое корректируется компилятором, т.е. софтварно. Вот вам и просадка.
И что, ты хочешь сказать, что современные 64-битные процы не пилятся специально так, чтобы не было просадок на тоннах 32-битного софта?
I'm a sewer mutant, and my favorite authors are Edgar Allan Poo, H.G. Smells and George R.R. Martin.
Здравствуйте, mike_rs, Вы писали:
Pzz>>Если использовать int по назначению (например, в качестве счетчика цикла), то обычно вообще все равно, 16 он бит или 32.
_>даа, теперь понятно откуда тонны уязвимостей integer overflow с последующим корраптом памяти...
Здравствуйте, Pzz, Вы писали:
_>>даа, теперь понятно откуда тонны уязвимостей integer overflow с последующим корраптом памяти... Pzz>Ну, Си не для всех...
BFE>У многих файлов и каталогов дата поменялась на 2040... и именно это приводит к проблемам. Если поменять даты каталогов /etc и /dev на текущие, то кое-что начинает работать.
Хм, интересно. похоже это бага драйвера fs. Какая там fs?
И зачем вообще системе смотреть на даты файлов? это атрибут user level.
Здравствуйте, B0FEE664, Вы писали:
BFE>Надёжная Debian 12
Я начал использовать Debian с 6 версии, с переходом на 7 версию на полный цикл. Больше всего мне нравилась 9 версия. А 12 версия на мой взгляд неудачная.
И в Debian есть выведенное мною правило, что начинать использовать выпуск нужно тогда, когда выпустили следующую версию.
Например, выпускают установочный образ 13 версии, тогда идём и скачиваем последний установочный образ 12 версии.
В последнем установочном образе уже исправили многие баги из коробки. Это лучше, чем ставить баганутый образ первых выпусков и обновления, так как реконфигурация сама по себе не делается.
В целом же Debian это рабочий инструмент. Цель его дать пользователям операционку для последующей настройки.
Для таких случаев и существует профессия администратора. Если сам не хочешь настраивать можешь заплатить. А если настраиваешь сам, то сам и становишься админом.
Здравствуйте, Alekzander, Вы писали:
A>И что, ты хочешь сказать, что современные 64-битные процы не пилятся специально так, чтобы не было просадок на тоннах 32-битного софта?
Я хочу сказать, что в любой процессор закладывается ограниченное количество кейсов для оптимизации.
Нынешние процессоры затачиваются в основном под 32 и 64 бита.
Иногда 32х битная версия быстрее, иногда 64.
Для интересу можно 16 битный код потестировать, не знаю, правда, как этого добиться.
Еще есть и 8 битные команды, вроде бы их не выбрасывали.
А вот если вы захотите 128бит — у вас снова будут просадки, как и в стародавние времена. Только поменьше, т.к. раньше в процессорах отсутствовали многие механизмы, типа буфер ветвления, кеширование итд итд
Здравствуйте, Pauel, Вы писали:
P>Нынешние процессоры затачиваются в основном под 32 и 64 бита.
"Что ж ты, фраер, сдал назад?" Сначала ты пишешь:
>Это во все времена так. Железо умеет работать только с конкретной разрядностью. Всё что другое корректируется компилятором
А теперь, значит, "затачиваются" сразу "под 32 и 64 бита", да?
Об этом и речь шла. Если верна гипотеза, что когда-то плавающий инт ввели с Си в порядке оптимизации, чтобы при переносе на другие платформы автоматически (без изменения кода) получать родную разрядность и максимальную производительность, то теперь смысла в плавающем инте больше нет. А нет смысла потому, что имея такой корпус 32-битных программ создатели 64-битных процессоров вложились в оптимизацию под "неродную", 32-битную разрядность. Хотя я даже не уверен, что там к 32-битности вообще применимо понятие "неродная".
I'm a sewer mutant, and my favorite authors are Edgar Allan Poo, H.G. Smells and George R.R. Martin.
Здравствуйте, Alekzander, Вы писали:
A>"Что ж ты, фраер, сдал назад?" Сначала ты пишешь: A>А теперь, значит, "затачиваются" сразу "под 32 и 64 бита", да?
Вы так торопитесь, что ваши мысли вас не догоняют.
Цитирую себя: "А вот если вы захотите 128бит — у вас снова будут просадки, как и в стародавние времена. "
Разница между 32 и 64 небольшая, но есть. Не нравится — рассмотрите кейсы с 16 битными вычислениями, 8 битными, и даже 128 битными.
Здравствуйте, Pauel, Вы писали:
P>Цитирую себя: "А вот если вы захотите 128бит — у вас снова будут просадки, как и в стародавние времена. "
Вот тогда, возможно, снова станет актуальным плавающий инт. А на данный момент он актуальность утратил, в связи с тем, что хорошая нативная поддержка 32-битного софта всеми процессорами это фактор конкуренции.
Если, конечно, подчёркиваю, верна гипотеза о перформансных или каких-то иных плюшках автоматического приведения разрядности к родной. А другой разумной гипотезы, собственно, я не вижу.
I'm a sewer mutant, and my favorite authors are Edgar Allan Poo, H.G. Smells and George R.R. Martin.
Здравствуйте, Pzz, Вы писали:
Pzz>Если использовать int по назначению (например, в качестве счетчика цикла), то обычно вообще все равно, 16 он бит или 32.
Очень даже есть разница.
typedef int INDEX;
int xset(int *arr, INDEX pos, int val) {
arr[pos] = val;
}
Компилируем (gcc -O -S -masm=intel):
xset:
movsx rsi, esi
mov DWORD PTR [rdi+rsi*4], edx
ret
Ой, а откуда это movsx взялось? До адреса-то расширить надо...
То же для ARM/64:
xset:
str w2, [x0, w1, sxtw 2]
ret
Тут вложенная sxtw делает то же самое.
Если взять unsigned, то для такого простого кода, да, на x86 срабатывает автозатирка старших 32 бит при 32-битных операциях (но не при 16-битных!) На ARM аналогично появляются uxtw.
А теперь ещё интереснее — делаем индекс unsigned short и делаем цикл по нему:
typedef unsigned short INDEX;
int xfill(int *arr, INDEX size) {
INDEX i;
for (i = 0; i < size; ++i) {
arr[i] = i;
}
arr[size] = 0;
}
А зачем нам аж два and с 65535? А это нас арестовывать идут есть правило C/C++, что арифметика unsigned она modulo. В результате лишние операции в цикле.
На x86 GCC на это решил использовать 16-битные регистры, типа ax. Clang не захотел, поэтому там есть явный movzx после инкремента.
А теперь ещё и поменяем аргумент размера на size_t. GCC, x86:
Два лишних movzx. Мы убрали гарантию, что предел влезает в те же 16 бит, и включается полная арифметика по модулю 2^16 в регистре размером на 2^64. Это полное орейро.
Эффект я наблюдал в коде проектов, в которых почему-то очень любили, что если количество, например, модулей железа для чего-то приходит в виде uint8_t, то и итерировать по ним надо через uint8_t. В результате код был переполнен всякими ubfx и uxtw.
Для архитектур типа ARM я уже вообще не вижу причин оставлять int 32-битным, кроме совместимости с неизвестно чем. Для x86 минимальный аргумент — что 32-битные команды в массе, в отличие от 64-битных, не требуют REX префикса, поэтому чуть экономнее.
Зато в рекомендации по кодированию давно надо внести — все переменные циклов, которые используются для индексации, надо делать size_t или ssize_t. Иначе повылазят эти конверсии где не нужны.
Здравствуйте, Pzz, Вы писали:
Ф>>А что, во время 16-битных регистров мегабайтных файлов ещё не было? Или никто последовательно не вычитывал сотни тысяч элементов структуры? Вроде когда C придумали, уже юникс был — уже должны были быть подобные задачи, тем более Масачусетском универе. Ф>>Я не сишник, если что.
Pzz>Для этого был тип long.
Здравствуйте, Alekzander, Вы писали:
A>>>Я слышал, в старые времена железо тормозило на неродной разрядности. Например, задефайнив INT на 16 бит и используя его повсюду, можно было совершенно бесплатно получить просадку производительности на 86 времён, примерно, 9x.
P>> Это во все времена так. Железо умеет работать только с конкретной разрядностью. Всё что другое корректируется компилятором, т.е. софтварно. Вот вам и просадка.
A>И что, ты хочешь сказать, что современные 64-битные процы не пилятся специально так, чтобы не было просадок на тоннах 32-битного софта?
С подходами _современных_ процессоров вообще должно быть пофиг, какая разрядность, пока речь идёт об операциях над полным объектом (обычно регистром).
Во всех основных архитектурах это обеспечено тем, что операция с младшей частью регистра чистит старшую часть. X86 — любая 32-битная операция зануляет старшую половину 64-битного регистра. ARM/64 — то же самое. RISC-V — знаковое расширение на старшую часть, но последствия те же. Или загрузка из памяти в регистр: у тебя есть какие-нибудь lb, lbu, lh, lhu, lw, lwu, ld (список по RISC-V) с расширением, но нет условного lhk (поменять младших 16 бит не трогая старшие). Нужно такое — делаешь особым комбинированием (как bfm в ARM/64), но нужно очень редко.
А вот с 8 и 16 битами в x86 иначе. Они старшую часть, какого она бы ни была размера (16, 32, 64), вообще не трогают. Для 8086 это было ещё логично: работаешь с AL, не меняешь AH. Но сделав такое правило в 386, Intel сама себе подложила огромную свинью. Те задержки, о которых ты говоришь, происходят от того, что возникает "ложная зависимость" между старым и новым значением регистра, которая не даёт параллелить операции.
Особенно это грустно было на PPro. В P2 и особенно в P3 это исправили, вместе с другими проблемами — в PPro, например, Flags рассматривался целиком, и любимые Intel подходы, что некоторые команды меняют только часть condition codes, давали тут такую же неустранимую зависимость. В P2 его разделили на каждый бит CC (CF, SF, OF, ZF, AF, PF) отдельно. Наверняка это ты и вспомнил в вопросе скорости 16-битных программ "во времена 9x".
Но я думаю, что с последними поколениями, когда 16-битный код в нормальном софте используется только для загрузки до момента перехода в защищённый режим с загруженным ядром, эту подпорку начинают убирать обратно. Хочешь легаси — не вопрос, но будет тормозить на тех же false dependency.
Здравствуйте, Pauel, Вы писали:
P>Здравствуйте, Alekzander, Вы писали:
A>>Я слышал, в старые времена железо тормозило на неродной разрядности. Например, задефайнив INT на 16 бит и используя его повсюду, можно было совершенно бесплатно получить просадку производительности на 86 времён, примерно, 9x.
P> Это во все времена так. Железо умеет работать только с конкретной разрядностью. Всё что другое корректируется компилятором, т.е. софтварно. Вот вам и просадка.
X86 таки тут особый случай. Поддержка 8- и 16-битных операций в легаси-стиле. Я в соседнем комментарии расписал подробнее.
(Честно говоря, не только он, конечно. SystemZ отличается тем же. Но там такие пользователи, что их это в большинстве случаев не волнует.)
Здравствуйте, Alekzander, Вы писали:
A>Я думаю, при переносе восьмибитных программ на практике ты всегда влезал в память, если тупо заменял главный int на 16-битный.
Насколько я понял твою хитро завёрнутую мысль, то таки нет.
Самая ходовая среди таких платформ — 6502 — имела с этим серьёзные проблемы. Позволить себе 16-битный int было чудовищно дорого.
Здравствуйте, B0FEE664, Вы писали:
BFE>По ssh не зайти, девайса в сети нет (хотя ip на нём фиксированный)
[...]
BFE>Через последовательный порт видно , что загрузка с ошибками, но проходит. BFE>putty подвисает после каждого нажатия enter, так что каждая команда требует переподключения. BFE>Обратно дату на текущую не изменить: команда завершается с ошибкой. BFE>У многих файлов и каталогов дата поменялась на 2040... и именно это приводит к проблемам. Если поменять даты каталогов /etc и /dev на текущие, то кое-что начинает работать. BFE>Я не стал дальше разбираться, а просто переставил систему с флешки.
BFE>>>А почему? А потому, что опытные программисты знают как там оно на самом деле устроено и кастят time_t к int. Pzz>>А там в хардварии сколько битов-то? BFE>ARM 64 бита.
Крайне странно. На 64 битах уже давно time_t 64-битный насквозь.
Присоединяюсь к вопросу, не виноват ли какой-нибудь код за пределами Linux (аббревиатура BSP, которую тут упомянули, в этом числе).
Здравствуйте, Alekzander, Вы писали: A>И что, ты хочешь сказать, что современные 64-битные процы не пилятся специально так, чтобы не было просадок на тоннах 32-битного софта? тынц
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, netch80, Вы писали:
N>Крайне странно. На 64 битах уже давно time_t 64-битный насквозь. N>Присоединяюсь к вопросу, не виноват ли какой-нибудь код за пределами Linux (аббревиатура BSP, которую тут упомянули, в этом числе).
И за пределами, конечно, тоже виноват. Например, sft-plugin для Total Commander вообще не видит файлы, если их дата (причём любая из трёх) уходит за порог.
Ну и Debian от больших дат глючит.
Вот, ради эксперимента под Debian12 на WSL под Windows 10:
Скажите мне, каким образом 11-ое декабря 12340 года превратилось в 11-ое мая 2446 года? Программисты опять живут сегодняшним днём? Не, я понимаю, Земля замедляется, но за 10300 лет год увеличится не больше чем на 3 минуты и это никак не объясняет, куда делись 9894 года и почему 10:09 превратилось в 00:38.
Винда, кстати, в колонке Date на эти файлы показывает пустое место. Ну, хоть ничего не падает...
Здравствуйте, B0FEE664, Вы писали:
BFE>и всё. приплыли. BFE>А почему? А потому, что опытные программисты знают как там оно на самом деле устроено и кастят time_t к int.
Ну я не шеф, я рискнул — нихрена из описанного ужоса не происходит.
Отбой тревоги.
Фейк.
Это во все времена так. Железо умеет работать только с конкретной разрядностью. Всё что другое корректируется компилятором, т.е. софтварно. Вот вам и просадка.
