>> |
№143246
16743407175750.jpg
(662Кб, 1080x924)
Показана уменьшенная копия, оригинал по клику.
>>143232 > Вещаешь из под камушка как настоящий отшельник? Даже если не брать в рассмотрение буквальное отсутствие связи после ракетных ударов и возможность превращения излишне умных штук в тыкву, мне просто иррационально не нравится, когда я что-то купил, а оно не вполне в моей собственности. И одно дело средства связи с другими или что-то, требующее астрономических датасетов и неподъемное для домашних условий, и другое, когда подключение к сети нужно только для телеметрии производителю, а то и вообще только для регистрации. Кстати, работая над продуктом из одной из 100к+ мегакорпорации, известной своими продуктами каждому айтишнику, я этой пресловутой телеметрии за два года в глаза не видел, если у клиента что-то случалось и он особо платежеспособен, к нему просто ногами шел специально обученный человек снимать логи и заливать тестовые прошивки... > Потеря контекста между каналами заложена жёсткой тематикой каждого из них. Это даже в рабочих чатах на ограниченное число участниках вызывает либо зафлуживание, либо множественные дублирования, особенно если модераторов толком нет и вышестоящее начальство может тупо создавать каналы под разовые темы. Конечно, для длительных размеренных обсуждений ошибочно изначально брать формат чата, но похоже что кроме мессенджеров и инстаграма современное поколение уже ничем пользоваться не умеет, даже пользоваться емейлами для дела приходится доучивать... > Кстати, когда ты в последний раз пользовался этим функционалом? Буквально выше несколькими постами ставил ссылку на сильно более ранний пост, сохраняя текущий контекст: >>143215 > Нормальный search anywhere лучше грепа, т.к. умнее и удобнее. Умнее и удобнее не означает лучше. Конкретный пример: есть такая функция в стандартных библиотеках винды и линукса, ftime(), возвращающая время с миллисекундным разрешением, и есть у нее фатальный недостаток - она страдает проблемой 2038 года. И есть билд одной проприетарной сборочки, зашивающейся на полсотни платформ (текущая линейка устройств + навыпущенное и саппортимое десяток лет), общий вес кодовой базы - полтерабайта. Функция много где вызывалась ранее, на переходной период были написаны варианты кода с новыми заменителями, но в целях совместимости пооставляли старые варианты, отключенные директивой препроцессора. А так как функция используется чаще всего для вывода таймстампов логов, прямо из принтов, то общее число упоминаний в коде измеряется десятками тысяч... Гораздо продуктивнее сбилдить все платформы по одной, и для каждой запускать греп по объектным файлам, и вот уж в какой единице трансляции эта функция оказалась реально скомпилированной, там и дочищать. Можно конечно выпилить ее из libc и посмотреть где упадет билд, но в том случае это плохо работало из-за очень длинного перезапуска билда, полчаса даже на минимальных изменениях. Второе неудобство этих более умных инструментов - это плохая масштабируемость, даже просто ядро линукса весом исходников в полгигабайта на ноуте с 8-16 ГБ рам эклипсом или другим IDE проиндексировать без некоторых подтюниваний студии не получится. > концепция контракта, которая при запуске ядра выкинет ошибку с указанием неверного числа параметров или подобного Это все правильные вещи, примерно как рекомендация вызова скорой или пожарных при соответствующих проблемах, применимые в тепличных городских условиях, очень так себе работающих на поле боя, и совершенно нереализуемые на борту самолета или космической станции. А здесь аналогия с самолетом буквальная, можно делать любые приготовления до или планировать после, но момент загрузки происходит без какой-либо возможности осмысленно подрулить, пока ядро не проинициализирует управление собственными аллокаторами, не запустит ядра процессора, хоть какую-то периферию, куда можно стучаться с ошибками, их тупо некому будет видеть, не то что обрабатывать. Просто оцени, сколько всего нет на старте того же ядра, и какой длинный перечень всего надо запустить даже для собственного существования: https://github.com/torvalds/linux/blob/master/init/main.c#L940 И это мелкий, вырванный с середины загрузки фрагмент, там еще до него сквозь кучу кода вроде такого https://github.com/torvalds/linux/blob/master/arch/x86/boot/compressed/head_64.S побраться до старта надо. > Покрывается интеграционным тестом использующим реальный бутлоадер и реальный инстанс ядра и проверяющий что на stdout/stderr всё хорошо. По самому минимуму, для "stdout/stderr" нужно: загрузить ядро до уровня хотя бы работающего аллокатора и запустить драйвер последовательного порта (причем желательно именно настоящего аппаратного, поднимать целый стек для USB гораздо тяжелее), и чем-то внешним эти принты отлавливать. Это не то, что бы сложно в реализации, но я например ни разу не видел, чтобы даже любители компилять генту со своими кастомными ядрами проводили отладку аж настолько хардкорно, да и в ядерной разработке такое редкость, надо сразу писать правильно. Так вот и живут, без отладки, и с принтами уже в работающей системе... > А зачем? Затем, например, что даже оперативная память не работает без предварительной настройки, и если бутлоадер например ее аппаратно не проинициализировал, а ядро не зная об этом попыталось расположить на ней внутренности своего аллокатора, то оно даже ошибку выдасть не успеет, процессор просто остановится на недопустимой команде. То же, если ядро будет думать что оно на неинициализированном процессоре бежит на одном ядре, если на самом деле бутлоадер инициализировал многопроцессорность - прерывания от периферии, например, таймера для переключения процессов, проходят на все ядра одновременно, и если в ядре не будет настроены правильно механизмы синхронизации, произойдет split-brain, то есть, все ядра выполнят обработчик прерывания и вернутся в одно и то же место основного кода, поехав дальше выполняться впараллель с непредсказуемыми последствиями одновременного доступа к железу разных копий и взаимной порчи памяти друг другу х86 очень либеральная платформа, не бьющая банхаммером за невыровненный или одновременный доступ к памяти, на армах скорее всего убьет сразу... На самом деле, можно многое уточнять запросами к железу, как оно проинициализировано, но во-первых, если делать это на каждое действие, производительность итоговой системы упадет на несколько порядков, во-вторых, все равно стопроцентное покрытие проверками невозможно, что наглядно демонстрирует например Rust, в котором даже в рамках самого рантайма для языка не получается ни избавиться от unsafe для структур данных вроде двухсвязных списков, ни даже стабилизировать спецификацию языка для работы без стандартной библиотеки. Явно последнее не от нехватки внимания к проекту... > Если всё так плохо, то почему втыкание флешек не делает этой ОС бсод? Потому что написано вдумчиво, вылизано за несколько десятилетий, и предприняты меры, чтобы падения не рушили все ядро целиком, в само ядро затащено куча санитайзеров вроде подсчета висящих ссылок, включаемых на этапе тестирования железа путем сборки с отдельными опциями. Но сложность кода при этом растет экспоненциально, а даже отловив баг, понять как именно он происходит в данном куске кода становится все сложнее. > IDE должна вылавливать ошибки мультипотока? Ну как вариант, одно из мест, где бы хотелось упрощения жизни. > Опять же, зачем осиливать всё сразу. Затем, что подавляющее большинство багфикса и допила, по крайней мере в этой сфере, идет впараллель на разных уровнях. Если в автомобильной панели спидометра на андроиде не показывает скорость, это может быть проблема самого .apk, может быть глючная отрисовка картинки, могут быть проблемы с нативным демоном, абстрагирующим CAN-шину в сокеты, может сам драйвер CAN-шины в ядре, может сам тахометр передавать какую-то дичь, а может все работает правильно, но на шине еще висят датчики примерзания дворников и они на стенде передавая статус "поломки" зафлудили всю шину... IDE тут будет скорее тормозом, так как в ней придется постоянно создавать новые подпроекты на каждый модуль и прыгать между ними, и vs code на данный момент выглядит самым адекватным компромиссом. Впрочем, немалый процент пользуется вимом для всего, как минимум у него из коробки неплохо с подсветкой всех экзотических, но встречающихся языков вроде Tcl, или всевозможных форматов линуксовых конфигов.
|