По вашей ссылкам там некоторые ссылки, что не используют они, а просто есть биндинги на kotlin для их продуктов))) Как вы всех Android разработчиков или приложения посчитали?)
По мнению Джеймса Стрэчена[en], создателя языка программирования Groovy, Scala может стать преемником языка Java[5].
Стрэчен покинул проект за год до релиза Groovy 1.0 в 2007 году, а в июле 2009 года Стрэчен написал в своём блоге, что возможно не создал бы Groovy, если бы в 2003 году прочитал книгу Мартина Одерского с соавторами о программировании на языке Scala (вышедшую в 2007 году)[3].
Что такое развесистая JAVA-кодобаза? Electron используют по причине удобного рендеринга, движок chromium настолько оптимизирован, что даже не все десктоп приложения так быстро могут рендериться, плюс легкий вход css + js. Все же по мне JAVA отстает в плане графики. И при наличии jetbrains ide все же в некоторых проектах предпочитают VS Code, она шустрая, быстро запускается и самое главное есть интеграция с некоторыми тулчайнами, с которыми нет у jetrains.
Сомневаюсь, что то так с ходу даже не вспомню какой нибудь крупный и известный проект на kotlin, кроме их IDE. И как правильно выше написали, тому причина проприетарность. Не изучал лицензию, но думаю, там тоже не все гладко для разработчиков.
DenisB12 JAVA в топе популярных языков последние 20 лет. Очень много бизнес софта на нем написано. И все это было далеко до kotlin. Язык изначально был с хорошей выразительностью, и быстрой обучаемостью. Синтаксический сахар до контлина еще был в C#.
Это изначально был мертворожденный ребенок… Честно говоря, он мне напоминает просто клон scala. Зачем нужен kotlin если есть scala? Не нравится в kotlin, что он некоторые вещи решает за программиста, что убавляет гибкости. В методах тип пишется справа, и еще добавляется двоеточие… Проблема многих языков это лишний символы, которые надо печатать, например begin end вместо {}, и присвоение переменной через <= или +=, $ перед переменной(в шаблонах это нормально), даже с автодополнением на это тратиться много времени. В контлин добавили сокращения, это прям плюс по сравнению с JAVA. Проблема многих языков многобукв! В котлин все убило лишнее двоеточие, и тип переменной справа… Тут у меня сразу вспоминается дико не удобный objective c, с которым Apple хотела поменять отношение к программированию, все закончилось тем что программистов не прибавлялось, и выпустили swift… Лучше синтаксиса С и JAVA нет, они хорошо читаются и хорошо соотносятся с математической логикой, не хватает синтаксического сахара как в C# и dart, например вместо extends просто :. Но как правильно написано JAVA развивается. Скорее всего котлин был выплюнут на рынок в связи с судебной баталией Оракла и Гугла по поводу JAVA, и нужна была альтернатива для Android. Но гугл создал свой язык dart, который имеет хорошую читаемость, гибкость и синтаксический сахар! Большим зло считаю как раз то, что типа справа, человека учат математике и тип всегда слева, и переменной значение присваивают через знак =, извращения на этом пути ни к чему хорошему не приведут. Конечно за это решение можно сказать один плюс, все нестандартное развивает нейроны. Еще проблема kotlin, что они не создали свою виртуальную машину, а просто сделали транслятор в байткод JVM. Язык надо было создавать с нуля со всей стандартной библиотекой. За 25 лет программирования, так и не увидел язык, который был мог переплюнуть своей выразительностью C, C++, JAVA, Python поэтому они и занимают ведущие позиции. И многие языки, которые якобы решают их проблемы, на самом деле добавляют кучу своих…
dlinyj мне лично быстрее ввести формулу, чем вставить и залить картинку. Формулы в основном пишут в LaTeX формате, katext и mathjax это лишь библиотеки для рендеринга LaTeX формул. На 4к мониторе, картинки довольно блеклые и смазанные, что снижает комфорт от чтения. Помню, что вроде можно было формулы добавлять на habr, поэтому уточнил. Вы подтвердили, что можно нормально добавить формулы.
Scinolim если повышающая схема на умножителе, то стабилизируют линейными регуляторами низковольтное напряжение, и на выходе по желанию ставят RC фильтр. Способов много, все решают эту не тривиальную задачу по разному.
Пожалуйста www.hamamatsu.com/eu/en/product/type/R6233/index.html
По SiPM можете к примеру на mouser посмотреть их временные характеристики.
Вот график нашел по быстрому, был еще график другой, там поменьше были значения. Для счета там не обязательно высокая скорость счета для классических NaJ(TI) и CsJ(TI), а вот для спектрометрии надо захватить верхушку. Как решение проблемы, это преобразовывать сигнал в меандр, и растянуть по времени. Самые быстрые сцинтилляторы пластиковые, выше по сообщениям сможете найти даташиты. Поэтому выше был совет использовать NaJ(TI) или CsJ(TI), у них временные характеристики не такие агрессивные.
Neuromantix да, от стабильности напряжения очень будут зависить показания АЦП. Да и на дешевых микроконтроллерах АЦП любят плыть, тому простой пример всякие китай LCR измерители, там люди ради получения хотя бы чуть адекватных значения пытаются ставить кварцевые генераторы получше, но все равно ENOB там тухлый.
Вредный совет со строчником, смотря какая ФЭУ у hamamatsu там до 1200в, как знаю люди их запускают уже на 700в, видимо это снижает скорость счета, чтобы удобнее захватить с помощью АЦП звуковухи. Вообще там потребление очень маленькое(темновые токи там в нА исчисляются) и достаточно безопасного источника в пару мА, ток ограничивают, чтобы не убило. Про это тут на хабре уже писал Максим Madmax. Там еще в зависимости от ФЭУ надо подавать с положительной или отрицательной полярностью.
У популярной Hamamatsu R6233
[Time Response] Rise Time Typ. 9.5 ns
[Time Response] Transit Time Typ. 52 ns
А у лучших SiPM там несколько сотен пикосенд.
Микросекунд не будет там. Есть научная статья по созданию гамма спектрометра на основе АЦП звуковой карты, ФЭУ и кристалла NaJ(TI), все эту схему в общем копируют, там в статье же есть сравнение с нормальным решением, в общем захватывает это решение только около 10% всех частиц. Все больше зависит от временной характеристики сцинтиллятора, поэтому быстрые сцинтилляторы требуют более быстрого счета.
Потребность науки в быстрых SiPM и сцинтилляторах востребована, для лучшего изучения происходящих процессов. В случае спектрометрии можно устать пару часов делать анализ низкоактивных источников — например продуктов питания.
Все можно сделать в KDE кроме sudoers. У меня нет убунты, и не знаю функционала их оболочки, но вот в KDE это все довольно легко настраивается. В статье нет ничего такого, что нельзя сделать в графической оболочке, у меня лично к примеру настройки на сетевой интерфейс ставятся через shell скрипт, который из udev запускается, вот такое точно не сделать без консоли. iptables являются устаревшими, и везде рекомендуют переходить на nftables. Статью надо было назвать настройка убунты для чайников.
Альфу бету он точно не ловит, они не пройдут через корпус, а вот рентген может, с учетом того, что в помещениях все же пролетаю разные частицы в небольшом количестве, то скорее всего детектор ловит их, а не мюоны. Как помню мюоны детектируют высоко в горах, чтобы внешний фон не влиял на детектор. У меня дома примерно с такой же скоростью детектирует гамма частицы обычный дозиметр при фоне 16мкР/ч. Там еще проблема всей конструкции, что такой маленький SiPM на крупный кусок пластикового сцинтиллятора, там рабочая поверхность будет довольно маленькая, и имхо сколько показывает лампочка на детекторе в принципе столько мюонов им не поймать. Если бы в статье был обычный ФЭУ с большим окном, то сомнений у меня не было. На самом деле дешевле поиграться можно с фотодиодами, и даже сделать альфа спектрометр на них. SiPM имеет смысл с быстрыми сцинтилляторами с хорошим выходом, например LaBr3, LYSO, там маленьким кристаллом можно быстро много наловить. Вас не минусовал.
По мнению исследователя, проблема этого драйвера в том, что в его коде используется «очень слабый 32-битный хеш — например, CRC или XOR»
Это не проблема. Чем сложнее хэш тем больше процессорного времени тратится, если процессов будет много, то на хеширование может уйти не мало времени, и если драйвер будет жрать процессор как в не себя, то это не здоровая ситуация, к примеру на моем ryzen9 и c очень быстрой файловой системой, хеширование sha512 для файла около 70мб занимает 0.1с. 10 программ, уже создаст заметный лаг в 1с. Инсталятор в 350мб, уже хешируется 0.45с с помощью sha512. Думаю код драйвера стоит как обработчик прерывания, что в свою очередь может сказаться на обработке других прерываний, и тут важна скорость, и даже минимальная задержка будет снижать производительность всей системы. Еще не понятно сканируется только родительский процесс или все дочерние? Если все дочерние, то это уже будет реально заметный лаг на некоторых приложениях.
Bright_Translate просто изучал тему, читал литературу, хочу построить свой гамма спектрометр для проверки продуктов, только сделанного более по уму, чем большинство решений. Но вот никак руки не доходят реализовать. На самом деле в теме не так хорошо разбираюсь, как например ученные, чисто как технический специалист.
По SiPM можете к примеру на mouser посмотреть их временные характеристики.
Вот график нашел по быстрому, был еще график другой, там поменьше были значения. Для счета там не обязательно высокая скорость счета для классических NaJ(TI) и CsJ(TI), а вот для спектрометрии надо захватить верхушку. Как решение проблемы, это преобразовывать сигнал в меандр, и растянуть по времени. Самые быстрые сцинтилляторы пластиковые, выше по сообщениям сможете найти даташиты. Поэтому выше был совет использовать NaJ(TI) или CsJ(TI), у них временные характеристики не такие агрессивные.
[Time Response] Rise Time Typ. 9.5 ns
[Time Response] Transit Time Typ. 52 ns
А у лучших SiPM там несколько сотен пикосенд.
Микросекунд не будет там. Есть научная статья по созданию гамма спектрометра на основе АЦП звуковой карты, ФЭУ и кристалла NaJ(TI), все эту схему в общем копируют, там в статье же есть сравнение с нормальным решением, в общем захватывает это решение только около 10% всех частиц. Все больше зависит от временной характеристики сцинтиллятора, поэтому быстрые сцинтилляторы требуют более быстрого счета.
Потребность науки в быстрых SiPM и сцинтилляторах востребована, для лучшего изучения происходящих процессов. В случае спектрометрии можно устать пару часов делать анализ низкоактивных источников — например продуктов питания.
www.crystals.saint-gobain.com/sites/imdf.crystals.com//files/documents/bc400-404-408-412-416-data-sheet.pdf
Который использовали в статье, у него чувствительность к рентгену, альфе, бета, и космическим лучам, мюонам.
В этом даташите написано, что ловит еще нейтроны.
www.phys.ufl.edu/courses/phy4803L/group_I/muon/bicron_bc400-416.pdf
Альфу бету он точно не ловит, они не пройдут через корпус, а вот рентген может, с учетом того, что в помещениях все же пролетаю разные частицы в небольшом количестве, то скорее всего детектор ловит их, а не мюоны. Как помню мюоны детектируют высоко в горах, чтобы внешний фон не влиял на детектор. У меня дома примерно с такой же скоростью детектирует гамма частицы обычный дозиметр при фоне 16мкР/ч. Там еще проблема всей конструкции, что такой маленький SiPM на крупный кусок пластикового сцинтиллятора, там рабочая поверхность будет довольно маленькая, и имхо сколько показывает лампочка на детекторе в принципе столько мюонов им не поймать. Если бы в статье был обычный ФЭУ с большим окном, то сомнений у меня не было. На самом деле дешевле поиграться можно с фотодиодами, и даже сделать альфа спектрометр на них. SiPM имеет смысл с быстрыми сцинтилляторами с хорошим выходом, например LaBr3, LYSO, там маленьким кристаллом можно быстро много наловить. Вас не минусовал.
Это не проблема. Чем сложнее хэш тем больше процессорного времени тратится, если процессов будет много, то на хеширование может уйти не мало времени, и если драйвер будет жрать процессор как в не себя, то это не здоровая ситуация, к примеру на моем ryzen9 и c очень быстрой файловой системой, хеширование sha512 для файла около 70мб занимает 0.1с. 10 программ, уже создаст заметный лаг в 1с. Инсталятор в 350мб, уже хешируется 0.45с с помощью sha512. Думаю код драйвера стоит как обработчик прерывания, что в свою очередь может сказаться на обработке других прерываний, и тут важна скорость, и даже минимальная задержка будет снижать производительность всей системы. Еще не понятно сканируется только родительский процесс или все дочерние? Если все дочерние, то это уже будет реально заметный лаг на некоторых приложениях.