Знакомая силиконовая оптическая смазка. Это все хорошо, но из статьи так не понял какие частицы мы будем ловить? Во вторых на фото пластиковый сцинтиллятор от бикрон, и видимо с чувствительностью к нейтронам, если посмотреть временные характеристики его, то там очень короткое время послесвечения, и чтобы хотя бы нормально считать, скорость счета нужна не менее 1Ггц! Обычные ЦАП будут мимо кассы пропускать большое количество частиц, если нам просто считать без фиксации энергии, то лучше делать высокоскоростной счетчик, а не цап, проще схема. ЦАП понадобится дорогой и скоростной, и еще нужен будет FPGA для него. Если говорить про фиксацию гамма излучения, то там сцинтилляторы более медленные у натрий йод активированного талием, как помню 40нс, а у цезий йод активированного талием 200нс, а у бромида ланта LaBr3(Ce) чуть больше чем у пластиковых. Пластик не подход для спектрометрии, только для счета.
Еще есть самая главная характеристики у SiPM(полупроводникового ФЭУ, да и у любого ФЭУ) это рабочая частота света к которой он более чувствителен. У On Semi это ближе к красному свету, у Broadcom(их использует cern, и видимо в паре с LaBr3) это ближний ультрафиолет. Так же у сцинтиллятора есть частота света в которой они излучают, у LaBr3 это фиолетовый-ближний ультрафиолет, NaJ синий-фиолетовый, CsJ это желто-красный, у пластика не помню. Главный недостаток SiPM они уходят довольно быстро в насыщение, поэтому для маломальски нормального устройства их надо несколько, что стоит очень дорого, иначе мы очень сильно ограничены в пределах измеряемых значений. Вместе с быстрым пластиком, быстрым SiPM и медленным цап от микроконтроллера, на выходе будет лажа и SiPM будет уходить в насыщение. Для начала лучше делать на классическом ФЭУ и NaJ(TI), это проще и дешевле, и можно сделать дешево гамма спектрометр, правда с низкой скоростью счета. Главное не описан в статье принцип работы, и нет схемы… Статья не раскрывает тему совсем. Самое главное это просто игрушка, для изучения частиц подходит мало.
Честно говоря уже не помню, что там используют для покрытия контактов, желтое покрытие контактов вроде было какое-то соединение титана, еще вроде никелем покрывают. Просто помню, что нитрид титана желтого цвета, и довольно прочный.
obenjiro он подходит для всего, да основная причина это возможность трассировки бэкенда в продакшене, а к этому приходят многие, так как бэкенд на nodejs не редко работает медленно и перестает справляться с нагрузками. Для фронтенда гугл профайлер.
Как все запущено. Белый список IP и правило по умолчанию блокировать все — решает все проблемы. Если вас захотят ддосить, то найдут кучу способов, и смена порта не поможет. Второй вопрос уверены ли в боте, и что будет если он упадет… Не надо придумывать себе проблемы на ровном месте. Все давно уже решено за вас.
Какой же вы батенька извращенец, нормальные люди, компании уже давно перешли к авторизации по сертификату. Просто запрещаете авторизацию по SSH руту и по паролю. Cоздаете обычного пользователя и делаете авторизацию по сертификату.
Дальше в конфиге SSH сервера:
А я бы не советовал блокировать IPv6. На моем роутере ни одной атаки по IPv6 не было за много лет, а по IPv4 часто что-то да приплывает. Миф про опасность IPv6 раздут просто на ровном месте людьми не понимающими принцип его работы. Начнем с того, что IETF(инженерный совет интернета) рекомендует провайдерам выделять для физических лиц префиксы размерностью не менее /56, для юрлиц /48, мой провайдер не дает столько, но дает /64. А теперь посчитайте сколько это адресов, и как долго вы их будете сканировать. Если не можете посчитать сами, найдите калькулятор в интернете. IPv6 разрабатывался с учетом безопасности и учитывает все проблемы IPv4. В IPv6 к примеру кроме основного IPv6 адреса, есть временный IPv6, который меняется с определенной периодичностью(благо /56 нам позволить это делать всю жизнь и даже останется), так вот все исходящие соединения только по этому временному IPv6 и сервера видят только его, определить по нему основной нереально. Ну и файервол и белый список IP никто не отменял… Зато IPv6 имеет более низкие накладные расходы, лучше скорости, задержки и не нужен NAT. Мой домашний Linux компьютер все качает в основном по IPv6, все обновления системы с IPv6 зеркал.
Все решается проще, создается просто белый список IP для SSH, и правило по умолчанию DENY (BLOCK, DROP) для всего, при желании можно логировать тех кто попал в DENY(BLOCK, DROP). fail2ban тут совсем не нужен, у меня на серверах всегда правило по умолчанию DENY(BLOCK, DROP).
third112 про золото не совсем правильно, до сих пор у советского человека есть стереотип золото — значит качественно. Нормальные разъемы в большинстве покрываются специальными соединениями, например нитрид титана, хоть он прочный но все равно стачивается от втыкания. Золото само по себе довольно мягкий металл и долго на контактах не продержится, а серебро окисляется, поэтому если они есть, то в небольшом количестве. Золото в микросхемах чисто из-за инертности и его можно нанести удобным способом тонким слоем, и тонкие волоски довольно гибкие и прочные. Основная проблема USB не разъемы, а кабеля, если говорить про принцип работы USB, то это обычные цифровые дифференциальные линии, которые для эффективной работы нужно выравнивать по длине или задержке, второй метод более правильный, так как от формы проводника и его пути прохождения задержка будет отличаться. Если линии выровнены плохо, то падает скорость, и высокоскоростные линии сильнее подвержены ЭМ влиянию. В идеале не только пары должны быть выровнены, но так же вся группа. Тут для примера можно привести UTP кабель, чем выше категория, тем лучше кабель экранирован и сами пары так же экранированы, и самое главное используется более сложное и плотное плетение проводов дифференциальной пары. Поэтому основная проблема это не качественные китай кабеля, скажу даже больше чаще всего разъемы практически не окисляются, а тупо контакты разъема отпаиваются от платы от нагрузок и расшатывания разъема. Высокоскоростные и ВЧ схемы довольно сложная тема и факторов там очень много, в первую очередь влияет форма проводника и его реактивное сопротивление на рабочей частоте.
Boomburum основная проблема хабра не только сетка ботов, но еще тотальная безграмотность основной массы людей на ресурсе и отсюда прессинг habr.com/ru/company/ruvds/blog/556168
Если в самом начале создания хабра статьи были хорошие и действительно помогали разобраться в каком-то сложно вопросе, то сейчас все скатилось к желтушным газетным статьям авторов которых даже не разбираются в базовых вещах или как припаять два светодиода к ардуино. Стоит заметить желтушные статьи на ресурс имеют большую популярность, чем какие-то полезные технические. В интернете есть реально не мало хороших статей на английском, а не ересь которую перепечатывают от непонятного автора. Проблема RU_VDS что публикует статьи человек совсем не практикующий, отсюда «иссякли идеи». Современные технологии плохо освещены, а если освещены совсем поверхностно и даже хуже чем в официальной документации Get Started, никто к примеру не объясняет разные сложные процессы и как они работают, например какие-то функции ядра Linux, разные алгоритмы т.д. Да банально перевод некоторой документации будет значительно полезнее желтушных статей… А еще меня «радуют» статьи про деградацию, которые набираю популярность, когда недо программист пишет, что его хорошего «программиста» заставили решили задачки, дали задания на знания алгоритмов, и не объективно оценивают знания при трудоустройстве на должность senior разработчика с окладом в 200 тыс.рублей в крупной компании, или про программного архитектора, которые на собеседование заявлет, что code review не будет заниматься и удивляется почему его не приняли, ага, представьте патологоанатома или хирурга, который устраивается в больницу, и заявлет вскрытие делать не буду, но заключения или диагноз напишу.
1. Это имел ввиду. Да размерность если известна. Но тут локальная переменная и смысл ссылочный тип держать нет. Я вначале тоже использовал указатель и new, но мне мейнтенейры в разных проектах сказали, что это не правильно. Плюс дисассемблирование показывает, что в случае с массивом ASM листинг короче и чуть быстрее. Я переписал код, и сделал нормальный бенчмарк для проверки.
2. Все правильно. Про кеш тоже согласен. Плюс еще есть предсказатель переходов и т.д., факторов много влияет на скорость. Тема сложная и мало кто в ней хорошо плавает. Просто изначально всегда обучали и делали акцент на стеке, что это кэш память, а куча более медленная. Плюс у нас все же несколько видов кеша в процессорах.
3. Так и есть. Написал выше «может», поведение зависит от контекста, поэтому использовать просто массив выгоднее чем указатель на массив.
Hes дело не только в комментариях, в php не любят обрабатывать исключения. В нормальных языках это основа из основ, где-то даже не даст скомпилировать пока исключение не обработаешь. На лицо в скрипте отсутствие обработки исключений. Кто программирует на нормальном языке пытается всегда обработать исключения.
Судя по вашему ответу вы мебель в иномарке кабриолете возите… А мешок картошки только складываете в багажник мерседеса… Это называется «Вася не учился в автошколе, но купил себе феррари и разбился...» Про скоростной режим в дождь ничего не слышали? Чем лучше пилить дерево бензопилой или лобзиком?
В языках программирования, на которых мне приходилось писать, везде есть UB. Глубоко сомневаюсь, что UB нет в haskell и там нельзя выстрелить себе в ногу.
В случае с bash тут безграмотность на лицо и не знание техники безопасности, обработки исключений, и правильного написания кода.
Простой пример, вы взяли бензопилу спилить дерево, не зная техники безопасности и правил работы с бензопилой приступили к работе, в итоге бензопила отскочила и отрезала вам ногу, или дерево упало вам на голову. Кто виноват Бензопила!??? Дерево!??? Вы сами? Значит ли это, что бензопила плохая и не безопасная? Подходит ли бензопила выкручивать шурупы? А можете ли вы спилить дерево отверткой?
sergio_nsk человек про потенциальные проблемы написал, ниже вам правильно ответили.
По коду сразу понятно, что человек просто не владеет shell скриптом и программирует на другом языке, так не делают люди, которые пишут хорошо скрипты и майтейнерят крупные сервера, программы, и линукс дистрибутивы. Уже не однократно писал на хабре про обработку исключений в shell скриптах, как обычно в скрипте их, отсюда куча проблем. Почему-то в нормальных языках исключения обрабатывают, а в shell про них просто забывают. В shell немного другая логика чем в привычных языках программирования, некоторые вещи с виду и без опыта делаются не удобно и не стоит шуроповертом пытаться забивать гвозди, у bash только одна основная функция автоматизация выполнения команд, куда еще для удобства входят конвеерное выполнение команд и потоковое редактирование. Когда говорят про безопасность bash это такая же ересь, как к примеру сказать, что на R нельзя написать десктоп приложения и синтаксис его не удобен и поэтому язык плохой, там нет безопасности, и он не создан вообще для сложных приложений. Shell скрипт так же как R заточен строго под свои функции и синтаксис их для этого создан. Вы когда нибудь программировали на R?
Еще есть самая главная характеристики у SiPM(полупроводникового ФЭУ, да и у любого ФЭУ) это рабочая частота света к которой он более чувствителен. У On Semi это ближе к красному свету, у Broadcom(их использует cern, и видимо в паре с LaBr3) это ближний ультрафиолет. Так же у сцинтиллятора есть частота света в которой они излучают, у LaBr3 это фиолетовый-ближний ультрафиолет, NaJ синий-фиолетовый, CsJ это желто-красный, у пластика не помню. Главный недостаток SiPM они уходят довольно быстро в насыщение, поэтому для маломальски нормального устройства их надо несколько, что стоит очень дорого, иначе мы очень сильно ограничены в пределах измеряемых значений. Вместе с быстрым пластиком, быстрым SiPM и медленным цап от микроконтроллера, на выходе будет лажа и SiPM будет уходить в насыщение. Для начала лучше делать на классическом ФЭУ и NaJ(TI), это проще и дешевле, и можно сделать дешево гамма спектрометр, правда с низкой скоростью счета. Главное не описан в статье принцип работы, и нет схемы… Статья не раскрывает тему совсем. Самое главное это просто игрушка, для изучения частиц подходит мало.
Дальше в конфиге SSH сервера:
Если в самом начале создания хабра статьи были хорошие и действительно помогали разобраться в каком-то сложно вопросе, то сейчас все скатилось к желтушным газетным статьям авторов которых даже не разбираются в базовых вещах или как припаять два светодиода к ардуино. Стоит заметить желтушные статьи на ресурс имеют большую популярность, чем какие-то полезные технические. В интернете есть реально не мало хороших статей на английском, а не ересь которую перепечатывают от непонятного автора. Проблема RU_VDS что публикует статьи человек совсем не практикующий, отсюда «иссякли идеи». Современные технологии плохо освещены, а если освещены совсем поверхностно и даже хуже чем в официальной документации Get Started, никто к примеру не объясняет разные сложные процессы и как они работают, например какие-то функции ядра Linux, разные алгоритмы т.д. Да банально перевод некоторой документации будет значительно полезнее желтушных статей… А еще меня «радуют» статьи про деградацию, которые набираю популярность, когда недо программист пишет, что его хорошего «программиста» заставили решили задачки, дали задания на знания алгоритмов, и не объективно оценивают знания при трудоустройстве на должность senior разработчика с окладом в 200 тыс.рублей в крупной компании, или про программного архитектора, которые на собеседование заявлет, что code review не будет заниматься и удивляется почему его не приняли, ага, представьте патологоанатома или хирурга, который устраивается в больницу, и заявлет вскрытие делать не буду, но заключения или диагноз напишу.
2. Все правильно. Про кеш тоже согласен. Плюс еще есть предсказатель переходов и т.д., факторов много влияет на скорость. Тема сложная и мало кто в ней хорошо плавает. Просто изначально всегда обучали и делали акцент на стеке, что это кэш память, а куча более медленная. Плюс у нас все же несколько видов кеша в процессорах.
3. Так и есть. Написал выше «может», поведение зависит от контекста, поэтому использовать просто массив выгоднее чем указатель на массив.
В случае с bash тут безграмотность на лицо и не знание техники безопасности, обработки исключений, и правильного написания кода.
Простой пример, вы взяли бензопилу спилить дерево, не зная техники безопасности и правил работы с бензопилой приступили к работе, в итоге бензопила отскочила и отрезала вам ногу, или дерево упало вам на голову. Кто виноват Бензопила!??? Дерево!??? Вы сами? Значит ли это, что бензопила плохая и не безопасная? Подходит ли бензопила выкручивать шурупы? А можете ли вы спилить дерево отверткой?
По коду сразу понятно, что человек просто не владеет shell скриптом и программирует на другом языке, так не делают люди, которые пишут хорошо скрипты и майтейнерят крупные сервера, программы, и линукс дистрибутивы. Уже не однократно писал на хабре про обработку исключений в shell скриптах, как обычно в скрипте их, отсюда куча проблем. Почему-то в нормальных языках исключения обрабатывают, а в shell про них просто забывают. В shell немного другая логика чем в привычных языках программирования, некоторые вещи с виду и без опыта делаются не удобно и не стоит шуроповертом пытаться забивать гвозди, у bash только одна основная функция автоматизация выполнения команд, куда еще для удобства входят конвеерное выполнение команд и потоковое редактирование. Когда говорят про безопасность bash это такая же ересь, как к примеру сказать, что на R нельзя написать десктоп приложения и синтаксис его не удобен и поэтому язык плохой, там нет безопасности, и он не создан вообще для сложных приложений. Shell скрипт так же как R заточен строго под свои функции и синтаксис их для этого создан. Вы когда нибудь программировали на R?
Вот примерно как делается правильно: