Atoll A-560E/A-550 STD без минерализатора. Я пробовал его ставить один раз, разницу увидел только tds измеритель. Но мы все время жили в местности с мягкой водой, для нас вкус воды после осмоса нормальный. Люди, которые с детства привыкли к жесткой могут считать такую воду невкусной.

для престо была утилита для просмотра паролей
https://www.nirsoft.net/utils/web_browser_password.html

Ну и ещё вот способ только что нагуглил:
https://forums.opera.com/topic/14319/как-перенести-пароли-из-файла-wand

В общем поначалу ещё можно было выкрутиться хоть как-то.

vlmcsd под любой привычный вам дистрибутив. Можно и в докере

Остаётся загадкой, как всякие Cilium блокируют Egress

Во-первых, при помощи tc, а не XDP. XDP используется только на железках, на veth (и прочих виртуальных устройствах) его использовать смысла нет, так как skb все равно создается. (Кроме этого, xdpgeneric кривой, а нативный xdp на veth еще более кривой.)

Во-вторых, tc программа сажается на внешний кусок veth, находящийся в рутовом namespace, так как внутренний может быть доступен приложению внутри контейнера, которое может поменять логику BPF программы. (Это поменяется, когда мы станем использовать новый виртуальный девайс netkit, см. https://lpc.events/event/17/contributions/1581/ и сможем сажать программу прямо внутрь.)

А насчет сабжа у меня когда-то был dhcpclient на XDP (https://github.com/aspsk/xdp-dhcp), который сажался на tap и отвечал виртуалочке.

Хочу поделиться практическим опытом в качестве разработчика, переводившего одну широко известную в узких кругах игру на фэншуйные многопоточные рельсы. Фэншуй заключается в следующем: на старте игры анализируется топология процессора; далее, с учетом знаний о вендоре, знании о P/E-ядрах, структуре кешей L3, количестве ядер, наличия SMT/HT, и тд, физические ядра распределяются на группы в соответствии с их будущей специализацией (графика, логика, IO, звук, инпут, и т.п.). На основании полученных знаний, и в том числе, например, с учетом рекомендаций с сайта самого Intel’а о том как для игры реального времени оптимально распределять потоки на их гибридных процессорах, определяются максимальные размеры пулов потоков, их affinity-маски. На уровне Windows выставляются соответствующие приоритеты памяти, приоритеты исполнения, возможность троттлинга. Группировка также происходит по использованию ядрами общего кэша L3, если их несколько, чтобы уменьшить core-to-core latency и снизить вероятность cache-thrashing, так как связанные потоки с большой вероятностью работают с общей памяти, тем самым выше шанс что кэш будет дольше оставаться “теплым”. В результате имеем достаточно неплохую масштабируемость (в разумных пределах гранулярности наших задач), работающую лучше, чем без учета топологии процессора.
По итогу внедрения и обратной связи от юзеров на целом зоопарке процессоров, включая экстремальные вещи типа AMD ThreadRipper PRO 5975WX (32 ядра, 64 потока, 4 кэша L3), вывод такой: основная головная боль происходит именно от процессоров Intel с гибридной архитектурой. В чего вдруг?

Связано это с конфликтом управления ресурсами процессора. Если совсем кратко - в идеальном мире каждый разработчик должен сам учитывать конкретную модель процессора и определять какие потоки должны выполняться на каких ядрах, их количество, и тд, (и никакие другие процессы не должны конкурировать одновременно с ним за тот же ресурс процессора). Но в подавляющем большинстве случае этого никто не делает, как и нельзя изолироваться от конкурентов за ЦПУ, и все это остается на откуп операционной системе - слишком долго мы жили в однопоточной парадигме, плюс есть множество крупного рогатого софта ныне живущего по 30 лет, который не так просто переписать на новую парадигму. В итоге с одной стороны имеем многочисленный софт, который живет строго в один поток, либо создает неадекватное количество потоков и не управляет ими (например, std::thread::hardware_concurrency() возвращает максимальное количество потоков с учетом SMT/HT и без учета энергоэффективности ядер, некий абстрактный гомогенный пул), и с другой стороны имеем ОС, которая одновременного жонглирует потокам всех процессов по всем ядрам, ничего не зная о структуре вычислительной нагрузки конкретного процесса (какие потоки важнее и должны иметь высокий приоритет, какие можно затроттлить, и тп) старается максимизировать общую пропускную способность процессора и всей системы, а не производительность конкретного процесса находящегося в foreground (в ущерб остальным процессам в фоне). Foreground-процесс оптимизируется косвенно за счет повышения его приоритета, и возможного буста некоторых ядер на котором вращаются его потоки. Но ОС не обладает даром ясновидения, и может полагаться только:

1. на некоторые эвристики в оценке важности потока и паттерна его нагрузки на процессор

2. некоторые хинты, которые может сообщить разработчик для своих потоков

Даже с учетом хинтов, все это провалится в планировщик потоков ОС, который для рядового разработчика является черным ящиком без возможности прямого управления. И в общем случае попытка освоить всю мощность процессора сталкивается с неэффективностью планировщика и другими проблемами, особенно когда речь идет о real-time игре, где множество микро-тасков, и где высокой FPS и низкий latency при передаче данных между потоками на разных ядрах - не пустой звук, особенно когда Windows - не операционная система реального времени.

Конфликт управления, как было сказано выше, на примере гибридных процессоров Intel, заключается в следующем:

1. У каждого ядра есть некий режим Idle - когда ядро как бы спит, сокращая потребление электроэнергии до минимума ценой высокого latency при пробуждении, то есть переключение в режим idle и обратно штука не быстрая от слова совсем, когда мы ожидаем низкую core-to-core latency, а получаем тыкву. Основной смысл режима Idle - экономия электроэнергии и жизни батареи ноутбука, что уже как бы намекает, что эта история не про мощь и производительность, ведь так?...

2. На гибридных процессорах также появился некий хардварный ThreadDirector, который на основании внутренних метрик и, ключевое слово, эвристик, выдает рекомендации ОС о том, как управлять ядрами - когда и что переводить в режим Idle, троттлить, и тп.

3. ОС в праве не прислушиваться к рекомендациям ThreadDirector и может руководствоваться собственной политикой планировщика потоков, но, на сколько я могу судить, она таки это делает.

4. При этом в Windows во главу угла поставлена PPM (Processor Power Management) - политика управления питанием процессора. Соответственно на основе плана электропитания ОС может агрессивно управлять мощностью ядер, вплоть до перевода их в режим Idle.

5. Это приводит к распространенному явлению на процессорах Intel известному в Windows как Core Parking (на AMD подобного поведения пока не встречал), когда на основе всех эвристик и с учетом PPM операционная система принимает решение усыпить ядро, и вот с этого момента начинается ад. В реальности эти эвристики косячат. Разработчик мог рассчитывать именно на это ядро, т.к. оно входит в группу на котором вращался пул потоков быстрого реагирования - задачи выполняющиеся с какой-то периодичностью (условно 40% времени потоки привязанные к этим ядрам курят бамбук на семафоре, частота таких переключений вкл/выкл пропорциональна FPS в игре, и важна скорость включения этих ядер в работу). В итоге по эвристике ОС может решить что потоки не достаточно важны, и ядро можно усыпить несмотря на все affinity-маски и приоритеты потоков. В итоге пробуждая поток по семафору мы внезапно попадаем на latency при переходе ядра из режим Idle в боевой режим. Что и наблюдается у части счастливых обладателей гибридных процессоров, и выражается это во всевозможных фризах… Лечится принудительным отключением Core Parking (да-да, руками юзера в реестре или через PowerShell), но это не то на что я как разработчик могу повлиять, нет такого API через который я мог бы сообщить ОС убрать свои грязные лапы от моих блестящих ядрышек и оставить их в покое.. Скажу больше, даже если поставить план электропитания на максимальную производительность, Core Parking отключается только у E-ядер, а у P-ядер - никогда! Классно же, да?

Я могу ошибаться, но на мой текущий взгляд вся эта гибридность идет точно не от желания поразить пользователя выдающейся мощность процессора в самое сердечко, а про что-то другое… Для меня выглядит парадоксальным и абсурдным вводить эти добровольно-принудительные политики ограничения питания процессора особенно на десктопных машинах, в то время как от разработчика ожидают противоположного, что он снимет максимальную мощность с их любимого процессора. Начинаешь снимать мощность - получи троттлинг и дикие latency. Да, я понимаю что нагрев процессора - не пустой звук, но проблема этой гетерогенности ядер еще в том что в нагрузку вместо одного L3 кэша идут несколько кэшей с повышенной core-to-core latency между ядрами с разными L3. Синхронизация кэшей L1/L2 через синхронизацию L3 между P/E ядрами стоит дороже чем между P/P или E/E. Это уже накладывает отпечаток на то какой многопоточность, в широком смысле, должна быть - это максимально изолированные задачи, которые живут на своих типах ядер и практически не пересекающиеся по используемой памяти, чтобы избегать как огня синхронизации кэшей L3 (о фэнтезийный, дивный мир). 

При текущем раскладе вся эта история с гибридными процессорами плохо ложится на паттерн использования, когда от всей широты ядер ожидается высокая пиковая пропускная способность и низкая latency. По факту в случае с Intel реально работают только P-ядра, а E-ядра можно использовать для всяких балластных задач, которые, по сути, ни на что не виляют, и в таком количестве для игры просто не нужны... Какой-нибудь офлайновый рендерящий софт таких проблем не имеет, т.к. для него стихийные задержки в несколько миллисекунд не существенны, в то время как целый кадр игры надо распараллелить, посчитать, и собрать, например, при 120 FPS быстрее чем за ~8 мс, и здесь задержка в пару миллисекунд уже критична.

Стоит отметить, что на некоторых процессорах AMD также присутствует гетерогенность, но, по крайней мере, у них нет режима Idle и принудительного Core Parking я еще не встречал.

ну с ораклом всё ясно, там на спарк еще переезжали, но вообще это всётаки БД и юникс это слой совместимости, конкретно про m68k у меня примеров нет, но могу догадаться что это промышленные контроллеры, медицинские аппараты типа МРТ и прочее УЗИ, станки всякие... это всё крайне консервативные отрасли и там никто не будет софт менять если сегодня другой процессор модным станет

у меня помню на работе был станок который работал под Windows 95, в середине нулевых его по многочисленным просьбам радиослушателей портировали официально аж на Windows 98! и разработчики просто делали квадратные глаза и говорили что "всё отлично работает, вот комп, вот софт. в требованиях винда, чё тебе собака надо?" (c) ... станок лямов 50 стоил тогда... все запросы переделать софт хотябы на XP они просто отметали... причем софт был написан на VB5 (рукалицо) и под NT системами упорно не работал никак из-за того что гвоздями был прибит ф-циям ядра 9x винды

Хоть вопрос и не мне, отвечу :) Основная система видит WSL2 по IP адресу в отдельной внутренней сети, соответственно, этот адрес можно прямо и указывать в браузере.

Одна проблема - способ сделать этот адрес статическим довольно неочевиден, пришлось поискать.

Со стороны Windows вносим в реестр (сеть для примера, выбираете любую удобную из приватных диапазонов):

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Lxss]
"NatGatewayIpAddress"="172.24.80.1"
"NatNetwork"="172.24.80.0/20"

