Вот вы серьёзно предлагаете либо плановую экономику, либо печатать деньги? И не видите в этом проблем? Это ваши решения такие? Ну тогда не удивляйтесь критике.
То, что у нас пока нет лучшей работающей на практике модели, не значит, что капитализм не является кривым костылём. Просто это - самый рабочий кривой костыль, который у нас сейчас работает.
(И да, тот факт, что капитализм даже в нынешнем его виде требует постоянного роста потребления (читай бесконечного роста рынков сбыта), давно в общем-то признан и не является секретом Полишинеля. Просто пока есть куда расти рынку, вот он и работает.)
"Чистый" pagecache в своп и не выгружается. Либо "грязные" страницы, которые после чтения изменились, но ещё не были записаны на диск, либо анонимные страницы. Выгружать в своп то, что просто можно прочитать с диска смысла немного.
Я вот сейчас специально перепроверил перед тем, как ответить. И да, UPnP как был штукой, придуманной для целей NAT punching, так ей и остался. И, соответственно, оно ipv4 only, для v6 стандарта нет. И реализаций тоже нет.
Сможет. Лампочка с "управлением откуда угодно" будет сюрприз-сюрприз! По условному mqtt/websocket из облака производителя получать команды, которые в облако будет приложенька на телефоне пользователя отправлять. Сама инициировать коннект изнутри наружу и получать пуши. Вы думаете эти облачные сервисы с учетками для чего лепят то?
что в инет смотрит, что нет и это был прозрачно и удобно
NAT транслирует адреса в заголовках. Связность - вопрос роутинга. Безопасность - фаервола. В любом пользовательском CPE/условном микротике/всяких мелкоэнтерпрайзных роутерах/ngfw и прочих таких штуках есть всё из вышеперечисленного.
Пользователь лампочку непременно прямо в точку обмена трафиком подключит. Оптикой на сто гигабит.
А не в домашний wifi, который раздаёт взятый у оператора CPE с линуксом на борту. В котором ВНЕЗАПНО из коробки практически гарантированно включен stateful фаервол, разрешающий снаружи внутрь проходить только пакеты, относящиеся только established и related соединениям. Такшта домохозяйки и бабушки ровно в такой же безопасности, как и сейчас при ipv4.
Ультимативно универсальный способ - реверс прокси с хелсчеками воткнуть. Берёте haproxy, вешаете его слушать tcp сокет на лупбэке хоста, где крутится приложение. Соединения приходящие на этот сокет отправляете в backend секцию с развесистой логикой хэлсчеков на основе tcp-check send/expect и пачкой ваших инстансов pg кластера. При должной ловкости рук реально заставить haproxy отправлять коннекты только на primary инстанс; рвать соединения в пуле внутри приложения если инстанс постгреса, на который они смотрят, перестал быть primary; очень быстро детектить переезд primary инстанса; некоторое время придерживать в очереди соединения приложения если прямо сейчас нет живой primary ноды (вместо того, чтобы в приложение валили ошибки о невозможности подключиться к живому мастеру в момент переезда primary). И вообще ещё много чего странного и безумного. Но придётся разобраться в протоколе постгреса и руками hex строки собирать для tcp-check логики.
Нужно ее полностью выключить, подождать, пока конденсаторы разрядятся, и включить снова. Новые состояния ячеек памяти можно будет анализировать и исследовать в качестве случайных данных.
А потом у вас меняется partnumber этой самой DRAM и ВНЕЗАПНО!!! новая ревизия гарантированно успевает разрядиться за выбранное вами эмпирически время выключения. Или гарантированно не успевает. Или там переходные процессы при включении более предсказуемые и паттерн 0-1 по ячейкам каждый раз +- одинаковый. Или температура эксплуатации немножечко другой становится и характеристики конденсаторов помахали ручкой (ах, эта старая добрая cold boot attack!). Короче говоря, классическое "после сборки доработать напильником до появления случайности", да.
Не успел отредактировать прошлый комментарий, поэтому напишу отдельным. Чтобы светодиоды не пытались получать питание с ножки микроконтроллера, можно (и стоит в общем-то для лишней стабильности и помехоустойчивости) поставить между микроконтроллером и первым(и) светодиодам(и) push-pull драйвер (чьё питание подключено не к питанию контроллера, а прям к той жирной линии, от которой светодиоды питаются). Можно взять какой-нибудь готовый драйвер для мосфетов (типа eicedriver от infineon), можно на bjt транзисторах собрать. Микроконтроллер можно запитать от того же источника, что и ленты, просто через диод шоттки и с жирным собственным буферным конденсатором. И тогда можно сильно сократить количество банок на лентах.
Советы про cpld и soc с fpga академически, конечно, интересны. Но, честно скажу, не очень практичны =)
Именно сразу параллельно на много лент с однопроводным управлением. Я лично делал шесть каналов, но можно и больше. Вроде бы до восьми (по четыре на каждый блок PIO). Плюс весь этот процесс обновления вообще не грузит cpu, а работать напрямую с цветами в виде трехбайтных RGB структур получается быстро и удобно. В общем в реальности у меня лично процессор простаивал почти всегда при том, что ленты обновлялись настолько часто, насколько частота их шины позволяет (800k вроде бы). По сравнению с stm32 прямо другой уровень совершенно. Раньше такое можно было сделать разве что только на cypress (у них тоже блоки для реализации кастомной периферии есть), но у cypress совершенно другой уровень вхождения и ценники.
Кстати, на новой модели контроллера от raspberry должно поддерживаться ещё больше лент параллельно (12?)
В качестве контроллера для таких лент шикарно заходит rp2040 от raspberry. У него есть pio, который позволяет буквально сделать выделенный блок для управления лентами и тупо в него по DMA rgb заливать прямо из памяти в виде трехбайтовых блоков без всяких конверсий.
То, что у нас пока нет лучшей работающей на практике модели, не значит, что капитализм не является кривым костылём. Просто это - самый рабочий кривой костыль, который у нас сейчас работает.
(И да, тот факт, что капитализм даже в нынешнем его виде требует постоянного роста потребления (читай бесконечного роста рынков сбыта), давно в общем-то признан и не является секретом Полишинеля. Просто пока есть куда расти рынку, вот он и работает.)
"Чистый" pagecache в своп и не выгружается. Либо "грязные" страницы, которые после чтения изменились, но ещё не были записаны на диск, либо анонимные страницы. Выгружать в своп то, что просто можно прочитать с диска смысла немного.
Пункт первый: написать самому. Если где-то воткнули детектор, то вам жирно так намекают, что ваша задача НЕ пользоваться LLM.
Скорее всего речь про пиковое потребление в момент отправки данных по радио, причём с максимальной мощностью. 50мА, конечно, не идеал, но терпимо.
Я вот сейчас специально перепроверил перед тем, как ответить. И да, UPnP как был штукой, придуманной для целей NAT punching, так ей и остался. И, соответственно, оно ipv4 only, для v6 стандарта нет. И реализаций тоже нет.
Никогда такого не было и вот опять!
Сможет. Лампочка с "управлением откуда угодно" будет сюрприз-сюрприз! По условному mqtt/websocket из облака производителя получать команды, которые в облако будет приложенька на телефоне пользователя отправлять. Сама инициировать коннект изнутри наружу и получать пуши. Вы думаете эти облачные сервисы с учетками для чего лепят то?
В упор не понимаю как NAT решает
NAT транслирует адреса в заголовках. Связность - вопрос роутинга. Безопасность - фаервола. В любом пользовательском CPE/условном микротике/всяких мелкоэнтерпрайзных роутерах/ngfw и прочих таких штуках есть всё из вышеперечисленного.
Следуя логике господ выше, отключенный на почти каждом CPE из коробки UPnP обычная домохозяйка найти и включить не сможет)
Пользователь лампочку непременно прямо в точку обмена трафиком подключит. Оптикой на сто гигабит.
А не в домашний wifi, который раздаёт взятый у оператора CPE с линуксом на борту. В котором ВНЕЗАПНО из коробки практически гарантированно включен stateful фаервол, разрешающий снаружи внутрь проходить только пакеты, относящиеся только established и related соединениям. Такшта домохозяйки и бабушки ровно в такой же безопасности, как и сейчас при ipv4.
Stateful фаерволы на тех же cpe: "Ну да, ну да. Пошли мы нафиг"
Ультимативно универсальный способ - реверс прокси с хелсчеками воткнуть. Берёте haproxy, вешаете его слушать tcp сокет на лупбэке хоста, где крутится приложение. Соединения приходящие на этот сокет отправляете в backend секцию с развесистой логикой хэлсчеков на основе tcp-check send/expect и пачкой ваших инстансов pg кластера. При должной ловкости рук реально заставить haproxy отправлять коннекты только на primary инстанс; рвать соединения в пуле внутри приложения если инстанс постгреса, на который они смотрят, перестал быть primary; очень быстро детектить переезд primary инстанса; некоторое время придерживать в очереди соединения приложения если прямо сейчас нет живой primary ноды (вместо того, чтобы в приложение валили ошибки о невозможности подключиться к живому мастеру в момент переезда primary). И вообще ещё много чего странного и безумного. Но придётся разобраться в протоколе постгреса и руками hex строки собирать для tcp-check логики.
А потом у вас меняется partnumber этой самой DRAM и ВНЕЗАПНО!!! новая ревизия гарантированно успевает разрядиться за выбранное вами эмпирически время выключения. Или гарантированно не успевает. Или там переходные процессы при включении более предсказуемые и паттерн 0-1 по ячейкам каждый раз +- одинаковый. Или температура эксплуатации немножечко другой становится и характеристики конденсаторов помахали ручкой (ах, эта старая добрая cold boot attack!). Короче говоря, классическое "после сборки доработать напильником до появления случайности", да.
Фильм "Задница" - шикарная постметаирония. Уверен, что современный критики нашли бы в ней глубокий (кхе-кхе) социальный посыл.
Третий пусть пропускают нафиг. И сразу делают Las Vegas.
Абсолютли. Эта кроличья нора весьма бездонна
Хватить должно. Но реализовывать - офигеть не встать. FPGA - очень глубокая кроличья нора даже на таких рядовых задачах, как условные DSP фильтры.
Не успел отредактировать прошлый комментарий, поэтому напишу отдельным. Чтобы светодиоды не пытались получать питание с ножки микроконтроллера, можно (и стоит в общем-то для лишней стабильности и помехоустойчивости) поставить между микроконтроллером и первым(и) светодиодам(и) push-pull драйвер (чьё питание подключено не к питанию контроллера, а прям к той жирной линии, от которой светодиоды питаются). Можно взять какой-нибудь готовый драйвер для мосфетов (типа eicedriver от infineon), можно на bjt транзисторах собрать. Микроконтроллер можно запитать от того же источника, что и ленты, просто через диод шоттки и с жирным собственным буферным конденсатором. И тогда можно сильно сократить количество банок на лентах.
Советы про cpld и soc с fpga академически, конечно, интересны. Но, честно скажу, не очень практичны =)
https://mcuoneclipse.com/2023/04/02/rp2040-with-pio-and-dma-to-address-ws2812b-leds/
Именно сразу параллельно на много лент с однопроводным управлением. Я лично делал шесть каналов, но можно и больше. Вроде бы до восьми (по четыре на каждый блок PIO). Плюс весь этот процесс обновления вообще не грузит cpu, а работать напрямую с цветами в виде трехбайтных RGB структур получается быстро и удобно. В общем в реальности у меня лично процессор простаивал почти всегда при том, что ленты обновлялись настолько часто, насколько частота их шины позволяет (800k вроде бы). По сравнению с stm32 прямо другой уровень совершенно. Раньше такое можно было сделать разве что только на cypress (у них тоже блоки для реализации кастомной периферии есть), но у cypress совершенно другой уровень вхождения и ценники.
Кстати, на новой модели контроллера от raspberry должно поддерживаться ещё больше лент параллельно (12?)
В качестве контроллера для таких лент шикарно заходит rp2040 от raspberry. У него есть pio, который позволяет буквально сделать выделенный блок для управления лентами и тупо в него по DMA rgb заливать прямо из памяти в виде трехбайтовых блоков без всяких конверсий.