Добавлю, возможность установить 2 полноскоростных M.2 SSD позволяет пробросить их в VMку с NASом и поднять на них NVME read/write кэш (для него нужны 2 SSD в RAID1, с одним можно только read-only кэш поднять (если RW-кэш умрёт - будут потеряны все данные, в том числе и те что на HDD)), а третий SSD можно сделать системным для PVE. Или обойтись хорошей USB3 флешкой, но они не так надёжны. 4 слота для SATA HDD/SSD дают запас слотов для безопасной миграции на другие диски (не разбивая зеркало) или расширения ёмкости.
PVE же удобен тем, что для него есть много готовых скриптов (Proxmox VE Helper-Scripts) которые автоматически разворачивают контейнеры и VMки с приложениями которые вы выберите (тот же Jellyfin к примеру), это очень удобно для самохостинга.
Только декоративную крышку на дисковую корзину лучше не устанавливать на WTR PRO - она мешает охлаждению дисков, перекрывает воздуху путь.
Ещё, вроде как 5825u позволяет установить 64GiB RAM, а n150 - 32. Хотя по спекам вдвое меньше у обоих, так что это не точно.
Aoostar WTR PRO на Ryzen 7 5825U неплохие, как основа для NAS/мини-сервера имхо сейчас лучший вариант по цене/производительности. Поместится 2 (если очень надо - 3, но третий будет ограничен одной линией PCI-Express 3.0) M.2 SSD 2280 и 4 диска 3.5" (2х Exos 20ТБ точно нормально помещаются).
По цифрам и бенчмаркам миники на N100/150 сильно уступают (производительность ядер у них хуже, самих ядер меньше, слот RAM и M.2 слот всего один).
Только если захочется XPEnology - придётся вспомнить, что драйвера amdgpu там нет и аппаратное транскодирование заведётся только если поставить PVE, в нём поднять контейнер с Jellyfin (который будет юзать драйвер amdgpu от PVE) и VMку с XPEnology.
Но это если медиасервер нужен, для любых других задач недостатков у вариата на Ryzen имхо нет. Конечно, неплохо бы ECC-память и hot-swappable дисковую корзину, но это уже другой уровень.
Как позднее объяснил Клинг, он не против нейтрального языка, он против чужаков, которые приходят и присылают пулл-реквесты с идеологической мотивацией.
Строчки со * для find (и вообще когда надо передать именно строчку а не список файлов) надо в кавычки заключать, иначе будет плохо (shell попытается развернуть паттерн сам и дальше произойдёт что-то, но вряд ли то, чего вы хотели от find).
В примере это сработало только по счастливой случайности - в текущем каталоге не нашлось файлов с именами *conf*, и при этом shell не выдал ошибку а передал строчку как есть. ZSH например такое не прощает и выдаёт ошибку.
Да стандартные приложения вообще оч плохо дружат с BT-микрофонами, мне когда-то нужен был диктофон для записи с BT-устройства - замучился перебирать приложения, еле нашёл подходящее. Правда давно это было.
Может действительно что-то своё запилили, но сомневаюсь. ИМХО, просто приложение камеры допилили для работы с HSP/HFP.
"Полный спектр" BT HSP/HFP не тянет, там mSBC кодек, он даёт качество чуть лучше УГ (причем в обе стороны).
А вот почему микрофон в кейсе лучше - мне тоже не понятно. Он же подключен через тот же BT (и точно так же зарезается им по полосе частот).
А ещё непонятно зачем, ведь если в руках всё равно надо какую-то фиговину держать - так телефон же уже есть, и он уже оснащен хорошим, годным микрофоном с полным спектром (уже без кавычек, ибо mSBC его не режет).
Да и человек разговаривающий с телефоном выглядит уже привычно и нормально, а вот разговаривающий с непонятным яйцом - малость странновато)
Примерно так (termux потому что мобила в руках, но работает во всех линуксовидных осях):
Report issues at https://termux.dev/issues ~ $ which sleep /data/data/com.termux/files/usr/bin/sleep ~ $ cat /data/data/com.termux/files/usr/bin/sleep > sleep ~ $ chmod +x sleep ~ $ ./sleep 60& [1] 7678 ~ $ echo test > ./sleep bash: ./sleep: Text file busy ~ $
Но это явно не частый случай, иначе любое обновление используемых библиотек или запущенных демонов заканчивалось бы ошибкой
Выше уже упомянули, что пакетные менеджеры не пишут в исполняющиеся бинари/либы, а создают рядом новые файлы и затем переименовывают/удаляют старые бинари-либы а новые временные файлы переименовывают во имя старых.
При этом открытые дескрипторы (и их ммапы) остаются валидными, но привязанными к старым файлам (которые можно даже удалить, но при этом дисковое пространство освободится только когда последний открытый дескриптор закроется), а вновь запускающиеся процессы будут работать с уже обновлёнными файлами.
А вот что происходит при записи в исполняющийся текстовый файл:
Что тут происходит (лучше в динамике посмотреть самому):
~ $ linenew - это не я набрал, это bash вывел приглашение ~ $ и затем через время скрипт вывел linenew и завершился. Потом я нажал ENTER и bash сообщил что скрипт в фоне завершил работу.
На USB2.0 (и 3.0 по линиям 2.0) работают QC2.0 (аналог PD 2.0 с фиксированными профилями), QC3.0 (аналог PD3.0 PPS с плавным регулированием напряжения), а также всякая проприетарщина. Но они используют не линию CC (её в этих портах ещё не завезли) а линии D+/D-.
Кстати, а есть какие-то протоколы зарядки, которые работают через пары TX/RX от USB3.0?
Единственное что работало на USB2.0 это PD1.0 (ещё более странное недоразумение чем QC1.0):
USB Power Delivery 1.0 был предложен в 2012 году, раньше Quick Charge 1.0. Этот протокол был значительно сложнее всего описанного выше — гаджет и ЗУ общались по линии VCC цифровым кодом частотной модуляцией на частоте 24 МГц. Использовался мало.
Лично мне такие зарядки и устройства не попадались (а QC2.0/3.0 полно). В PD2.0 уже перешли на TypeC и работу по линии CC.
Если мост на двух реле собран - реле похоже имеют несколько контактных групп (минимум по две). Если групп 3 или больше - можно сделать аппаратную электрическую взаимоблокировку (по схеме как у контакторов вспомогательные блок-контакты подключаются в реверсивной схеме, но там по хорошему ещё и механическая взаимоблокировка дополнительно подстраховывает).
В принципе можно блокировку сделать и с двумя контактными группами, но это малость сложнее и требует дополнительных компонентов (прежде всего приходят на ум транзисторные ключи на размыкание питания катушек крест-накрест друг от друга).
Добавлю, возможность установить 2 полноскоростных M.2 SSD позволяет пробросить их в VMку с NASом и поднять на них NVME read/write кэш (для него нужны 2 SSD в RAID1, с одним можно только read-only кэш поднять (если RW-кэш умрёт - будут потеряны все данные, в том числе и те что на HDD)), а третий SSD можно сделать системным для PVE. Или обойтись хорошей USB3 флешкой, но они не так надёжны. 4 слота для SATA HDD/SSD дают запас слотов для безопасной миграции на другие диски (не разбивая зеркало) или расширения ёмкости.
PVE же удобен тем, что для него есть много готовых скриптов (Proxmox VE Helper-Scripts) которые автоматически разворачивают контейнеры и VMки с приложениями которые вы выберите (тот же Jellyfin к примеру), это очень удобно для самохостинга.
Только декоративную крышку на дисковую корзину лучше не устанавливать на WTR PRO - она мешает охлаждению дисков, перекрывает воздуху путь.
Ещё, вроде как 5825u позволяет установить 64GiB RAM, а n150 - 32. Хотя по спекам вдвое меньше у обоих, так что это не точно.
Aoostar WTR PRO на Ryzen 7 5825U неплохие, как основа для NAS/мини-сервера имхо сейчас лучший вариант по цене/производительности. Поместится 2 (если очень надо - 3, но третий будет ограничен одной линией PCI-Express 3.0) M.2 SSD 2280 и 4 диска 3.5" (2х Exos 20ТБ точно нормально помещаются).
По цифрам и бенчмаркам миники на N100/150 сильно уступают (производительность ядер у них хуже, самих ядер меньше, слот RAM и M.2 слот всего один).
Только если захочется XPEnology - придётся вспомнить, что драйвера amdgpu там нет и аппаратное транскодирование заведётся только если поставить PVE, в нём поднять контейнер с Jellyfin (который будет юзать драйвер amdgpu от PVE) и VMку с XPEnology.
Но это если медиасервер нужен, для любых других задач недостатков у вариата на Ryzen имхо нет. Конечно, неплохо бы ECC-память и hot-swappable дисковую корзину, но это уже другой уровень.
И где он тут не прав?
Ни за что фашистом обозвали разработчика(
Смартфон вместо геймпада?
Неудобно же, тактильной отдачи на нажатие нет, стиков нет, и вообще непонятно как держать - ручек тоже нет.
Хуже чем джойстики от Dendy - у тех хотя бы тактильная отдача у кнопок была и выронить не страшно было.
Как-то тема производительности вообще не раскрыта, хотя в заголовке упомянута.
Да и тема размера тоже, то что dll уменьшится от такого было и так нетрудно догадаться, интереснее было бы конкретные показатели увидеть.
А время сборки как-то изменилось?
Кто-нибудь в теме, подскажите, а у волокон на других материалах но под эти же длинны волн как с потерями обстоят дела?
Так вот из-за кого телефон так греется и тормозит при серфинге!
Не надо так!
Не понимаю, как связано одно:
с другим:
Разработчики дружно потеряли дистрибутив 17.13?
Строчки со * для find (и вообще когда надо передать именно строчку а не список файлов) надо в кавычки заключать, иначе будет плохо (shell попытается развернуть паттерн сам и дальше произойдёт что-то, но вряд ли то, чего вы хотели от find).
В примере это сработало только по счастливой случайности - в текущем каталоге не нашлось файлов с именами *conf*, и при этом shell не выдал ошибку а передал строчку как есть. ZSH например такое не прощает и выдаёт ошибку.
Да стандартные приложения вообще оч плохо дружат с BT-микрофонами, мне когда-то нужен был диктофон для записи с BT-устройства - замучился перебирать приложения, еле нашёл подходящее. Правда давно это было.
Может действительно что-то своё запилили, но сомневаюсь. ИМХО, просто приложение камеры допилили для работы с HSP/HFP.
"Полный спектр" BT HSP/HFP не тянет, там mSBC кодек, он даёт качество чуть лучше УГ (причем в обе стороны).
А вот почему микрофон в кейсе лучше - мне тоже не понятно. Он же подключен через тот же BT (и точно так же зарезается им по полосе частот).
А ещё непонятно зачем, ведь если в руках всё равно надо какую-то фиговину держать - так телефон же уже есть, и он уже оснащен хорошим, годным микрофоном с полным спектром (уже без кавычек, ибо mSBC его не режет).
Да и человек разговаривающий с телефоном выглядит уже привычно и нормально, а вот разговаривающий с непонятным яйцом - малость странновато)
Будильник не обязательно слышать, есть же всякие часы-браслеты с будильником на вибрации.
Примерно так (termux потому что мобила в руках, но работает во всех линуксовидных осях):
Report issues at https://termux.dev/issues
~ $ which sleep
/data/data/com.termux/files/usr/bin/sleep
~ $ cat /data/data/com.termux/files/usr/bin/sleep > sleep
~ $ chmod +x sleep
~ $ ./sleep 60&
[1] 7678
~ $ echo test > ./sleep
bash: ./sleep: Text file busy
~ $
Выше уже упомянули, что пакетные менеджеры не пишут в исполняющиеся бинари/либы, а создают рядом новые файлы и затем переименовывают/удаляют старые бинари-либы а новые временные файлы переименовывают во имя старых.
При этом открытые дескрипторы (и их ммапы) остаются валидными, но привязанными к старым файлам (которые можно даже удалить, но при этом дисковое пространство освободится только когда последний открытый дескриптор закроется), а вновь запускающиеся процессы будут работать с уже обновлёнными файлами.
А вот что происходит при записи в исполняющийся текстовый файл:
~ $ cat test.sh
#!/usr/bin/env sh
echo line1
sleep 30
~ $ ./test.sh&
[1] 19211
~ $ line1
~ $ echo >> test.sh 'echo linenew'
~ $ cat test.sh
#!/usr/bin/env sh
echo line1
sleep 30
echo linenew
~ $ linenew
[1]+ Done ./test.sh
~ $
Что тут происходит (лучше в динамике посмотреть самому):
~ $ linenew - это не я набрал, это bash вывел приглашение ~ $ и затем через время скрипт вывел linenew и завершился. Потом я нажал ENTER и bash сообщил что скрипт в фоне завершил работу.
Можно грабить корованы?
И что, теперь ходить всем непрокачаными нубасами первоуровневыми?(
Ура-ура, теперь PS5 будет разряжаться и работать медленнее!
Хотя подождите, она же без аккумулятора!
А родителя им предъявить там не надо при этом?
Ну так, на всякий случай, должен же кто-то родительский контроль реализовывать?
И как теперь геймпад выключать? Что, каждый раз батарейки вышелушивать??
Неа.
На USB2.0 (и 3.0 по линиям 2.0) работают QC2.0 (аналог PD 2.0 с фиксированными профилями), QC3.0 (аналог PD3.0 PPS с плавным регулированием напряжения), а также всякая проприетарщина. Но они используют не линию CC (её в этих портах ещё не завезли) а линии D+/D-.
Кстати, а есть какие-то протоколы зарядки, которые работают через пары TX/RX от USB3.0?
Единственное что работало на USB2.0 это PD1.0 (ещё более странное недоразумение чем QC1.0):
Лично мне такие зарядки и устройства не попадались (а QC2.0/3.0 полно). В PD2.0 уже перешли на TypeC и работу по линии CC.
Если мост на двух реле собран - реле похоже имеют несколько контактных групп (минимум по две). Если групп 3 или больше - можно сделать аппаратную электрическую взаимоблокировку (по схеме как у контакторов вспомогательные блок-контакты подключаются в реверсивной схеме, но там по хорошему ещё и механическая взаимоблокировка дополнительно подстраховывает).
В принципе можно блокировку сделать и с двумя контактными группами, но это малость сложнее и требует дополнительных компонентов (прежде всего приходят на ум транзисторные ключи на размыкание питания катушек крест-накрест друг от друга).