Сейчас у меня нет с собой фотографий фрезера, но дома постараюсь загрузить.
Использую комбинированную технологию - отверстия на ЧПУ + фоторезист. Третий класс точности - хотелось бы, но текстолит с толстой медью этому не способствует (с дуру заказал 35мкм). Его теоретически можно достичь в домашних условиях, но это слегка за гранью возможностей струйного принтера (печатаю фотошаблоны на плёнке, засвечиваю УФ фонариком на 3-5Вт). Вообще, изначально ЧПУ довольно спорный. Механика не жёсткая, ось хрупкая, шпиндель что ни делай, имеет люфт (раз на раз немного меняется - решилось установкой бесщёточного шпинделя - вибрации стали раза в три меньше).
От родного остались только плата управления, моторы, часть проводки, 2 вала и ведущий вал. Остальное было безжалостно заменено на заказанные детали. При сборке тоже были весёлые косяки, но объективно, доволен.
Китайский 3018 после покупки требует переделки, потому что у него "мягкая жёсткость". Все его валы гуляют при небольшом усилии. Шпиндель вообще в момент сверловки/фрезеровки отклоняется от платы вверх (его выгибает на валах, когда инструмент упирается в плату). На тонких свёрлах незаметно, а вот 1.5мм+ уже очень хорошо видно. И отверстие... уходит в сторону ОТ широкой оси. Ах да. Ещё он сломал ДВЕ(!) оси Z - пошли трещины вокруг радиальных подшипников (больше всего вокруг нижних).
В общем, свой 3018 я переделал полностью на рельсы и алюминиевый профиль (ЧПУ обработка на заводе). Обошлось мне это всё в ~55к. Зато тепрерь эта дурища не признаёт различий в материале и выдаёт точность не хуже 0.1мм (если бы поставил и расчитал нормальные ШВП, а не трапецевидные гайки на тех же валах, было бы в разы лучше и люфт снизился до десятков микрон, но... поступил недальновидно). В итоге получаю платы с допуском 0.1мм по габаритам и сверловкой с промахом не хуже 0.15мм, чаще всего идеально в центре. Но дорого :( Осталось переделать ось под столом. Но лень.
Эх... Купил я тут новый телефон на замену прошлому (у которого система вдруг пошла в разнос - телефон перезапустился, поймал boot-loop, а после восстановления потерял root). Новый смарт уже с Android 9 и, как оказалось, фирменным white-list'ом приложений. Он не так глубоко запрятан в настройки, но... что ж лезет в настройки "Умного помощника", когда там обычно только настройка жестов и обработка дополнительной кнопки?. Мало кто. А белый список оказался именно в нём и назывался "Блокировка приложений". В общем, don't kill my app показывал 1% рабочего времени до его выброса из памяти (при тесте на 1 час), то есть его выбрасывало пинком в окно практически сразу после блокировки экрана. После включения разрешения в этом самом помощнике результат сразу перешёл в 100%. Вот такая интересная особенность вендора (Conquest в моём случае). Но подлянка после Android 8 оказалась неожиданной, ибо в последнем ВСЕ приложения работали... хотя бы нормально. Мессенджеры получали сообщения в фоне, музыка игралась, данные с часов перетекали в телефон в фоне. А в 9-ке - не работало ни-че-го (мем из "Pumpkin Dance") и пришлось мучаться неделю. Даже залез в logcat, где подозрительно мелькало app-blacklist или что-то подобное.
Для прототипов - делаю плату на ЧПУ и травлю в хлорном железе под фоторезистом. Спокойно получаю 0.25/0.25мм дорожка/зазор. Использую струйный принтер для фотошаблона и "5W" УФ фонарь на более-менее честные 365нм (вообще, жрёт он как раз эти 4-5W от заряженного аккумулятора). Отверстия на ЧПУ 0.3мм, ободок 0.35мм (диаметр пятака - 1мм, сверло 0.3мм) сводятся вообще без проблем. После пропаиваются проволочными перемычками.
Чёт у них там вроди бы своя витруальнма машина, кэш которой при некоторых действиях, приходится чистить (угу, Davik). И подозреваю, что ВСЕ приложения изначально подразумевалось писать именно под него. Так зачем тонны библиотек? Ах да... нельзя просто так взять и сделать на базе обычных библиотек. Почему-то в WM всё работало нормально. Интересно, да?
А знаете, я скучаю по временам Windows CE / Win Mobile 5. Приложения были лаконичными. Мессенджер? QIP Mobile - 1.3МБ. ICQ? 1МБ. Текстовый редактор? 200-300кБ. Пара утилит-виджетов? 16кБ. Всё было легковесным и летало на медленных процах. Не жрало батарею и адекватно вело себя в фоне.
А сейчас что? Телефон с 4ГБ оперативной памяти не может удержать в этой памяти три приложения (и рабочий стол). VK + Telegram ещё как-никак работают, но стоит запустить что-то дополнительно - мессенджеры выдавливает из памяти. Почему? "Потому что ты лох, вот почему" (с)
Кстати, прошу в комментарии написать, кто когда-либо задумывался о причинах того, что верхний предел диапазона измерения ПМИ-2 составляет 10-3 Торр?
И вы сами ответили на вопрос :( Моя мысль была скорее не в износе материала катода, сколько в возможном образовании слишком большого числа ионов, и, следовательно, повышения рабочего тока лампы (а это электронная лампа) и насыщению либо тока коллектора ионов, либо выхода электроники, управляющей лампой в защиту и ограничение тока катод-анод из-за начинающегося разряда между электродами. Фактически, получаем неоновую лампу с подогретым катодом. Знаю, объяснение так себе, но как у технаря достаточно далёкого от электро-вакуумных приборов, и представляющего их работу на основе ещё советского(!) учебника физики... должно получиться немного правдоподобно.
Ядром - да, но тут мне пришла аналогия из Пиратов Карибского Моря. "Всем ни с места! Я обронил мозги." И что-то похожее происходит во время исключений в... да практически во всех ЯП.
Брался готовый, в который должна поместиться плата со всей электроникой и в котором можно проделать отверстия под элементы управления и индикацию. Gainta g430. Наличие корпуса, вероятно, сильно удешевляет производство. Хотя к инженерам, оставляющим документацию к корпусу таким образом, как у конкретно этого производителя, имеются претензии.
Возможно я чего-то не учёл, либо не понял логику работы этого калькулятора, но для мелкосерийных устройств, находящихся между прототипом и законченым устройством, цена исключительно сильно завышена. Выбрал устройство, которое разрабатывал сам: Все графы слева "Нет", т.к. особой миниатюризации не было. LED, Носимое, питание от сети/батареи (на самом деле больше от батареи и зарядка от USB, с возможностью работать при зарядке), промышленность (хотя тут скорее служба сервиса, но более точного варианта не оказалось), экран: 1, штук в год - от 20 до 2к (первое - реальная потребность, второе - на проверку), стоимость ~2500 рублей. И мне выдало какие-то заоблачные 740к+
Извините, даже если сложить мою заработную плату за эти две-три недели, цену на ВСЁ оборудование, которое я использовал при его изготовлении, абсолютно все расходники (даже те, от которых требовалось всего чуть-чуть), то... выходит сильно меньше 100к. Ну это опять же, мой случай - сферический в вакууме. Прибор - по сути хитрый клон трассоискателя. И... реальная стоимость прототипа - 3к + зарплата за это время... порядка 20к. Прототипа. А он функционален. :\ Возможно для проекта типа того же Флиппера, подобные цифры окажутся более реалистичными, но по моим прикидкам, тоже будут завышены.
Так-то да. Только у них в блоге несколько записей с факапами от поставщиков электронных компонентов. Некоторые очень неприятные, так что, думаю можно простить им срыв сроков. Или хотя бы понять его.
Это как раз по причине того, что транзисторы - HEXfet - массив микро-транзисторов в одном корпусе.
В то же время есть "цельные" полевые транзисторы (либо другой вариант внутреннего их устройства), которые не имеют данного эффекта и нагреваются равномерно (и пропускают ток через весь кристалл более-менее одинаково). Их как раз можно использовать в линейном режиме, о чём в datasheet'ах обычно говорится явно. Первым нагуглится IXYS IXTA15N50 (Даташит), в котором явно указано:
Features > Designed for Linear Operation
А обычные HEXfet такой строки не имеют (те же, любимые мной n7002 - обычный выключатель).
Полноценные продажи ожидаются после весны 2022-го, когда будут отправлены все Флипперы, приобретённые через Kikstarter и те, что шли по купонам (полу Kikstarter). В совсем недавней записи их блога, как раз об этом сообщалось. Предарительно необходимо разослать ~60k устройств в ~120 стран мира, при выходе на производство в 5k~10k (к февралю) флипперов в неделю (как раз за месяц могут успеть произвести, плюс время на отправку).
А потом уже поступят в более-менее свободную продажу.
_
PS: Хабр, ну ёмана (с) BBCode уже не поддерживаем, а редактор... неудобный >_<
Карта спокойно работает неделями, но после выключения-включения монитора (со стороны системы) ведёт себя вот так. При этом, особо нагрузки на карту не идёт. И после перезагрузки восстанавливается.
Даже не угадаю. Возможно, около версии 3.6, которая устарела в те же годы. Хотя если пытаться компилировать прямо на системе - может получится и более новую версию поставить.
В итоге я забил на эту заатею, побоявшись доломать систему, и написал костыль, который вместо SoX'а выполняет одну задачу, зато быстро и без вопросов - собирает из двух монофонических файлов один стерео. Заточил под конкретно свою версию asterisk'а. Наверное, нужно было сразу так сделать.
Да может и она. Хотя конкретно у меня 5.11, то есть с некоторыми патчами даже. Исторически так сложилось. :(
попробуйте на досуге найти старые версии виндовых программ.
Те, что запускаются - хотя бы работают. Почти всегда. Но это не обязательно всегда. С исходниками на них всё ещё более грустно, согласен. В этом плане linux сообщество хотя бы веселее.
Сегодня с утра "занимаюсь любовью" с процессом сборки приложения. Где-то успешнее, где-то не очень. На текущий момент удалось добиться только одной ошибки динамической линковки - gcc за каким-то чёртом добавляет одну функцию со ссылками на две версии GLIBC 2.2.5 и 2.27. Но LD спотыкается о свежую версию и устраивает истерику. Старую грузить не пытается :(
SoX - всего-лишь утилита, которая умеет работать с аудиофайлами wav, в частности, Asterisk'а. К сожалению, проблема в том, что на CentOS 5-й версии невозможно установить слинкованый обычным образом бинарник, ибо тот требует libc6 версии выше 2.14 (LD при загрузке ищет версии 2.9 - 2.15), но если поставить её в систему штатно - упадёт до чёртиков всего остального. А найти статически слинкованый бинарник почему-то не удалось.
Собрать этот же даже саму библиотеку (её можно подкинуть общим файлом libc-2-14.so), но его для начала нужно скомпилировать, потому что в репозиториях уже давно версии 2.23+
Компиляция не идёт по причине выше. Вот и... "Оно само сломалось"
А ещё там зависимости и чёрт ногу сломит в "А требует М", "М требует Ф, Н, П версии не выше 7.113/8, параграф 14", "Н (который есть на диске), требует П версии не ниже 8.12Ж" и так далее. "Зависимости сломаны" (с) apt-get
Потому вариант компилить всё статическими образами, к сожалению, и остаётся. А с ним вопрос, где. Опять ставить виртуальную машину, поскольку докер там развернуть будет.... мягко говоря, проблемно.
Понадобилось мне на прошлой неделе обновить версию SoX на CentOS. Система на сервере старая, сервер закрыт. Из-за закончившейся поддержки на web-управление, обновлять его нельзя (пробовали - ломается всё; просто потому что). В итоге после недавней волны устаревания корневых сертификатов, вся система управления пакетами (CentOS 5.11) превращается в тыкву.
Ладно, чёрт был бы с ней, ведь мне нужен только один скомпилированный файл.
Но тут начниается веселье. Просто так никто не хранит этот пакет, потому что он устарел. Но все хранят исходники. Прелестно!
Качачем тот пакет, который хранится в репозитории. Ставится? Нет. Почему? Просто потому что. (На самом деле из-за зависимостей, которые протухли уже лет пять назад; Почему - читаем выше, ибо всё ломается).
Качаем исходники? Качаем. Собриаем на том же сервере? Нет. Там вообще нет инструментов для сборки, да и (естественно!) gcc устарел. Хорошо. Пробую собрать на Debian машине. Что в итоге? gcc устарел. Подождите-ка! Дистрибутив был установлен всего пару лет назад! Ах да, make тоже устарел, потому идинахер (с)
# apt-get update && apt-get install gcc make
apt: Ничего не знаю, у нас самые свежие версии!
Ну спасибо, разработчики, блин.
Ладно, я ещё как-то могу понять, почему им устарел gss. Но make за что?!
И так всё в linux* дестрибутивах. Устарела библиотека? Обновляйся, или иди на###. Обновляешь пакет, который требует что-то хитрое? Ищи репозиторий. Репозиторий протух? Смотри выше.
Так что ситуация с софтом - это повесместное.
А тормозящие кеды - это в принципе забавно. Они ещё и драйверы видеокарты могут терять на лету. И пытаясь разблокировать экран можно поймать экспрессионизм на грани Пикассо:
Конкретно здесь - что-то случилось с драйвером Mesa для Radeon HD2600
В некоторых случаях срабатывают Glitch-атаки. Но их нужно проводить в строго определённое время между снятием сигнала сброса, иногда отсчёт идёт с момента подачи питания.
Была ещё интересная история про взлом ключей приставки кабельного ТВ во франции, но я не могу вспомнить, было ли это на Хабре, или где-то в другом месте. Разве что там использовали дополнительное питание процессора, чтобы он не потерял содержимое памяти между успешным запуском и переносом (физическим) его в программатор для считывания этой самой памяти.
Сейчас у меня нет с собой фотографий фрезера, но дома постараюсь загрузить.
Использую комбинированную технологию - отверстия на ЧПУ + фоторезист. Третий класс точности - хотелось бы, но текстолит с толстой медью этому не способствует (с дуру заказал 35мкм). Его теоретически можно достичь в домашних условиях, но это слегка за гранью возможностей струйного принтера (печатаю фотошаблоны на плёнке, засвечиваю УФ фонариком на 3-5Вт). Вообще, изначально ЧПУ довольно спорный. Механика не жёсткая, ось хрупкая, шпиндель что ни делай, имеет люфт (раз на раз немного меняется - решилось установкой бесщёточного шпинделя - вибрации стали раза в три меньше).
От родного остались только плата управления, моторы, часть проводки, 2 вала и ведущий вал. Остальное было безжалостно заменено на заказанные детали. При сборке тоже были весёлые косяки, но объективно, доволен.
Китайский 3018 после покупки требует переделки, потому что у него "мягкая жёсткость". Все его валы гуляют при небольшом усилии. Шпиндель вообще в момент сверловки/фрезеровки отклоняется от платы вверх (его выгибает на валах, когда инструмент упирается в плату). На тонких свёрлах незаметно, а вот 1.5мм+ уже очень хорошо видно. И отверстие... уходит в сторону ОТ широкой оси. Ах да. Ещё он сломал ДВЕ(!) оси Z - пошли трещины вокруг радиальных подшипников (больше всего вокруг нижних).
В общем, свой 3018 я переделал полностью на рельсы и алюминиевый профиль (ЧПУ обработка на заводе). Обошлось мне это всё в ~55к. Зато тепрерь эта дурища не признаёт различий в материале и выдаёт точность не хуже 0.1мм (если бы поставил и расчитал нормальные ШВП, а не трапецевидные гайки на тех же валах, было бы в разы лучше и люфт снизился до десятков микрон, но... поступил недальновидно). В итоге получаю платы с допуском 0.1мм по габаритам и сверловкой с промахом не хуже 0.15мм, чаще всего идеально в центре. Но дорого :(
Осталось переделать ось под столом. Но лень.
Эх... Купил я тут новый телефон на замену прошлому (у которого система вдруг пошла в разнос - телефон перезапустился, поймал boot-loop, а после восстановления потерял root). Новый смарт уже с Android 9 и, как оказалось, фирменным white-list'ом приложений. Он не так глубоко запрятан в настройки, но... что ж лезет в настройки "Умного помощника", когда там обычно только настройка жестов и обработка дополнительной кнопки?. Мало кто. А белый список оказался именно в нём и назывался "Блокировка приложений".
В общем, don't kill my app показывал 1% рабочего времени до его выброса из памяти (при тесте на 1 час), то есть его выбрасывало пинком в окно практически сразу после блокировки экрана. После включения разрешения в этом самом помощнике результат сразу перешёл в 100%.
Вот такая интересная особенность вендора (Conquest в моём случае). Но подлянка после Android 8 оказалась неожиданной, ибо в последнем ВСЕ приложения работали... хотя бы нормально. Мессенджеры получали сообщения в фоне, музыка игралась, данные с часов перетекали в телефон в фоне. А в 9-ке - не работало ни-че-го (мем из "Pumpkin Dance") и пришлось мучаться неделю. Даже залез в logcat, где подозрительно мелькало app-blacklist или что-то подобное.
Для прототипов - делаю плату на ЧПУ и травлю в хлорном железе под фоторезистом. Спокойно получаю 0.25/0.25мм дорожка/зазор. Использую струйный принтер для фотошаблона и "5W" УФ фонарь на более-менее честные 365нм (вообще, жрёт он как раз эти 4-5W от заряженного аккумулятора). Отверстия на ЧПУ 0.3мм, ободок 0.35мм (диаметр пятака - 1мм, сверло 0.3мм) сводятся вообще без проблем. После пропаиваются проволочными перемычками.
Чёт у них там вроди бы своя витруальнма машина, кэш которой при некоторых действиях, приходится чистить (угу, Davik). И подозреваю, что ВСЕ приложения изначально подразумевалось писать именно под него.
Так зачем тонны библиотек? Ах да... нельзя просто так взять и сделать на базе обычных библиотек.
Почему-то в WM всё работало нормально. Интересно, да?
А знаете, я скучаю по временам Windows CE / Win Mobile 5.
Приложения были лаконичными. Мессенджер? QIP Mobile - 1.3МБ. ICQ? 1МБ. Текстовый редактор? 200-300кБ. Пара утилит-виджетов? 16кБ.
Всё было легковесным и летало на медленных процах. Не жрало батарею и адекватно вело себя в фоне.
А сейчас что?
Телефон с 4ГБ оперативной памяти не может удержать в этой памяти три приложения (и рабочий стол). VK + Telegram ещё как-никак работают, но стоит запустить что-то дополнительно - мессенджеры выдавливает из памяти. Почему? "Потому что ты лох, вот почему" (с)
И вы сами ответили на вопрос :(
Моя мысль была скорее не в износе материала катода, сколько в возможном образовании слишком большого числа ионов, и, следовательно, повышения рабочего тока лампы (а это электронная лампа) и насыщению либо тока коллектора ионов, либо выхода электроники, управляющей лампой в защиту и ограничение тока катод-анод из-за начинающегося разряда между электродами. Фактически, получаем неоновую лампу с подогретым катодом.
Знаю, объяснение так себе, но как у технаря достаточно далёкого от электро-вакуумных приборов, и представляющего их работу на основе ещё советского(!) учебника физики... должно получиться немного правдоподобно.
Ядром - да, но тут мне пришла аналогия из Пиратов Карибского Моря.
"Всем ни с места! Я обронил мозги."
И что-то похожее происходит во время исключений в... да практически во всех ЯП.
Брался готовый, в который должна поместиться плата со всей электроникой и в котором можно проделать отверстия под элементы управления и индикацию. Gainta g430. Наличие корпуса, вероятно, сильно удешевляет производство. Хотя к инженерам, оставляющим документацию к корпусу таким образом, как у конкретно этого производителя, имеются претензии.
Вверх.
Возможно я чего-то не учёл, либо не понял логику работы этого калькулятора, но для мелкосерийных устройств, находящихся между прототипом и законченым устройством, цена исключительно сильно завышена.
Выбрал устройство, которое разрабатывал сам: Все графы слева "Нет", т.к. особой миниатюризации не было.
LED, Носимое, питание от сети/батареи (на самом деле больше от батареи и зарядка от USB, с возможностью работать при зарядке), промышленность (хотя тут скорее служба сервиса, но более точного варианта не оказалось), экран: 1, штук в год - от 20 до 2к (первое - реальная потребность, второе - на проверку), стоимость ~2500 рублей.
И мне выдало какие-то заоблачные 740к+
Извините, даже если сложить мою заработную плату за эти две-три недели, цену на ВСЁ оборудование, которое я использовал при его изготовлении, абсолютно все расходники (даже те, от которых требовалось всего чуть-чуть), то... выходит сильно меньше 100к. Ну это опять же, мой случай - сферический в вакууме. Прибор - по сути хитрый клон трассоискателя. И... реальная стоимость прототипа - 3к + зарплата за это время... порядка 20к. Прототипа. А он функционален. :\
Возможно для проекта типа того же Флиппера, подобные цифры окажутся более реалистичными, но по моим прикидкам, тоже будут завышены.
Так-то да. Только у них в блоге несколько записей с факапами от поставщиков электронных компонентов. Некоторые очень неприятные, так что, думаю можно простить им срыв сроков. Или хотя бы понять его.
Это как раз по причине того, что транзисторы - HEXfet - массив микро-транзисторов в одном корпусе.
В то же время есть "цельные" полевые транзисторы (либо другой вариант внутреннего их устройства), которые не имеют данного эффекта и нагреваются равномерно (и пропускают ток через весь кристалл более-менее одинаково). Их как раз можно использовать в линейном режиме, о чём в datasheet'ах обычно говорится явно. Первым нагуглится IXYS IXTA15N50 (Даташит), в котором явно указано:
Features
> Designed for Linear Operation
А обычные HEXfet такой строки не имеют (те же, любимые мной n7002 - обычный выключатель).
Полноценные продажи ожидаются после весны 2022-го, когда будут отправлены все Флипперы, приобретённые через Kikstarter и те, что шли по купонам (полу Kikstarter). В совсем недавней записи их блога, как раз об этом сообщалось. Предарительно необходимо разослать ~60k устройств в ~120 стран мира, при выходе на производство в 5k~10k (к февралю) флипперов в неделю (как раз за месяц могут успеть произвести, плюс время на отправку).
А потом уже поступят в более-менее свободную продажу.
_
PS: Хабр, ну ёмана (с) BBCode уже не поддерживаем, а редактор... неудобный >_<
Карта спокойно работает неделями, но после выключения-включения монитора (со стороны системы) ведёт себя вот так. При этом, особо нагрузки на карту не идёт. И после перезагрузки восстанавливается.
Не очень-то похоже на отвал.
Даже не угадаю. Возможно, около версии 3.6, которая устарела в те же годы. Хотя если пытаться компилировать прямо на системе - может получится и более новую версию поставить.
У меня там как бы сервер без GUI. =]
В итоге я забил на эту заатею, побоявшись доломать систему, и написал костыль, который вместо SoX'а выполняет одну задачу, зато быстро и без вопросов - собирает из двух монофонических файлов один стерео. Заточил под конкретно свою версию asterisk'а.
Наверное, нужно было сразу так сделать.
Да может и она. Хотя конкретно у меня 5.11, то есть с некоторыми патчами даже. Исторически так сложилось. :(
Те, что запускаются - хотя бы работают. Почти всегда. Но это не обязательно всегда.
С исходниками на них всё ещё более грустно, согласен. В этом плане linux сообщество хотя бы веселее.
Сегодня с утра "занимаюсь любовью" с процессом сборки приложения. Где-то успешнее, где-то не очень. На текущий момент удалось добиться только одной ошибки динамической линковки - gcc за каким-то чёртом добавляет одну функцию со ссылками на две версии GLIBC 2.2.5 и 2.27. Но LD спотыкается о свежую версию и устраивает истерику. Старую грузить не пытается :(
SoX - всего-лишь утилита, которая умеет работать с аудиофайлами wav, в частности, Asterisk'а. К сожалению, проблема в том, что на CentOS 5-й версии невозможно установить слинкованый обычным образом бинарник, ибо тот требует libc6 версии выше 2.14 (LD при загрузке ищет версии 2.9 - 2.15), но если поставить её в систему штатно - упадёт до чёртиков всего остального.
А найти статически слинкованый бинарник почему-то не удалось.
Собрать этот же даже саму библиотеку (её можно подкинуть общим файлом libc-2-14.so), но его для начала нужно скомпилировать, потому что в репозиториях уже давно версии 2.23+
Компиляция не идёт по причине выше. Вот и... "Оно само сломалось"
А ещё там зависимости и чёрт ногу сломит в "А требует М", "М требует Ф, Н, П версии не выше 7.113/8, параграф 14", "Н (который есть на диске), требует П версии не ниже 8.12Ж" и так далее.
"Зависимости сломаны" (с) apt-get
Потому вариант компилить всё статическими образами, к сожалению, и остаётся. А с ним вопрос, где. Опять ставить виртуальную машину, поскольку докер там развернуть будет.... мягко говоря, проблемно.
Так и живём.
Понадобилось мне на прошлой неделе обновить версию SoX на CentOS. Система на сервере старая, сервер закрыт. Из-за закончившейся поддержки на web-управление, обновлять его нельзя (пробовали - ломается всё; просто потому что). В итоге после недавней волны устаревания корневых сертификатов, вся система управления пакетами (CentOS 5.11) превращается в тыкву.
Ладно, чёрт был бы с ней, ведь мне нужен только один скомпилированный файл.
Но тут начниается веселье. Просто так никто не хранит этот пакет, потому что он устарел. Но все хранят исходники. Прелестно!
Качачем тот пакет, который хранится в репозитории. Ставится? Нет. Почему? Просто потому что. (На самом деле из-за зависимостей, которые протухли уже лет пять назад; Почему - читаем выше, ибо всё ломается).
Качаем исходники? Качаем. Собриаем на том же сервере? Нет. Там вообще нет инструментов для сборки, да и (естественно!) gcc устарел. Хорошо. Пробую собрать на Debian машине. Что в итоге? gcc устарел. Подождите-ка! Дистрибутив был установлен всего пару лет назад! Ах да, make тоже устарел, потому идинахер (с)
# apt-get update && apt-get install gcc make
apt: Ничего не знаю, у нас самые свежие версии!
Ну спасибо, разработчики, блин.
Ладно, я ещё как-то могу понять, почему им устарел gss. Но make за что?!
И так всё в linux* дестрибутивах. Устарела библиотека? Обновляйся, или иди на###.
Обновляешь пакет, который требует что-то хитрое? Ищи репозиторий. Репозиторий протух? Смотри выше.
Так что ситуация с софтом - это повесместное.
А тормозящие кеды - это в принципе забавно. Они ещё и драйверы видеокарты могут терять на лету. И пытаясь разблокировать экран можно поймать экспрессионизм на грани Пикассо:
В некоторых случаях срабатывают Glitch-атаки. Но их нужно проводить в строго определённое время между снятием сигнала сброса, иногда отсчёт идёт с момента подачи питания.
Например, была статья https://habr.com/ru/post/500246/ хотя здесь используют глитч на пине сброса.
https://habr.com/ru/company/ntc-vulkan/blog/480500/ - Здесь RaccoonSecurity описывает уже vcc-glitch, когда ядро МК пропускает инструкцию, либо неверно её интерпретирует при просадке питания.
Была ещё интересная история про взлом ключей приставки кабельного ТВ во франции, но я не могу вспомнить, было ли это на Хабре, или где-то в другом месте. Разве что там использовали дополнительное питание процессора, чтобы он не потерял содержимое памяти между успешным запуском и переносом (физическим) его в программатор для считывания этой самой памяти.