Со стороны WSL в /etc/wsl.conf добавляете:

[boot]
command="ip address add 172.24.80.2/20 brd + dev eth0"

Всё, теперь у Вас WSL всегда по адресу 172.24.80.2, можете добавлять в закладки... и решать следующую проблему с автоматическим шатдауном WSL самой себя, который происходит по малопонятным правилам и отключается, если повезёт, совсем уж замысловатыми танцами с бубном.

1. amd_pstate=active

   Активация amd_pstate даёт не просто выбрать одну из 3-4 частот процессора (например 1ghz, 2ghz и 3ghz с возможностью буста), а установить вообще любую, хоть 899mhz, хоть 2345mhz. Активный же режим содержит эвристику, который находит "подходящую, достаточную для текущей нагрузки" частоту. Это помогает немного сэкономить батарею, не теряя качество "опыта использования". Например нам надо 2.2ghz для текущей нагрузки. ACPI cpufreq поставит 3.0ghz т.к. 2.0ghz мало, а pstate сделает как надо (точнее может, но его ещё настроить надо).

2. tsc=reliable - проблема скорее всего биоса, но проявляется преимущественно на AMD. tsc не проходит проверку на точность, ядро отключает его в пользу hpet, который, разумеется, работает как надо, но в редких задачах производительность падает на десятки процентов, иногда в разы. проверить можно в cat /sys/devices/system/clocksource/clocksource0/current_clocksource или dmesg | grep clocksource

