Нет, я хочу сказать, что мне нужно чётко привязываться к началу минуты. Ибо я не знаю сколько по времени займёт выполнение программой своих основных функций. Если ставить sleep ровно на минуту, то соответственно временной интервал будет минута + время на работу функций. Соответственно временной интервал будет со временем "уплывать" от начала минуты. Кроме того системное время может быть скорректировано и определённый промежуток между нулевыми секундами может стать меньше/больше минуты. А если ставить sleep меньше то будут пустые циклы, которые будут грузить процессор. Чем меньше sleep - тем точнее привязка, но больше нагрузка. А хотелось бы этого избежать.
Это понятно, но я сомневаюсь, что железо может так влиять на запись файлов. Разве что карточка битая. Скорее дело в особенностях ОС, но я недостаточно опытен в линуксе для того, чтобы осознать корень проблем.
До этого всё это дело крутилось на х86 ноутбуке под Windows. Программы были те же, только откомпилированные Visual Studio и Intel Fortran (сейчас же gcc и gfortran соответственно). Работало долго. Подобных проблем с выводом в файлы замечено не было.
Система Raspbian, ядро 3.10.25+
Файловая система ext4 с вкраплением vfat для раздела с конфигами самого raspberry и cifs для подключённой в виде папки внешней базы данных.
Системная кодировка koi-8. Программы соответственно используют системную кодировку.
Я понимаю, что в самописных программах могут быть ошибки, но абсолютно одинаковая ошибка в двух разных программах написанных на разных языках и берущих и выводящих данные в разные файлы? Т.е. программы между собой связаны только тем, что работают на одной системе. Даже скрипты, читающие выходные данные программ разные (что не обязательно, но сложилось исторически).
А протоколы... Оборудование передаёт данные через стандартный драйвер FTDI и данные на входе в программу контролируются. Если бы устройство посылало некорректные данные, то это я это бы заметил. Да и в любом случае это повлияло бы на содержание но не на формат выходной строки. Внешняя же база подмонтирована просто как папка и программа читающая её состоит буквально из десятка строк. Чтение состоит в распарсивании бинарных файлов. Данный процесс был уже отработан в десятке других программ и подобных накладок никогда не было.
Делать чистую установку с ключём для апгрейда — нельзя. Точнее, система-то встанет и даже активируется, но вот через какое-то время активация слетит с заявлением типа «данный ключ только для обновления, купите полный ключ».
Либо заглянуть в настройки самой точки, либо воспользоваться специальной программой на том устройстве, которое эту точку видит. Я обычно пользуюсь Wifi Analyzer на телефоне.
Единственное, смущает фраза «на УБУНТе тот же ноут видит». Ибо у меня была такая-же история но с разными ноутами. В одном из них wifi адаптер не видел сеть на 12-ом канале. Но от системы это не зависело.
Почти два года пользуюсь 200-ым. Прошивку обновил до iODD сразу. Постоянно таскаю с собой в сумке. Проблем с осыпающимся диском не было.
Сменил диск пару месяцев назад только по причине того, что металлический Zalman (вынутый из чехла, ибо уже сильно нагрелся) соскользнул с не менее металлического ASUS'а прямо во время копирования большого количества данных. Длины провода хватило аккурат до пола. Мгновенное fatality.
Ссылку про linux я уже видел. Но трогать уже работающую систему как-то нехорошо. Да ещё и программы пересобирать под linux придётся.
А механический разрыв цепи, как я уже сказал — крайняя мера.
Рабочая директория указана верно. По крайней мере, она совпадает с расположением exe-шника.
Меня всё больше гложат подозрения, что это таки какой-то глобальный глюк системы, а не самого Хрома. Единственное что смущает, так это почему только одна программа глючит.
Переустановка совершенно ничего не изменила. Версии пробовал stable и dev.
Флэш написан «Adobe Flash Player (2 files) — Версия: 11.3.31.331», поэтому подозреваю что он не встроенный.
Ах да, и при правом клике его можно только закрепить/открепить или открыть, тогда как остальные приложения в Метро можно ещё и запустить от имени администратора.
