Там написано, что посылать MIDI и определяться, как MIDI контроллер он может не только по USB, но еще и про WiFi через WebSocket или через BLE. Про прием ничего не написано.
Перегнали. По крайней мере на AliExpress. Если на Arduino Nano минимальная цена сейчас от 210 рублей с доставкой, то ESP32-C3 SuperMini можно купить за 190 рублей с доставкой. Ну а сравнивать их по возможностям бессмысленно.
Для тех случаев, когда действительно нужен восьмибитный МК, лучше ориентироваться на существенно более дешевый Padauk. Например, даже в Чип и Дип можно купить PFS154-S08 по 20 рублей, а PFS154-S16 по 53 рубля. Про OTP вообще молчу, там же PMS150C-U06 по 11 рублей.
К тому, что у MySQL (текущей LTS версии - 8.4) всего 0 подтвержденных багов. Просто задайте правильный фильтр.
Ну если по-вашему правильный фильтр - это исключить тысячи до сих пор неисправленных багов в предыдущих версиях, то я не понимаю, о чем можно дальше дискутировать.
Вы анализировали багтрекер mysql? Можете поделиться статистикой сколько подтвержденных багов не закрыто?
Самому что-ли влом посмотреть? Сейчас активных (Open+Verified) 11374. Закрыто в 9.1 - чуть больше сотни. Но к чему это?
Не думаете, что если мало исправлений, то это значит что мало багов?
Как разработчик с тридцатилетним стажем, занимавшийся разработкой весьма крупных и разных проектов, я в это не поверю. Мало багов может быть только в проекте, который вообще не развивается, но хорошо поддерживается.
Речь о том, что в MySQL фич сейчас за год появляется десяток-полтора. Тогда как в PostgreSQL только в одном commitfest, даже не в релизе, их коммитится по полсотни - свыше двух сотен за год.
Почему Вы упорно занимаетесь демагогией, подменяя тему?
Я что писал?
В сравнении даже с одним commitfest PostgreSQL
При чем тут вообще релизы?
Их много, но о чем это говорит? О наличии горы багов, которые исправляют.
В первую очередь, это говорит о том, количество багов, которые неизбежны в любом программном продукте, активно уменьшается. И чем больше я вижу коммитов с исправление багов в проекте, тем значит меньше он их содержит. И наоборот, если в проекте баги исправляются редко, то значит их там действительно горы.
Вот например в 17 версию не дотащили поддержку uuid v7
Все претензии к Бордину, который выдал последний патч только вчера
Одно дело, впихнуть UUIDv7 где-то сбоку. Сбоку он и так есть. А совсем другое дело - в ядро. Там целая Санта-Барбара получилась.
Тут. Естественно речь идет о КПД ДВС в гибридном автомобиле.
Mercedes еще в 2017 представил двигатель с КПД 43%
Возможность нормально реализовать мощность на самых эффективных оборотах дадут, пожалуй, только электропередача, гидропередача и вариатор.
Для легковых автомобилей, всё же более перспективна гибридная силовая установка с электроприводом.
Помимо этого, много энергии просто "вылетает" в выхлопную трубу.
Это как? Я на своей L200 спокойно могу взяться рукой за выхлопную трубу при заведенном двигателе. Ну да, теплая. Но далеко не горячая.
На той же Тесла жидкостная система охлаждения электродвигателей и АКБ. Объем заливаемого антифриза 15 литров. И, естественно, радиатор, ничуть не уступающий в размерах моему. Так что я, уподобляясь Вам, тоже могу сказать, что на электромобилях тоже "много энергии просто "вылетает" в окружающую среду" )))
Навряд-ли даже с печкой удастся выжать с бензинового двигателя более 50-60% КПД.
Исходя из того, что некоторые дизельные автомобили оборудуются дополнительными обогревателями салона, в холодное время года тепла от двигателя, наоборот, не хватает для обогрева. Например, L200 при -30 за бортом, хоть час её прогревай, но больше +10 градусов в салоне не будет, пока не включишь рециркуляцию.
Ну ладно, пусть даже 50-60% КПД. Но если энергия соляры какая была на НПЗ, такой остается и в топливном баке, то с электроэнергией всё не так просто. Например, КПД ГАЭС не 70-75%. Потери в ЛЭП до ГАЭС и от неё - еще 5-10%, КПД зарядного устройства 95%, АКБ - 90-95%, электродвигателя - 95%. Что там получилось? Потери по минимуму 25+5+5+5+5=45%. И вышли на тоже самое, даже считая, что вся энергия для ночной зарядки электромобилей вырабатывается солнечными батареями и накапливается на ГАЭС.
Лично мне кажется более привлекательными воздушно-алюминиевые батареи. Во-первых, высокая емкость, позволяющая проехать до 2 тыс. км. Во-вторых, алюминиевые аноды при транспортировке и хранении энергию не теряют. В-третьих, технологически замену алюминиевых анодов можно производить за время даже меньшее, чем тратится сейчас на заправку на АЗС. Да, есть ряд нерешенных проблем, но перспективы выглядят действительно заманчиво. И зеленая энергетика оказывается при деле, поставляя энергию на производство алюминиевых анодов, которые хранить можно десятилетиями.
Не понял о чем Вы. Периодичность commitfest PostgreSQL - 2-3 месяца. И в каждом видим порядка сотни коммитов. Ну пусть даже треть - багфиксы. Все равно получается свыше полусотни фич каждые 2-3 месяца.
Собственно говоря, именно из-за подобных соображений я и решил, что мониторинг мощности сигнала WiFi (RSSI) дает более адекватный результат, чем геопозиционирование. В моем случае, при -90 точка доступа уже устойчиво детектируется, а на парковке во дворе, так как WiFi уличный в LTE модеме на столбе, RSSI может оказаться даже нулевым.
Ну так детская нога вполне в эти пять сантиметров может пролезть. Пальцы могут и в сантиметр пролезть.
А в описываемом мной случае был забор из профнастила. Столбы 60х60. Итого между столбом и воротами 40-50, а между профнастилом и воротами - уже 100-110. А с той стороны укосина ворот под 45 градусов. И ребенка, как ножом, могло покалечить или убить, зажав между этой укосиной и столбом.
К сожалению, это не так. Знаю случай, когда ребенок не стал инвалидом только благодаря тому, что успели вовремя остановить открывающиеся ворота. Его к тому времени уже зажало между забором и каркасом ворот. Еще немного, и между забором и воротами оказалась бы не только нога, но и голова.
Тут спасёт, разве что, установка заграждения, не позволяющего детям попасть в зону сдвига ворот вдоль забора при их открывании.
Проблема не в том, что JS изначально был интерпретатором. Это как раз решаемо, так как компилировать можно и на лету. Причем не только кешируя результат, но еще и оптимизируя его в зависимости от профиля нагрузки.
Проблема производительности JS в динамической типизации и сборке мусора. Первое в любом случае приводит к дополнительной нагрузке на процессор и память при исполнении кода. А второе может приводить к непредсказуемым задержкам в неподходящий момент времени и/или к излишнему потреблению памяти.
Так как кеш CPU не резиновый, то бОльшее потребление памяти напрямую влияет на производительность.
Вторая проблема JS, которая органически вытекает из всего перечисленного выше - это необходимость в собственной среде выполнения. Иными словами, если код на том же Rust может почти из издержек многократно вызываться из любой среды, хоть из драйвера в ядре, то код на JS так просто не вызвать из-за необходимости инициализации среды. И это заметно сужает область его применения.
Если уж говорить о юридическом аспекте, то любым действиям должно предшествовать утверждение документа. В данном случае, локального подзаконного акта со ссылками уже на законы, их статьи, пункты и абзацы. Где он?
Похоже себе делаю (еще в прототипе), но на ESP32-C3 и только на открытие при подъезде к участку, контролируя уровень сигнала WiFi. Если при регистрации он сильный, значит машина на участке и подавать сигнал открытия ворот не надо. Если слабый, то значит только подъезжаем и нужно открыть ворота.
А вот при выезде с участка пользуюсь штатным брелком. Потому что с момента, как я сяду за руль до момента, когда я уже выезжаю, нередко, ворота просто не успевают открыться. С другой стороны, неудобно пользоваться брелком, когда за рулем в движении. А когда только садишься в машину - это не напрягает.
Автозакрытие по фотодатчику стоит на полторы минуты. Этого с лихвой хватает для въезда, даже если пес выбегает встречать машину через ворота сразу после их открытия.
Btree и hash решают несколько разные задачи. Для поиска только по равенству, само собой, hash эффективней. Но, для примера, в PostgreSQL hash индексы применяются не часто. По той простой причине, что на практике в выборках нужны сравнения не только по равенству, но и > или <. И тут hash не поможет, в отличии от Btree. Так что, если упорядоченность не нужна - применяем hash. Но если нужна - Btree.
Среднего размера прошивка для ESP32 - 2-3 мегабайта. Как представил её заливку звуком - ужаснулся.
Если вспомнить, что I2C обязателен в составе PCIe, то бишь, используется для коммуникации между PCB, то тут явно погорячились
SSRS, а не MSRS
Там написано, что посылать MIDI и определяться, как MIDI контроллер он может не только по USB, но еще и про WiFi через WebSocket или через BLE. Про прием ничего не написано.
Принимать MIDI проще. Например.
Например, ESP32
У него еще и I2S имеется.
Перегнали. По крайней мере на AliExpress. Если на Arduino Nano минимальная цена сейчас от 210 рублей с доставкой, то ESP32-C3 SuperMini можно купить за 190 рублей с доставкой. Ну а сравнивать их по возможностям бессмысленно.
Для тех случаев, когда действительно нужен восьмибитный МК, лучше ориентироваться на существенно более дешевый Padauk. Например, даже в Чип и Дип можно купить PFS154-S08 по 20 рублей, а PFS154-S16 по 53 рубля. Про OTP вообще молчу, там же PMS150C-U06 по 11 рублей.
А перейти по ссылке, увидеть все значения фильтра в URL и убедиться, что в том числе и строк с "MySQL Server: *" там полно гордость не позволяет?
Я просто не стал фильтровать по категории, вполне обосновано полагая, что фильтр будет по тупому совпадению, а не по префиксу. И оказался прав.
Потому что они должны быть либо закрыты, если исправлены в следующих версиях, либо остаются в них.
Ну если по-вашему правильный фильтр - это исключить тысячи до сих пор неисправленных багов в предыдущих версиях, то я не понимаю, о чем можно дальше дискутировать.
Хотя даже тут солгали
Самому что-ли влом посмотреть? Сейчас активных (Open+Verified) 11374. Закрыто в 9.1 - чуть больше сотни. Но к чему это?
Как разработчик с тридцатилетним стажем, занимавшийся разработкой весьма крупных и разных проектов, я в это не поверю. Мало багов может быть только в проекте, который вообще не развивается, но хорошо поддерживается.
Еще раз, при чем тут циклы выпуска релизов?
Речь о том, что в MySQL фич сейчас за год появляется десяток-полтора. Тогда как в PostgreSQL только в одном commitfest, даже не в релизе, их коммитится по полсотни - свыше двух сотен за год.
Почему Вы упорно занимаетесь демагогией, подменяя тему?
Я что писал?
При чем тут вообще релизы?
В первую очередь, это говорит о том, количество багов, которые неизбежны в любом программном продукте, активно уменьшается. И чем больше я вижу коммитов с исправление багов в проекте, тем значит меньше он их содержит. И наоборот, если в проекте баги исправляются редко, то значит их там действительно горы.
Все претензии к Бордину, который выдал последний патч только вчера
Одно дело, впихнуть UUIDv7 где-то сбоку. Сбоку он и так есть. А совсем другое дело - в ядро. Там целая Санта-Барбара получилась.
Тут. Естественно речь идет о КПД ДВС в гибридном автомобиле.
Mercedes еще в 2017 представил двигатель с КПД 43%
Для легковых автомобилей, всё же более перспективна гибридная силовая установка с электроприводом.
Это как? Я на своей L200 спокойно могу взяться рукой за выхлопную трубу при заведенном двигателе. Ну да, теплая. Но далеко не горячая.
На той же Тесла жидкостная система охлаждения электродвигателей и АКБ. Объем заливаемого антифриза 15 литров. И, естественно, радиатор, ничуть не уступающий в размерах моему. Так что я, уподобляясь Вам, тоже могу сказать, что на электромобилях тоже "много энергии просто "вылетает" в окружающую среду" )))
Исходя из того, что некоторые дизельные автомобили оборудуются дополнительными обогревателями салона, в холодное время года тепла от двигателя, наоборот, не хватает для обогрева. Например, L200 при -30 за бортом, хоть час её прогревай, но больше +10 градусов в салоне не будет, пока не включишь рециркуляцию.
Ну ладно, пусть даже 50-60% КПД. Но если энергия соляры какая была на НПЗ, такой остается и в топливном баке, то с электроэнергией всё не так просто. Например, КПД ГАЭС не 70-75%. Потери в ЛЭП до ГАЭС и от неё - еще 5-10%, КПД зарядного устройства 95%, АКБ - 90-95%, электродвигателя - 95%. Что там получилось? Потери по минимуму 25+5+5+5+5=45%. И вышли на тоже самое, даже считая, что вся энергия для ночной зарядки электромобилей вырабатывается солнечными батареями и накапливается на ГАЭС.
Лично мне кажется более привлекательными воздушно-алюминиевые батареи. Во-первых, высокая емкость, позволяющая проехать до 2 тыс. км. Во-вторых, алюминиевые аноды при транспортировке и хранении энергию не теряют. В-третьих, технологически замену алюминиевых анодов можно производить за время даже меньшее, чем тратится сейчас на заправку на АЗС. Да, есть ряд нерешенных проблем, но перспективы выглядят действительно заманчиво. И зеленая энергетика оказывается при деле, поставляя энергию на производство алюминиевых анодов, которые хранить можно десятилетиями.
Не понял о чем Вы. Периодичность commitfest PostgreSQL - 2-3 месяца. И в каждом видим порядка сотни коммитов. Ну пусть даже треть - багфиксы. Все равно получается свыше полусотни фич каждые 2-3 месяца.
Собственно говоря, именно из-за подобных соображений я и решил, что мониторинг мощности сигнала WiFi (RSSI) дает более адекватный результат, чем геопозиционирование. В моем случае, при -90 точка доступа уже устойчиво детектируется, а на парковке во дворе, так как WiFi уличный в LTE модеме на столбе, RSSI может оказаться даже нулевым.
Ну так детская нога вполне в эти пять сантиметров может пролезть. Пальцы могут и в сантиметр пролезть.
А в описываемом мной случае был забор из профнастила. Столбы 60х60. Итого между столбом и воротами 40-50, а между профнастилом и воротами - уже 100-110. А с той стороны укосина ворот под 45 градусов. И ребенка, как ножом, могло покалечить или убить, зажав между этой укосиной и столбом.
К сожалению, это не так. Знаю случай, когда ребенок не стал инвалидом только благодаря тому, что успели вовремя остановить открывающиеся ворота. Его к тому времени уже зажало между забором и каркасом ворот. Еще немного, и между забором и воротами оказалась бы не только нога, но и голова.
Тут спасёт, разве что, установка заграждения, не позволяющего детям попасть в зону сдвига ворот вдоль забора при их открывании.
Проблема не в том, что JS изначально был интерпретатором. Это как раз решаемо, так как компилировать можно и на лету. Причем не только кешируя результат, но еще и оптимизируя его в зависимости от профиля нагрузки.
Проблема производительности JS в динамической типизации и сборке мусора. Первое в любом случае приводит к дополнительной нагрузке на процессор и память при исполнении кода. А второе может приводить к непредсказуемым задержкам в неподходящий момент времени и/или к излишнему потреблению памяти.
Так как кеш CPU не резиновый, то бОльшее потребление памяти напрямую влияет на производительность.
Вторая проблема JS, которая органически вытекает из всего перечисленного выше - это необходимость в собственной среде выполнения. Иными словами, если код на том же Rust может почти из издержек многократно вызываться из любой среды, хоть из драйвера в ядре, то код на JS так просто не вызвать из-за необходимости инициализации среды. И это заметно сужает область его применения.
Если уж говорить о юридическом аспекте, то любым действиям должно предшествовать утверждение документа. В данном случае, локального подзаконного акта со ссылками уже на законы, их статьи, пункты и абзацы. Где он?
Похоже себе делаю (еще в прототипе), но на ESP32-C3 и только на открытие при подъезде к участку, контролируя уровень сигнала WiFi. Если при регистрации он сильный, значит машина на участке и подавать сигнал открытия ворот не надо. Если слабый, то значит только подъезжаем и нужно открыть ворота.
А вот при выезде с участка пользуюсь штатным брелком. Потому что с момента, как я сяду за руль до момента, когда я уже выезжаю, нередко, ворота просто не успевают открыться. С другой стороны, неудобно пользоваться брелком, когда за рулем в движении. А когда только садишься в машину - это не напрягает.
Автозакрытие по фотодатчику стоит на полторы минуты. Этого с лихвой хватает для въезда, даже если пес выбегает встречать машину через ворота сразу после их открытия.
Btree и hash решают несколько разные задачи. Для поиска только по равенству, само собой, hash эффективней. Но, для примера, в PostgreSQL hash индексы применяются не часто. По той простой причине, что на практике в выборках нужны сравнения не только по равенству, но и > или <. И тут hash не поможет, в отличии от Btree. Так что, если упорядоченность не нужна - применяем hash. Но если нужна - Btree.