3. pcie_aspm.policy=powersave - решаемая проблема тож не строго AMD, но всё равно мне пришлось устанавливать. если pci-e устройства не активируют ASPM, потроха (в первую очередь быстрые nvme диски и wifi адаптеры, но не только) жрут лишнее, дико греются, тормозят из-за тротлинга. проверить нужно ли можно так: sudo lspci -vv | grep 'ASPM.*abled;' (всё или почти всё должно быть Enabled)

4. бонус: mitigations=off куда уж без него)

Какой, блин, референс? ODM-ов смартфонов в мире - как грязи.
Современный телефон не от брэндов - это конструктор, как современный велосипед. Есть материнка от ODM на определенном чипе с фиксированными позициями разъемов и вырезами на плате под камеру и прочее. Все остальное - ограничено только вашей фантазией, в смысле - ценой на полке магазина. Хотите - 2МП камеру поставьте на новейший чипсет, хотите - 20МП на устаревший. Вопрос лишь в том, кто такую конфигурацию купит.
То же самое с корпусом и надписью на нем. Минимальный заказ - 10К штук, и можете этот телефон хоть в честь своей дочки назвать, будут выпуклые буквы с ее именем на задней крышке (правда, в этом случае придется доплатить за пресс-форму и подвинуться по срокам).
В общем, процесс выбора телефона в качестве платформы сейчас заключается в том, что вы прилетаете, скажем, в Гонконг на AsiaExpoWorld, или что там у них сейчас, идете по этим огромным залам, тыкаете пальцем в понравившиеся модели на стендах и просите спеки на них, точнее, стандартные проспекты, с ценой и конфигурациями. Получите что-то вроде вот этого. Потом, вечером в отеле, вместо прогулки по вечернему Гонконгу, выбираете среди выбранных 50-100 спек наиболее подходящие 4-5 и на следующий день обсуждаете с производителями все уже предметно, уточняя неочевидные детали - материал корпуса, расцветку, конкретику по камере, стеклу и аккумулятору. В идеале, за три дня вполне можно договориться и на получение опытных образцов, но по факту, получить их можно только в первый день и по совершенно конским ценам, поскольку на выставку везут лучшее, а это - опытные образцы с бешеной себестоимостью, причем большинство из них уже разобрано предварительно, в ходе предыдущих переговоров, до выставки.
Разумеется, не все так просто, нужен опыт, тут будут и попытки впарить вам дисплеи с искаженными цветами, и аккумуляторы, реальная емкость которых сильно отличается от написанных на них цифр, и 10МП камер, на фото с которых нельзя прочитать текст на листе А4 - все это будет и на то, чтобы все это отсечь, нужен опыт. Но, повторяю, это стандартный процесс, пройдя который однажды, перестаешь считать чем-то выдающимся, вроде самостоятельной настройки газового котла на даче. Так делают все производители, и не только с телефонами. Вот, например, по ноутбукам. Если вы считали, что ваша стиральная машинка LG разрабатывалась в Южной Корее, вы так больше не считайте - там примерно то же самое.
А вот написание своей операционки на этот телефон - вот это уже процесс, на четыре-пять порядков по сложности превышающий вышеописанное. Там нужно самое главное - огромное количество очень умных людей, которые разбираются в современных мобильных ОС, и при этом не считают вас придурками, взявшимися за практически неосуществимую задачу.

