Бить током от ноута - кто-то может пояснить КАК? Если от БП идет 110 (220), на разве в цепях питания не будет пробоя?
Очень просто.
Представим себе, от БП должны идти условные 19в. Т.е., в одном проводе 0, в другом +19.
А теперь представим, что из-за пробоя в одном проводе идёт 0 + 110 переменного тока, в другом - 19 + 110 того же переменного тока.
С точки зрения самого ноута ничего не изменилось, как было 19в между входными проводами питания, так и осталось.
Но только вот теперь дополнительно появилось 110в переменного тока на корпусе. Ноуту это не заметно, а вот человеку, который может касаться рукой металлического корпуса а ногой - чего-нибудь заземленного, вломит по полной программе.
Потому, что всё время преобразовывают. Если считать, что у ник КПД - 90%, то 10% потребляемой электроэнергии им надо всё время рассеивать в виде тепла.
В отличии от них, “простые” ИБП когда всё ОК, ничего почти и не делают, только поддерживают заряд батарей небольшим током.
Полная картина сложилась, когда меня как следует ударило током от корпуса ноутбука. Тут я впервые всерьез подумал: а вдруг проблема вообще в электрике?
Теперь я узнал, как люди получают Дарвиновскую премию :)
Вообще говоря, автору прям повезло очень. А мог и помереть.
Пришел техник и посоветовал купить ИБП с AVR, то есть с автоматической стабилизацией напряжения.
Дурной совет, кстати.
Стабилизатор в ИБП представляет собой автотрансформатор с несколькими отводами и блок реле, который переключается между этими отводами.
Во-первых, он очень грубый. Скажем, такой ИБП обещает удерживать 220в ± 10%. На практике это означает, что при снижении напряжения до примерно 200в (-10%) ИБП скачком перейдёт на 240в (+10%). Я что-то не уверен, что это лучше, чем было в розетке до стабилизатора.
А во-вторых, контакты этих реле имеют тенденцию со временем подгорать. и от этого залипают. И вполне может быть так, что в какой-то момент одно реле уже замкнёт, а другое еще не успеет отпустить, из-за износа контактов. И тогда два отвода автотрансформатора окажутся ненадолго соединены между собой, а это - короткое замыкание, ИБП отключится по перегрузке (или за него это сделает автомат в щитке).
В итоге мы размениваем небольшие колебания напряжения, которые прекрасно бы съел блок питания компьютера, на периодические неожиданные отключения.
Это не теория, реальная практика. Переплачивая за ИБП со стабилизатором, мы приобретаем ненужный геморрой за собственные деньги.
Но есть множество ситуаций, когда отладчик, скажем так, малоприменим.
Например, достаточно сложная система с большим количеством параллельных активностей и низкой вероятностью возникновения проблем. Вы запускаете её под отладчиком раз, другой, у вас всё хорошо. А под реальной нагрузкой падает. Даже и не падает, при падении хоть есть стек. Глючит, выдаёт неправильный результат. Сломаное состояние такой системы очень трудно поймать в отладчике.
Другой пример, ваша программа прекрасно работает у вас на компьютере и проходит все тесты. А у заказчика проявляются какие-то ошибки. Приехать к заказчику с отладчиком - не вариант. В лучшем случае вы можете попробовать воспроизвести у себя конфигурацию заказчика. Только вот беда, конфигурацию вы воспроизвели, а у вас всё равно всё хорошо работает. А у него - нет. Куда тут подлезть с отладчиком?
Третий пример, ваша программа прекрасно работает в отладочной сборке. А в релизной - нет. И компилятор так всё соптимизировал, что вы даже и понимаете, куда хотите заглянуть, но отладчик не видит ваших переменных, компилятор их уоптимизировал с глаз долой. Что делать?
Четвёртый пример, ваш код исполняется на встраиваемой системе. Теоретически, там даже и отладчик есть. Только не работает по инструкции. Вы лезете разбираться, и через несколько частов выясняется, что у вас появился новый проект: запустить отладчик на вашей железке. Очевидно непростой, и с малопредсказуемыми сроками исполнения.
Скажете, это редкие случаи? Возможно. Но это зависит от вашего опыта, вашей практики. Как по мне, именно какие-то такие случаи занимают достаточное количество усилий, чтобы хоть запомниться. А те простые случаи, которые берутся с отладчиком, ну они и без него прекрасно берутся.
И вот мысль, которую я хочу подчеркнуть отдельно. Когда основной ваш поиск ошибок происходит в условиях, когда у вас нет доступа к живой системе с отладчиком в руках, вы постепенно приучаетесь структурировать свой код так, что он становится пригоден для такой отладки. Логи в нужных местах, стараетесь не писать в лог всякий шум, события в логах должны быть сводимы, цепочки принятия решений должны отслеживаться. Пользовательскую конфигурацию имеет смысл записать в лог - это экономит время по извлечению её из пользователя (и гарантирует точность). Это влияет на саму логику вашего кода, и влияет в лучшую сторону. Вам приходится заранее хорошо задумываться, что делает ваш код. А не когда уже припёрло.
А потом вспомнил что рекламировать средства обхода блокировок в России с сентября 2025 нелегально, штрафы до 500 тысяч. Закрыл.
Даже и без конских штрафов вы такое не продадите. Люди привыкли получать такие вещи бесплатно. Точно так же, как вы не заработаете денег на опенсорсном проекте, которым пользуется миллион человек.
Придумывая бизнес, не надо забывать культурный контекст.
Как же мне её искать в гугле, если тут нет ни названия, ни бренда, ничего?
А если меня эта тётка заинтересовала, и продукция её тоже, можно как-то ссылку на сайт узнать или что-нибудь в этом роде?
Очень просто.
Представим себе, от БП должны идти условные 19в. Т.е., в одном проводе 0, в другом +19.
А теперь представим, что из-за пробоя в одном проводе идёт 0 + 110 переменного тока, в другом - 19 + 110 того же переменного тока.
С точки зрения самого ноута ничего не изменилось, как было 19в между входными проводами питания, так и осталось.
Но только вот теперь дополнительно появилось 110в переменного тока на корпусе. Ноуту это не заметно, а вот человеку, который может касаться рукой металлического корпуса а ногой - чего-нибудь заземленного, вломит по полной программе.
С этим лучше не шутить.
Кому как :)
Я сам начинал с железок всяческих, но постепенно пришёл к чистому программированию
А программа ещё приятнее.
“Банан велик, но кожура - больше”?
RedHat аутсорсит не экспертизу, а ответственность
Заметим, эта ниша занята. Там даже Canonical места не хватило. Canonical пытается создать магазин приложений и стать его оператором
Ну, мальчиком по вызову много не заработаешь.
Это игра где-то в той же лиге, что и всякие там установщики венды…
Вы знаете, как?
Я в детстве пытался починить ламповый радиоприёмник
В общем, экспериментальный факт: 250в постоянного тока меня не убивает. Но удовольствие прям сильно ниже среднего
У человека с другой проводимостью кожи и результат может оказаться другой
Я вроде примерно то же и сказал…
Потому, что всё время преобразовывают. Если считать, что у ник КПД - 90%, то 10% потребляемой электроэнергии им надо всё время рассеивать в виде тепла.
В отличии от них, “простые” ИБП когда всё ОК, ничего почти и не делают, только поддерживают заряд батарей небольшим током.
Зачем мне ИБП двойного преобразования?
Они шумят…
Теперь я узнал, как люди получают Дарвиновскую премию :)
Вообще говоря, автору прям повезло очень. А мог и помереть.
Дурной совет, кстати.
Стабилизатор в ИБП представляет собой автотрансформатор с несколькими отводами и блок реле, который переключается между этими отводами.
Во-первых, он очень грубый. Скажем, такой ИБП обещает удерживать 220в ± 10%. На практике это означает, что при снижении напряжения до примерно 200в (-10%) ИБП скачком перейдёт на 240в (+10%). Я что-то не уверен, что это лучше, чем было в розетке до стабилизатора.
А во-вторых, контакты этих реле имеют тенденцию со временем подгорать. и от этого залипают. И вполне может быть так, что в какой-то момент одно реле уже замкнёт, а другое еще не успеет отпустить, из-за износа контактов. И тогда два отвода автотрансформатора окажутся ненадолго соединены между собой, а это - короткое замыкание, ИБП отключится по перегрузке (или за него это сделает автомат в щитке).
В итоге мы размениваем небольшие колебания напряжения, которые прекрасно бы съел блок питания компьютера, на периодические неожиданные отключения.
Это не теория, реальная практика. Переплачивая за ИБП со стабилизатором, мы приобретаем ненужный геморрой за собственные деньги.
Как бы так сказать…
Я не возражаю против отладчика, как такового.
Но есть множество ситуаций, когда отладчик, скажем так, малоприменим.
Например, достаточно сложная система с большим количеством параллельных активностей и низкой вероятностью возникновения проблем. Вы запускаете её под отладчиком раз, другой, у вас всё хорошо. А под реальной нагрузкой падает. Даже и не падает, при падении хоть есть стек. Глючит, выдаёт неправильный результат. Сломаное состояние такой системы очень трудно поймать в отладчике.
Другой пример, ваша программа прекрасно работает у вас на компьютере и проходит все тесты. А у заказчика проявляются какие-то ошибки. Приехать к заказчику с отладчиком - не вариант. В лучшем случае вы можете попробовать воспроизвести у себя конфигурацию заказчика. Только вот беда, конфигурацию вы воспроизвели, а у вас всё равно всё хорошо работает. А у него - нет. Куда тут подлезть с отладчиком?
Третий пример, ваша программа прекрасно работает в отладочной сборке. А в релизной - нет. И компилятор так всё соптимизировал, что вы даже и понимаете, куда хотите заглянуть, но отладчик не видит ваших переменных, компилятор их уоптимизировал с глаз долой. Что делать?
Четвёртый пример, ваш код исполняется на встраиваемой системе. Теоретически, там даже и отладчик есть. Только не работает по инструкции. Вы лезете разбираться, и через несколько частов выясняется, что у вас появился новый проект: запустить отладчик на вашей железке. Очевидно непростой, и с малопредсказуемыми сроками исполнения.
Скажете, это редкие случаи? Возможно. Но это зависит от вашего опыта, вашей практики. Как по мне, именно какие-то такие случаи занимают достаточное количество усилий, чтобы хоть запомниться. А те простые случаи, которые берутся с отладчиком, ну они и без него прекрасно берутся.
И вот мысль, которую я хочу подчеркнуть отдельно. Когда основной ваш поиск ошибок происходит в условиях, когда у вас нет доступа к живой системе с отладчиком в руках, вы постепенно приучаетесь структурировать свой код так, что он становится пригоден для такой отладки. Логи в нужных местах, стараетесь не писать в лог всякий шум, события в логах должны быть сводимы, цепочки принятия решений должны отслеживаться. Пользовательскую конфигурацию имеет смысл записать в лог - это экономит время по извлечению её из пользователя (и гарантирует точность). Это влияет на саму логику вашего кода, и влияет в лучшую сторону. Вам приходится заранее хорошо задумываться, что делает ваш код. А не когда уже припёрло.
По-моему, как-то вот так…
Да вот пример из собственной практики, в гошном stdlib-е:
https://habr.com/ru/articles/906796/
С точки зрения санитайзера (race detector-а), там всё было хорошо.
Ну допустим, под тред саном проблема не воспроизводится. И тред сан не находит, к чему придраться.
Что дальше будем делать?
Даже и без конских штрафов вы такое не продадите. Люди привыкли получать такие вещи бесплатно. Точно так же, как вы не заработаете денег на опенсорсном проекте, которым пользуется миллион человек.
Придумывая бизнес, не надо забывать культурный контекст.
Неужели у вас нет кранов на батареях?