Я же описал задачу — учёт (netflow) и перехват траффика в процессе его прокачки, чтобы ни один байт не пробежал мимо. Ни микротик, ни любой другой микрорутер не позволят этого сделать — их аппаратное ускорение прячет большую часть пакетов. Формально они (некоторые модели) поддерживают netflow, но он дырявый. Ещё их минус — в случае VPN там можно говорить только о сотне-другой мегабит, всего-то. А с такой железкой ещё и бонус — можно использовать и как мини-сервер, с кучей памяти и довольно неплохим процом.
Chuwi явно опоздали на этот праздник жизни — подобных мини-pc, которые умеющаются на ладони, с таким же процессором но ещё и гигабитным ethernet — полно, например MinisForum.
На днях приобрёл себе MinisForum GK41 — Celeron J4125, 8 GB LPDDR4, 128 GB SSD (не eMMC, и вполне приличный по тестам хотя о нём никто не знает), два порта по гигабиту каждый, BLE/WiFi, 4x USB 3.0, — отличный рутер получился — спокойно прокачивает через себя весь гигабит при загрузке проца не более 20%, и это с conntrack и прочими плюшками.
До него перепробовал кучу армов (включая BPi-R2) — никто не тянул гигабит, а если я тянул то только с аппаратным ускорением NAT, что имело негативные последствия для учёта и перехвата траффика (его просто не видно в этом случае), поэтому нужно было что-то помощнее.
Цена, правда, чуть меньше €200, но по скорости никакой арм тут и рядом не валялся (этот Celeron как минимум в три раза быстрее чем RPi 4 и аналоги, а сам девайс таких же размеров только в корпусе).
Третий миф гласит, что смартфоны нельзя оставлять подключенными к зарядному устройству надолго, например, на ночь — будто бы батарея перезаряжается сверх меры, отчего теряет ёмкость и даже может загореться.
Это не совсем миф. Как уже выше упоминали, это зависит от конкретного устройства и его контроллера — некоторые убиваются, некоторые нет. К сожалению, есть только один способ это проверить… А производители все как один (что смартфонов, что ноутбуков и планшетов) "не рекомендуют" оставлять на зарядке на ночь.
У меня было два планшета Nexus 7, абсолютно идентичных — один был постоянно на зарядке, другой обычно нет. Через год первый был с убитой батареей, второй — без ощутимых проблем.
Из ноутбуков — у меня их небольшая пачка, так вот замечено что HP (даже современные) сильно убивают батарею если их постоянно держать на зарядке, в то время как Asus этому (кажется) не подвержены.
Разумеется, все аккаунты, добавленные в приложение, сохраняются в облаке.
И где гарантия что они не утекут из этого облака, пусть даже и зашифрованные? Второй фактор это "то что вы имеете" — сохранение его в облаке — это уже не вы имеете, а (потенциально) совсем наоборот, ещё и с учётом того что пароль на бэкапы "минимум 6 символов" (при этом сами они рекомендуют 8).
Если исключить облако, то есть весьма неплохое (к тому же open source) приложение AndOTP.
А что делать секте забывающих что беспроводные наушники нужно заряжать каждый день? Как-то неприятно выяснить что они почти разряжены когда времени на зарядку нет, или когда нет зарядного устройства под рукой, да и большинство их них не умеют одновременно и работать и заряжаться.
Отсутствие необходимости писать полное название типа при перечислении элементов коллекции делает код чуть-чуть чище.
Здорово (как и всё остальное). Но немножко жалко что всё ещё приходится писать полное имя класса при определении конструкторов и деструкторов, вместо лаконичного this (как в D):
class SomeClass {
this() {...}
~this() {...}
}
Вот совершенно непонятно зачем нужны для них полные имена. Хотя современные IDE позволяют на лету всё это рефакторить, но всё равно это кажется избыточным.
Есть много приложений которые используют/поддерживает только одну СУБД и не планируют мигрировать, к тому же Postgres настолько мощная штука что вряд-ли в этом есть особый смысл, разве что кому-то нужна multimaster репликация — тут конечно пока тяжко.
Получается кстати забавно — если "особенности" использовать не рекомендуется, то зачем их вообще реализовывать?
Это кому как. У меня легко влезут три окна вряд по 160 символов в строке у каждого, и будет комфортно читать, вопреки всяким исследованиям которые утверждают что длинные строки хуже воспринимаются (да, хуже если глаз не видит всю строку сразу, но не более того).
Но вот то что из-за несколько длинных идентификаторов не всегда удаётся влезть в 80 символов — явно очень неудобно, и это с учётом того что времена терминалов низкого разрешения уже почти канули в лету. Хотя бы 120-140 было бы норм, но почему-то многие проекты (включая гугла) настаивают на 80, причём часто мотивировка в духе "у нас есть несколько человек у кого нет хороших мониторов, им неудобно".
Защита проста — не ставить ничего кроме как из маркета, с рейтингом не ниже 4х звёзд и с не менее чем сотней тысяч скачиваний. Вариант — таки ставить что хочется, но если разрешений к файлам и персональным данным, сети и локации не требует.
Правда, никто не помешает кому-то сделать очень качественное и нужное приложение, которое несколько лет будет радовать своих пользователей чем-то полезным (для чего требуется много всяких разрешений со вполне легитимным объсянением их необходимости), но в день X оно превратит телефон в тыкву. Сразу у всех миллионов скачавших его в своё время. Или ещё проще, где скиллов поменьше требуется — этот злобный кто-то просто банально похачит уже существующее приложение и пропихнёт его обновление через маркет (я вот совсем не уверен что после нашумевших историй с Garmin их приложениям можно доверять).
Вы говорили про отладку. В чём принципиальная разница отладки приложения в распоряжении которого отдельный контейнер и приложения рядом с которым ещё десяток приложений, особенно если они под другим uid?
Я вот никакой разницы не наблюдаю, хотя нет, чуть-чуть вру — если это приложение в докере — то это масса дополнительного инструментария (и в зависимости от обстоятельств — потеря производительности), а в остальном — никаких различий.
Мои приложения максимально абстрактны с точки зрения среды выполнения — им нужны память, немножко (очень мало) файлы и сокеты (много), всё что им нужно из библиотек и прочих зависимостей лежит рядом в одном дереве (то есть в теории они даже в системных библиотеках не нуждаются) — всё, имея это они могут работать как внутри контейнеров так и вне контейнеров, совершенно не осознавая среды. Я могу их отлаживать где угодно, и выполнять где угодно (пока это "где угодно" даёт файлы и сокеты) — что я выиграю если буду их насильно контейниризировать и отлаживать в контейнерах?
Я где-то говорил что он "критический"? Речь идёт просто о процессе которому нужна память но её нет "здесь и сейчас".
И какая принципиальная разница между упавшей приложухой и поставленной на паузу?
Примерно такая же как между "накопили данные, обработали, упали перед тем как сохранили результат" и "накопили данные, обработали, ждём пока сможем сбросить".
А если это что-то типа Postgres или Dovecot? Мне хардкорно поправить их архитектуру чтобы в одном контейнере был один процесс, несмотря на то что они очень плотно связаны друг с другом?
Успехов с отладкой и эксплуатацией более одного процесса на контейнер.
Вы серьёзно? Любая ось — это тоже своего рода контейнер, и в нём десятки а то и сотни процессов (причём далеко не всегда связанных друг с другом) — как они отлаживались-то всё это время, до появления докера и кубернетов?
Да практически вся индустрия работает с кучей процессов на контейнер (чтобы под ним не подразумевалось) с начала времён — и особых проблем с отладкой нет, а если мы возьмём IoT то там вообще по определению "одна железка — один контейнер", и отлаживают же.
В конейтере обычно не один процесс, и не всегда это контейнер. "Важный" это такой без которого система в принципе бесполезна, хотя в контексте речь шла про "важность" с точки зрения OOM killer.
Как я уже говорил выше, может быть несколько процессов которым в разное время нужно много памяти, но не одновременно — зачем мне выделять 50 гиг на случай если вдруг они все сойдут с ума и потребуют её одновременно, если 99% времени одновременно нужно только 10 гиг максимум? Проще обрабатывать вариант отказа в выделении памяти конкретному процессу и ставить его на паузу пока память не появится.
Ясное дело, если у меня что-то настолько важное (скажем, буквально жизненно важное) что оно не имеет права не получить память — тогда оно получит и 50 и даже 100 гиг, но так в моей практике почти не бывает (уже).
Пусть программа упадёт и потеряет часть данных, но внешний мир (файлы, базы данных и т. д.) остались в консистентном состоянии.
Вы уверены? Представьте что вы работаете в чём-то типа IDE, и в момент поиска чего-то оно падает, теряя ваши последние 15 минут работы (важный баг-фикс). Конечно, современные IDE достаточно часто сохраняют файлы так что ситуация маловероятна — но вот оператор набивающий форму с данными которые получает по телефону будет очень расстроен, если приложение которое эту форму ему показывает вдруг умрёт в конце ввода, а форма может быть отправлена/сохранена только полностью.
Есть и другой пример, немножко обратный — когда программа меняет внешнее состояние "под себя" (на время работы) но должна его "вернуть взад" при завершении (любом — штатном или нет), причём транзакции тут неприменимы (самый просто пример — всякие демоны для рутинга типа quagga/bird).
Штатное закрытие да, обрабатывать надо.
А SIGINT/SIGHUP — штатное закрытие? Приложение может получить сигнал от системы (злобный админ решил сделать shutdown пока пользователи ходили на обед) — и его нужно корректно обработать. Ясный пень, SIGKILL как раз на крайний случай, но всё остальное (сигналы не связанные с аппаратными источниками) я бы всё равно отнёс к "штатным".
Так или иначе не очень сложно разработать архитектуру таким образом чтобы сохранять то что возможно (и что жалко потерять) в случае неожиданностей, включая нехватку памяти — пользователи будут безмерно благодарны.
Если следовать этой логике то overcommit (как дисков так и памяти) нужно в принципе исключить, со всеми вытекающими из этого последствиями, и в итоге мы получим системы которые не используют большую часть ресурсов большую часть времени, а это чрезвычайно расточительно.
Докеры и кубернетисы (которые, кстати, далеко не у всех, хотя и очень популярны) расчитаны на то чтобы ресурсы использовались максимально эффективно — это не карт-бланш на игнорирование ситуаций когда ресурсы временно могут оказаться недоступны.
И 500 MB совсем не мелочи — если у вас таких процессов с сотню, но эти самые 500 MB нужны далеко не всем одновременно. И ничего "неправильного" в таких процессах нет — всё зависит от задач.
Я же описал задачу — учёт (netflow) и перехват траффика в процессе его прокачки, чтобы ни один байт не пробежал мимо. Ни микротик, ни любой другой микрорутер не позволят этого сделать — их аппаратное ускорение прячет большую часть пакетов. Формально они (некоторые модели) поддерживают netflow, но он дырявый. Ещё их минус — в случае VPN там можно говорить только о сотне-другой мегабит, всего-то. А с такой железкой ещё и бонус — можно использовать и как мини-сервер, с кучей памяти и довольно неплохим процом.
Chuwi явно опоздали на этот праздник жизни — подобных мини-pc, которые умеющаются на ладони, с таким же процессором но ещё и гигабитным ethernet — полно, например MinisForum.
На днях приобрёл себе MinisForum GK41 — Celeron J4125, 8 GB LPDDR4, 128 GB SSD (не eMMC, и вполне приличный по тестам хотя о нём никто не знает), два порта по гигабиту каждый, BLE/WiFi, 4x USB 3.0, — отличный рутер получился — спокойно прокачивает через себя весь гигабит при загрузке проца не более 20%, и это с conntrack и прочими плюшками.
До него перепробовал кучу армов (включая BPi-R2) — никто не тянул гигабит, а если я тянул то только с аппаратным ускорением NAT, что имело негативные последствия для учёта и перехвата траффика (его просто не видно в этом случае), поэтому нужно было что-то помощнее.
Цена, правда, чуть меньше €200, но по скорости никакой арм тут и рядом не валялся (этот Celeron как минимум в три раза быстрее чем RPi 4 и аналоги, а сам девайс таких же размеров только в корпусе).
Это не совсем миф. Как уже выше упоминали, это зависит от конкретного устройства и его контроллера — некоторые убиваются, некоторые нет. К сожалению, есть только один способ это проверить… А производители все как один (что смартфонов, что ноутбуков и планшетов) "не рекомендуют" оставлять на зарядке на ночь.
У меня было два планшета Nexus 7, абсолютно идентичных — один был постоянно на зарядке, другой обычно нет. Через год первый был с убитой батареей, второй — без ощутимых проблем.
Из ноутбуков — у меня их небольшая пачка, так вот замечено что HP (даже современные) сильно убивают батарею если их постоянно держать на зарядке, в то время как Asus этому (кажется) не подвержены.
Это как? modprobe загружает модуль в текущее ядро, после перезагрузки его там снова не будет.
И где гарантия что они не утекут из этого облака, пусть даже и зашифрованные? Второй фактор это "то что вы имеете" — сохранение его в облаке — это уже не вы имеете, а (потенциально) совсем наоборот, ещё и с учётом того что пароль на бэкапы "минимум 6 символов" (при этом сами они рекомендуют 8).
Если исключить облако, то есть весьма неплохое (к тому же open source) приложение AndOTP.
А разве их не было? Причём задолго до айфона.
ToF это способ измерения, а не технология, любой несканирующий лидар использует ToF по определению, так что это не могут быть "разные вещи".
Потому что SHOW TABLES будет работать из любого клиента, а не только psql, и это гораздо удобней чем:
А что делать секте забывающих что беспроводные наушники нужно заряжать каждый день? Как-то неприятно выяснить что они почти разряжены когда времени на зарядку нет, или когда нет зарядного устройства под рукой, да и большинство их них не умеют одновременно и работать и заряжаться.
И это притом что правообладатели постоянно плачутся о "потерянной прибыли" из-за пиратства и о том как им тяжело жить...
Здорово (как и всё остальное). Но немножко жалко что всё ещё приходится писать полное имя класса при определении конструкторов и деструкторов, вместо лаконичного
this(как в D):Вот совершенно непонятно зачем нужны для них полные имена. Хотя современные IDE позволяют на лету всё это рефакторить, но всё равно это кажется избыточным.
Есть много приложений которые используют/поддерживает только одну СУБД и не планируют мигрировать, к тому же Postgres настолько мощная штука что вряд-ли в этом есть особый смысл, разве что кому-то нужна multimaster репликация — тут конечно пока тяжко.
Получается кстати забавно — если "особенности" использовать не рекомендуется, то зачем их вообще реализовывать?
Это кому как. У меня легко влезут три окна вряд по 160 символов в строке у каждого, и будет комфортно читать, вопреки всяким исследованиям которые утверждают что длинные строки хуже воспринимаются (да, хуже если глаз не видит всю строку сразу, но не более того).
Но вот то что из-за несколько длинных идентификаторов не всегда удаётся влезть в 80 символов — явно очень неудобно, и это с учётом того что времена терминалов низкого разрешения уже почти канули в лету. Хотя бы 120-140 было бы норм, но почему-то многие проекты (включая гугла) настаивают на 80, причём часто мотивировка в духе "у нас есть несколько человек у кого нет хороших мониторов, им неудобно".
Защита проста — не ставить ничего кроме как из маркета, с рейтингом не ниже 4х звёзд и с не менее чем сотней тысяч скачиваний. Вариант — таки ставить что хочется, но если разрешений к файлам и персональным данным, сети и локации не требует.
Правда, никто не помешает кому-то сделать очень качественное и нужное приложение, которое несколько лет будет радовать своих пользователей чем-то полезным (для чего требуется много всяких разрешений со вполне легитимным объсянением их необходимости), но в день X оно превратит телефон в тыкву. Сразу у всех миллионов скачавших его в своё время. Или ещё проще, где скиллов поменьше требуется — этот злобный кто-то просто банально похачит уже существующее приложение и пропихнёт его обновление через маркет (я вот совсем не уверен что после нашумевших историй с Garmin их приложениям можно доверять).
Вы говорили про отладку. В чём принципиальная разница отладки приложения в распоряжении которого отдельный контейнер и приложения рядом с которым ещё десяток приложений, особенно если они под другим uid?
Я вот никакой разницы не наблюдаю, хотя нет, чуть-чуть вру — если это приложение в докере — то это масса дополнительного инструментария (и в зависимости от обстоятельств — потеря производительности), а в остальном — никаких различий.
Мои приложения максимально абстрактны с точки зрения среды выполнения — им нужны память, немножко (очень мало) файлы и сокеты (много), всё что им нужно из библиотек и прочих зависимостей лежит рядом в одном дереве (то есть в теории они даже в системных библиотеках не нуждаются) — всё, имея это они могут работать как внутри контейнеров так и вне контейнеров, совершенно не осознавая среды. Я могу их отлаживать где угодно, и выполнять где угодно (пока это "где угодно" даёт файлы и сокеты) — что я выиграю если буду их насильно контейниризировать и отлаживать в контейнерах?
Я где-то говорил что он "критический"? Речь идёт просто о процессе которому нужна память но её нет "здесь и сейчас".
Примерно такая же как между "накопили данные, обработали, упали перед тем как сохранили результат" и "накопили данные, обработали, ждём пока сможем сбросить".
А если это что-то типа Postgres или Dovecot? Мне хардкорно поправить их архитектуру чтобы в одном контейнере был один процесс, несмотря на то что они очень плотно связаны друг с другом?
Вы серьёзно? Любая ось — это тоже своего рода контейнер, и в нём десятки а то и сотни процессов (причём далеко не всегда связанных друг с другом) — как они отлаживались-то всё это время, до появления докера и кубернетов?
Да практически вся индустрия работает с кучей процессов на контейнер (чтобы под ним не подразумевалось) с начала времён — и особых проблем с отладкой нет, а если мы возьмём IoT то там вообще по определению "одна железка — один контейнер", и отлаживают же.
В конейтере обычно не один процесс, и не всегда это контейнер. "Важный" это такой без которого система в принципе бесполезна, хотя в контексте речь шла про "важность" с точки зрения OOM killer.
Как я уже говорил выше, может быть несколько процессов которым в разное время нужно много памяти, но не одновременно — зачем мне выделять 50 гиг на случай если вдруг они все сойдут с ума и потребуют её одновременно, если 99% времени одновременно нужно только 10 гиг максимум? Проще обрабатывать вариант отказа в выделении памяти конкретному процессу и ставить его на паузу пока память не появится.
Ясное дело, если у меня что-то настолько важное (скажем, буквально жизненно важное) что оно не имеет права не получить память — тогда оно получит и 50 и даже 100 гиг, но так в моей практике почти не бывает (уже).
Вы уверены? Представьте что вы работаете в чём-то типа IDE, и в момент поиска чего-то оно падает, теряя ваши последние 15 минут работы (важный баг-фикс). Конечно, современные IDE достаточно часто сохраняют файлы так что ситуация маловероятна — но вот оператор набивающий форму с данными которые получает по телефону будет очень расстроен, если приложение которое эту форму ему показывает вдруг умрёт в конце ввода, а форма может быть отправлена/сохранена только полностью.
Есть и другой пример, немножко обратный — когда программа меняет внешнее состояние "под себя" (на время работы) но должна его "вернуть взад" при завершении (любом — штатном или нет), причём транзакции тут неприменимы (самый просто пример — всякие демоны для рутинга типа quagga/bird).
А SIGINT/SIGHUP — штатное закрытие? Приложение может получить сигнал от системы (злобный админ решил сделать shutdown пока пользователи ходили на обед) — и его нужно корректно обработать. Ясный пень, SIGKILL как раз на крайний случай, но всё остальное (сигналы не связанные с аппаратными источниками) я бы всё равно отнёс к "штатным".
Так или иначе не очень сложно разработать архитектуру таким образом чтобы сохранять то что возможно (и что жалко потерять) в случае неожиданностей, включая нехватку памяти — пользователи будут безмерно благодарны.
Если следовать этой логике то overcommit (как дисков так и памяти) нужно в принципе исключить, со всеми вытекающими из этого последствиями, и в итоге мы получим системы которые не используют большую часть ресурсов большую часть времени, а это чрезвычайно расточительно.
Докеры и кубернетисы (которые, кстати, далеко не у всех, хотя и очень популярны) расчитаны на то чтобы ресурсы использовались максимально эффективно — это не карт-бланш на игнорирование ситуаций когда ресурсы временно могут оказаться недоступны.
И 500 MB совсем не мелочи — если у вас таких процессов с сотню, но эти самые 500 MB нужны далеко не всем одновременно. И ничего "неправильного" в таких процессах нет — всё зависит от задач.