результат не идентичный, но достаточный для замены MPC-HC на linux

есть же mpc-qt, выглядит так же как MPC-HT, но работает лучше потому что под капотом mpv. а главное не привязан к конкретной ОС и одинаково хорош как на линуксе так и на винде и на макоси

Как раз на эту нишу великолепно претендуют всякие LabVIEW/Teststand и иже с ними. И вполне себе успешно.

Особенно учитывая что они без особых проблем поддерживают интеграцию различных скриптовых языков, библиотек, исполняемых файлов и так далее и тому подобное.

docker run --rm -ti fathyb/carbonyl https://habr.com/ru/companies/ruvds/articles/744264/
https://github.com/fathyb/carbonyl

Если железо умеет в IOMMU, VT-d, VT-x (для Интела), IOMMU, AMD-vi (для АМД), а так же это все дело поддерживает мать то есть шанс успешно пробросить ВК в ВМ. Я использую ProxMox для этого, на примере, правда другого ноута, это выглядит так (только нужно учитывать, что движок Хабра поломал кавычки штрихами, заменив их на кавычки елочкой): https://habr.com/ru/post/575654/

Второй вариант это Intel GVT-g, который применяется почти на всех ЦП Интела, начиная с 4-го поколения. Если утрировано это дробление ресурсов интегрированной ВК для проброса ее в ВМ, но в отличие от первого варианта рабочий стол ВМ "снять" кабелем или получить напрямую на монитор ноутбука/ПК будет нельзя. Или, по крайней мере, я не знаю как это сделать. Как по мне эта технология чем-то напоминает Windows Hyper-V Remote-FX, но ей не является конечно.
https://3os.org/infrastructure/proxmox/gpu-passthrough/igpu-split-passthrough/#linux-virtual-machine-igpu-passthrough-configuration

