Полная картина сложилась, когда меня как следует ударило током от корпуса ноутбука. Тут я впервые всерьез подумал: а вдруг проблема вообще в электрике?
Теперь я узнал, как люди получают Дарвиновскую премию :)
Вообще говоря, автору прям повезло очень. А мог и помереть.
Пришел техник и посоветовал купить ИБП с AVR, то есть с автоматической стабилизацией напряжения.
Дурной совет, кстати.
Стабилизатор в ИБП представляет собой автотрансформатор с несколькими отводами и блок реле, который переключается между этими отводами.
Во-первых, он очень грубый. Скажем, такой ИБП обещает удерживать 220в ± 10%. На практике это означает, что при снижении напряжения до примерно 200в (-10%) ИБП скачком перейдёт на 240в (+10%). Я что-то не уверен, что это лучше, чем было в розетке до стабилизатора.
А во-вторых, контакты этих реле имеют тенденцию со временем подгорать. и от этого залипают. И вполне может быть так, что в какой-то момент одно реле уже замкнёт, а другое еще не успеет отпустить, из-за износа контактов. И тогда два отвода автотрансформатора окажутся ненадолго соединены между собой, а это - короткое замыкание, ИБП отключится по перегрузке (или за него это сделает автомат в щитке).
В итоге мы размениваем небольшие колебания напряжения, которые прекрасно бы съел блок питания компьютера, на периодические неожиданные отключения.
Это не теория, реальная практика. Переплачивая за ИБП со стабилизатором, мы приобретаем ненужный геморрой за собственные деньги.
Но есть множество ситуаций, когда отладчик, скажем так, малоприменим.
Например, достаточно сложная система с большим количеством параллельных активностей и низкой вероятностью возникновения проблем. Вы запускаете её под отладчиком раз, другой, у вас всё хорошо. А под реальной нагрузкой падает. Даже и не падает, при падении хоть есть стек. Глючит, выдаёт неправильный результат. Сломаное состояние такой системы очень трудно поймать в отладчике.
Другой пример, ваша программа прекрасно работает у вас на компьютере и проходит все тесты. А у заказчика проявляются какие-то ошибки. Приехать к заказчику с отладчиком - не вариант. В лучшем случае вы можете попробовать воспроизвести у себя конфигурацию заказчика. Только вот беда, конфигурацию вы воспроизвели, а у вас всё равно всё хорошо работает. А у него - нет. Куда тут подлезть с отладчиком?
Третий пример, ваша программа прекрасно работает в отладочной сборке. А в релизной - нет. И компилятор так всё соптимизировал, что вы даже и понимаете, куда хотите заглянуть, но отладчик не видит ваших переменных, компилятор их уоптимизировал с глаз долой. Что делать?
Четвёртый пример, ваш код исполняется на встраиваемой системе. Теоретически, там даже и отладчик есть. Только не работает по инструкции. Вы лезете разбираться, и через несколько частов выясняется, что у вас появился новый проект: запустить отладчик на вашей железке. Очевидно непростой, и с малопредсказуемыми сроками исполнения.
Скажете, это редкие случаи? Возможно. Но это зависит от вашего опыта, вашей практики. Как по мне, именно какие-то такие случаи занимают достаточное количество усилий, чтобы хоть запомниться. А те простые случаи, которые берутся с отладчиком, ну они и без него прекрасно берутся.
И вот мысль, которую я хочу подчеркнуть отдельно. Когда основной ваш поиск ошибок происходит в условиях, когда у вас нет доступа к живой системе с отладчиком в руках, вы постепенно приучаетесь структурировать свой код так, что он становится пригоден для такой отладки. Логи в нужных местах, стараетесь не писать в лог всякий шум, события в логах должны быть сводимы, цепочки принятия решений должны отслеживаться. Пользовательскую конфигурацию имеет смысл записать в лог - это экономит время по извлечению её из пользователя (и гарантирует точность). Это влияет на саму логику вашего кода, и влияет в лучшую сторону. Вам приходится заранее хорошо задумываться, что делает ваш код. А не когда уже припёрло.
А потом вспомнил что рекламировать средства обхода блокировок в России с сентября 2025 нелегально, штрафы до 500 тысяч. Закрыл.
Даже и без конских штрафов вы такое не продадите. Люди привыкли получать такие вещи бесплатно. Точно так же, как вы не заработаете денег на опенсорсном проекте, которым пользуется миллион человек.
Придумывая бизнес, не надо забывать культурный контекст.
Ох уж эта священная война между любителями отладчиков и любителями логов.
Отладчик хорош для простых случаев.
Хотел бы я посмотреть, как вы будете отлаживать отладчиком многопоточный высоконагруженный сервер, который нет, не падает под высокой нагрузкой, но начинает лажать в бизнес-логике.
Я уж не говорю о том, что на целевой платформе может просто и не быть отладчика.
Поэтому нет, отладчик не отменяет структурированных логов (и это не просто, “пишем какую-то фигню в cout”).
И ещё один момент. Когда у вас формируется опыт отладки по логам, вы учитесь структурировать код так, чтобы его поведение было понятным по логам. Это делает ваши решения более прямолинейными, что хорошо и для отладки и в целом, для структурирования кода.
Я видел исходный код драйвера WiFi от одного крупного производителя чипов, Название не скажу, с меня взали слово не разглашать.
Там было Фсё. С большой буквы “Ф”. Своя реализация точки доступа. Написанная независимо от hostapd. Своя реализация клиента, не основанная на wpa_supplicant. Ну и разумеется, аппаратные драйвера под несколько платформ.
Я насчитал 6 реализаций одного и того же. Совпадающих почти строка в строку, с мелкими отличиями. Всё это было в одном проекте, разделённое условной компиляцией. Даже по файлам не было разделено.
Возможно, там было больше копий, но мне попались на глаза только 6.
Понять, какой экземпляр используется в какой конфигурации, было невозможно. Даже собрать это чудо было подвигом.
У компании был принцип: при появлении новой конфигурации используется та же кодовая база, но сборки под уже выпущенные конфигурации трогать нельзя. Поэтому всё просто дублировалось, и изменения шли в новую копию. Очень похожие, но немного различающиеся копии постепенно накапливались в единой кодовой базе.
По-моему, этот код был образцовым воплощением принципов, изложенных в данной статье.
Это был код, про который говорят, что он вызывает рак глаз. Когда я взялся за этот проект, мне казалось, что получить NNNN баксов за исправление небольшой ошибки - удачная сделка. Потом пожалел 10 раз, но отказаться уже было нельзя, потому, что это - вопрос чести. Ошибку, кстати, поправил - вслепую, без возможности проверить, потому, что железку соответствующую мне не дали. Но больше - ни за что, никогда.
Начиналось так хорошо, а кончились рекламой Lenza…
Павел занимался продуктовой частью. Он сделал ставку на облачную синхронизацию: где вся история сообщений хранится в облаке и доступна с любого устройства. Меняешь телефон или переходишь на десктоп, логинишься, и все переписки на месте.
В 2013 году такого не было ни у одного мессенджера.
Ответ подумавши. Никто не сказал, что номер паспорта всегда будет выглядеть, как "NN NN NNNNNN". Количество знаков в каждом "поле" может измениться. Количество полей может измениться. Допустимый алфавит может измениться (сейчас он состоит только из цифр, но никто не обещал, что это навсегда).
Будет нехорошо, если гос-во изменит формат номеров паспортов, и паспорта старого типа будет невозможно хранить в базе вместе с новыми.
И как выше уже отметили, бывают паспорта, выданные другими государствами, и там могут быть свои особенности.
Поэтому, наверное, всё же строка, но в URI-образном формате: "scheme:identifier". Для каждой схемы - свой порядок преобразования символов из бумажного документа в символы в базе. Например, можно договориться, что современные российские паспорта хранятся в виде "NNNN NNNNNN", без пробела между половинками серии и с одним пробелом между серией и номером.
Заодно схема образует namespace, и мы не сравним случайно номер армянского паспорта с номером паспорта из Мозамбика - кто знает заранее, вдруг у них одинаковый формат и номера могут совпасть?
Ну и эта. Есть смысл посмотреть, нет ли на эту тему международных стандартов каких. А то вдруг мы еще чего не учли...
В основе системы лежит модульная архитектура CorePC. Благодаря этому компоненты операционной системы больше не будут жестко переплетены между собой. Мы даже можем увидеть возможность обновления конкретных модулей без необходимости трогать остальные. На практике это означает, что одна и та же система сможет работать как на слабом планшете, так и на мощной рабочей станции — в разных, адаптированных конфигурациях.
А что это вообще значит? Что у неё, наконец, переписали инсталлятор, и она не ставит всё подряд и не обновляет всё подряд без нужды.
Так-то у неё компоненты особо-то и не были переплетены. Компоненты себе и компоненты, общаются по COM, особо друг на друга не завязаны. Собственно, COM для того и придумали, чтобы запчасти ОС можно было свинчивать между собой не на фабрике, а в рантайме. И COM-у этому уже лет 35, если учитывать его предшественник, обкатанный ещё на OS/2...
При всём при том, у меня самодельный проирыватель фильмов (маленький PC с линуксом и xbmc/kodi) грузится за 3 секунды. Причём 2 из них думает BIOS
Hint: я норме я его не выключаю, а усыпляю. Холодная загрузка занимает 15 секунд. Думаю, если сильно упереться, можно было бы сократить до 5, но лень этим заниматься...
Теперь я узнал, как люди получают Дарвиновскую премию :)
Вообще говоря, автору прям повезло очень. А мог и помереть.
Дурной совет, кстати.
Стабилизатор в ИБП представляет собой автотрансформатор с несколькими отводами и блок реле, который переключается между этими отводами.
Во-первых, он очень грубый. Скажем, такой ИБП обещает удерживать 220в ± 10%. На практике это означает, что при снижении напряжения до примерно 200в (-10%) ИБП скачком перейдёт на 240в (+10%). Я что-то не уверен, что это лучше, чем было в розетке до стабилизатора.
А во-вторых, контакты этих реле имеют тенденцию со временем подгорать. и от этого залипают. И вполне может быть так, что в какой-то момент одно реле уже замкнёт, а другое еще не успеет отпустить, из-за износа контактов. И тогда два отвода автотрансформатора окажутся ненадолго соединены между собой, а это - короткое замыкание, ИБП отключится по перегрузке (или за него это сделает автомат в щитке).
В итоге мы размениваем небольшие колебания напряжения, которые прекрасно бы съел блок питания компьютера, на периодические неожиданные отключения.
Это не теория, реальная практика. Переплачивая за ИБП со стабилизатором, мы приобретаем ненужный геморрой за собственные деньги.
Как бы так сказать…
Я не возражаю против отладчика, как такового.
Но есть множество ситуаций, когда отладчик, скажем так, малоприменим.
Например, достаточно сложная система с большим количеством параллельных активностей и низкой вероятностью возникновения проблем. Вы запускаете её под отладчиком раз, другой, у вас всё хорошо. А под реальной нагрузкой падает. Даже и не падает, при падении хоть есть стек. Глючит, выдаёт неправильный результат. Сломаное состояние такой системы очень трудно поймать в отладчике.
Другой пример, ваша программа прекрасно работает у вас на компьютере и проходит все тесты. А у заказчика проявляются какие-то ошибки. Приехать к заказчику с отладчиком - не вариант. В лучшем случае вы можете попробовать воспроизвести у себя конфигурацию заказчика. Только вот беда, конфигурацию вы воспроизвели, а у вас всё равно всё хорошо работает. А у него - нет. Куда тут подлезть с отладчиком?
Третий пример, ваша программа прекрасно работает в отладочной сборке. А в релизной - нет. И компилятор так всё соптимизировал, что вы даже и понимаете, куда хотите заглянуть, но отладчик не видит ваших переменных, компилятор их уоптимизировал с глаз долой. Что делать?
Четвёртый пример, ваш код исполняется на встраиваемой системе. Теоретически, там даже и отладчик есть. Только не работает по инструкции. Вы лезете разбираться, и через несколько частов выясняется, что у вас появился новый проект: запустить отладчик на вашей железке. Очевидно непростой, и с малопредсказуемыми сроками исполнения.
Скажете, это редкие случаи? Возможно. Но это зависит от вашего опыта, вашей практики. Как по мне, именно какие-то такие случаи занимают достаточное количество усилий, чтобы хоть запомниться. А те простые случаи, которые берутся с отладчиком, ну они и без него прекрасно берутся.
И вот мысль, которую я хочу подчеркнуть отдельно. Когда основной ваш поиск ошибок происходит в условиях, когда у вас нет доступа к живой системе с отладчиком в руках, вы постепенно приучаетесь структурировать свой код так, что он становится пригоден для такой отладки. Логи в нужных местах, стараетесь не писать в лог всякий шум, события в логах должны быть сводимы, цепочки принятия решений должны отслеживаться. Пользовательскую конфигурацию имеет смысл записать в лог - это экономит время по извлечению её из пользователя (и гарантирует точность). Это влияет на саму логику вашего кода, и влияет в лучшую сторону. Вам приходится заранее хорошо задумываться, что делает ваш код. А не когда уже припёрло.
По-моему, как-то вот так…
Да вот пример из собственной практики, в гошном stdlib-е:
https://habr.com/ru/articles/906796/
С точки зрения санитайзера (race detector-а), там всё было хорошо.
Ну допустим, под тред саном проблема не воспроизводится. И тред сан не находит, к чему придраться.
Что дальше будем делать?
Даже и без конских штрафов вы такое не продадите. Люди привыкли получать такие вещи бесплатно. Точно так же, как вы не заработаете денег на опенсорсном проекте, которым пользуется миллион человек.
Придумывая бизнес, не надо забывать культурный контекст.
Неужели у вас нет кранов на батареях?
Настоящий линукс тоже, как не удивительно, реализует Linux ABI/API поверх внутренней инфраструктуры ядра, Которая не тождественна публичному API…
Ох уж эта священная война между любителями отладчиков и любителями логов.
Отладчик хорош для простых случаев.
Хотел бы я посмотреть, как вы будете отлаживать отладчиком многопоточный высоконагруженный сервер, который нет, не падает под высокой нагрузкой, но начинает лажать в бизнес-логике.
Я уж не говорю о том, что на целевой платформе может просто и не быть отладчика.
Поэтому нет, отладчик не отменяет структурированных логов (и это не просто, “пишем какую-то фигню в cout”).
И ещё один момент. Когда у вас формируется опыт отладки по логам, вы учитесь структурировать код так, чтобы его поведение было понятным по логам. Это делает ваши решения более прямолинейными, что хорошо и для отладки и в целом, для структурирования кода.
Я видел исходный код драйвера WiFi от одного крупного производителя чипов, Название не скажу, с меня взали слово не разглашать.
Там было Фсё. С большой буквы “Ф”. Своя реализация точки доступа. Написанная независимо от hostapd. Своя реализация клиента, не основанная на wpa_supplicant. Ну и разумеется, аппаратные драйвера под несколько платформ.
Я насчитал 6 реализаций одного и того же. Совпадающих почти строка в строку, с мелкими отличиями. Всё это было в одном проекте, разделённое условной компиляцией. Даже по файлам не было разделено.
Возможно, там было больше копий, но мне попались на глаза только 6.
Понять, какой экземпляр используется в какой конфигурации, было невозможно. Даже собрать это чудо было подвигом.
У компании был принцип: при появлении новой конфигурации используется та же кодовая база, но сборки под уже выпущенные конфигурации трогать нельзя. Поэтому всё просто дублировалось, и изменения шли в новую копию. Очень похожие, но немного различающиеся копии постепенно накапливались в единой кодовой базе.
По-моему, этот код был образцовым воплощением принципов, изложенных в данной статье.
Это был код, про который говорят, что он вызывает рак глаз. Когда я взялся за этот проект, мне казалось, что получить NNNN баксов за исправление небольшой ошибки - удачная сделка. Потом пожалел 10 раз, но отказаться уже было нельзя, потому, что это - вопрос чести. Ошибку, кстати, поправил - вслепую, без возможности проверить, потому, что железку соответствующую мне не дали. Но больше - ни за что, никогда.
Я вот думаю, если за человека может сделать всю работу его секретарша, возможно, этот человек находится не на своём месте?
Вот так же и с ИИ…
Начиналось так хорошо, а кончились рекламой Lenza…
Скайп так всегда умел
Ответ навскидку: строка
Ответ подумавши. Никто не сказал, что номер паспорта всегда будет выглядеть, как "NN NN NNNNNN". Количество знаков в каждом "поле" может измениться. Количество полей может измениться. Допустимый алфавит может измениться (сейчас он состоит только из цифр, но никто не обещал, что это навсегда).
Будет нехорошо, если гос-во изменит формат номеров паспортов, и паспорта старого типа будет невозможно хранить в базе вместе с новыми.
И как выше уже отметили, бывают паспорта, выданные другими государствами, и там могут быть свои особенности.
Поэтому, наверное, всё же строка, но в URI-образном формате: "scheme:identifier". Для каждой схемы - свой порядок преобразования символов из бумажного документа в символы в базе. Например, можно договориться, что современные российские паспорта хранятся в виде "NNNN NNNNNN", без пробела между половинками серии и с одним пробелом между серией и номером.
Заодно схема образует namespace, и мы не сравним случайно номер армянского паспорта с номером паспорта из Мозамбика - кто знает заранее, вдруг у них одинаковый формат и номера могут совпасть?
Ну и эта. Есть смысл посмотреть, нет ли на эту тему международных стандартов каких. А то вдруг мы еще чего не учли...
А мужик, который сзади на картинке играет в игрушку на сотовом телефоне, он на неё что, прямо сквозь телефон смотрит? Или ИИ так видит?
Чем это плохо, если в проекте мало людей?
По щиколотку. Вниз головой.
Там BIOS непойми о чём думает 2 секунды. Если еще 3 отдать линуху, как раз в сумме 5 и получится...
А что это вообще значит? Что у неё, наконец, переписали инсталлятор, и она не ставит всё подряд и не обновляет всё подряд без нужды.
Так-то у неё компоненты особо-то и не были переплетены. Компоненты себе и компоненты, общаются по COM, особо друг на друга не завязаны. Собственно, COM для того и придумали, чтобы запчасти ОС можно было свинчивать между собой не на фабрике, а в рантайме. И COM-у этому уже лет 35, если учитывать его предшественник, обкатанный ещё на OS/2...
При всём при том, у меня самодельный проирыватель фильмов (маленький PC с линуксом и xbmc/kodi) грузится за 3 секунды. Причём 2 из них думает BIOS
Hint: я норме я его не выключаю, а усыпляю. Холодная загрузка занимает 15 секунд. Думаю, если сильно упереться, можно было бы сократить до 5, но лень этим заниматься...
А почему на этот раз так не получилось?
А точно ли этот ваш Signal такой защищённый? Или это просто вопрос выбора, спецслужбе какой страны открыть свою переписку?