Третий вариант это дробление ресурсов дискретной видеокарты для разных виртуалок, что при этом будет происходить со съёмом видеосигнала я ХЗ, т.к. не тестировал. Частично пересекается с первым по настройке и требованиям:

Четвертый вариант это вывод изображения с ВМ на монитор ноутбука, подменяя картинку хоста. Работает не всегда и не со всем ноутбучным железом. Многое зависит от разводки компонентов на мат.плате: https://gist.github.com/Misairu-G/616f7b2756c488148b7309addc940b28

Собственно если речь о внешней ВК, то это ближе к первому варианту, только вместо дскретки должен быть проброшен порт PCI-e в которую будет установлена внешняя ВК... Честно скажу не заморачивался на ноуте с этим, но все что есть на плате и доступно по lspci с обязательным пересечением по find /sys/kernel/iommu_groups/ -type l пробрасывается по методу в первом пункте, разве что для обычных устройств не нужно прописывать ID устройства для vfio, т.е. настройка упрощается немного.

Вроде ничего не забыл. По АМД - я не знаю есть ли у них аналог GVT-g, кроме того, по слухам, можно пробросить интеграшку полностью в ВМ, но лично у меня такой финт ушами не получился.

Сколько уже вбухали денег в этот редактор, сколько ещё предстоит.. Дешевле было бы выкупить визивиг, написанный на $mol, где все эти детские болезни уже решены, и немного кастомизировать под себя. Вот скрин:

Да, поддерживаются таблицы, мультикурсоры и горизонтальные каретки, блочное выделение, виртуальный рендер, бесконфликтный мёрж, синхронизацию дельтами, историю и тд.

однако если udp-пакеты перестают нормально ходить

а ещё насколько я помню прохмох часто посылает толстенные UDP пакеты от каждой ноды к каждой соседней для проверки "а не изменился ли mtu", не очень понимаю зачем это надо, но это приводит к довольно печальным последствиям если кол-во нод доходит до 30ти, а интерлинк всего гиг да ещё и не на самом лучшем свиче..

UPD: мне было лень рассписывать свою историю, поэтому нашёл похожую