Хм, помнится у меня тоже wd blue был, там история была с тем, что понадобилось мне раздел подвигать туда-сюда, так первая операция длилась сильно дольше второй, хотя объем данных был тот же, свободных ячеек тоже примерно одинаковое количество. TRIM работал, ноут работал каждый день.
в таком случае вообще не понятно, зачем вам измерительный шнур.
Иногда было бы удобно иметь такой.
Сейчас у меня есть Type-C тестер, но он добавляет два разъёма и свой шунт (что не добавляет стабильности). Это не очень удобно, зато даёт прекрасную возможность выломать разъём. Вот хороший мощный измерительный кабель с минимальным сопротивлением (и возможно с размыкателем линий данных) я бы взял.
А про двухпроводное подключение - это да, боль. Его подключаешь, и ничего не происходит. И идёшь искать Type-A порт. Кнопочка включающая подтяжку CC (и тем самым запускающая зарядник Type-C PD на дефолтных 5 вольтах) тоже была бы приятным бонусом.
Чип размещается в корпусе разъёма USB-A или USB-C и подключается к линиям питания через токоизмерительный шунт.
А без шунта никак?
К примеру, почему нельзя линию CC на стороне заряжаемого устройства замкнуть на VCC (у них даже имена друг другу соответствуют!), а на стороне зарядки измерять напряжение между этими линиями (то есть, на шунте из самой жилы VCC)?
Или даже лучше CC на GND замкнуть, чтобы не было большого напряжения и можно было низковольтными выводами измерять.
Реально не понятно, зачем добавлять доп.сопротивление в кабель. По идее, это же можно реализовать на кабеле с двумя подобными чипами (один замыкает кратковременно CC на GND, второй измеряет)? Но наверное придётся в этот момент CC от разъёма отключать с обоих сторон. Или зарядка от такого сбросится?
Когда только открывал статью - было предположение про то, что какая-то конкретная пачка может как-то забавно реагировать на температуру и к примеру лопаться если температура выхлопа оборудования поднимается выше какой-то безопасной. Не угадал(
Думаю, логика тут в том, что если накормить либу чем-то интересным - она сделает что-то забавное.
И если есть способ открыть в ffmpeg произвольный файл. - кто-то может подсунуть его именно в таком формате 1995 года, да ещё и с бережно подготовленным эксплойтом.
Когда открываешь видеофайл, а у тебя загорается светик на камере - это ниразу не прикольно)
Конечно, конкретно этот баг похоже не особо страшный, да.
Знаю точно, что в LTE (и древнее) ключи Ki (уникальный ключ симки) и OP (групповой ключ оператора) являются рандомными 128бит последовательностями.
Потом.вычисляется OPc=AES(OP, Ki), Ki и OPC сохраняются в сим-карте, а затем Ki шифруются транспортным ключом K4 (выбирая один из шифроблокнота) и превращаются в eKi, шифроблокнот и сами eKi (обычно разными путями) попадают оператору, там на HSS происходит расшифровка eKi обратно до Ki, возможно ещё предгенерация OPc (OP оператор уже знает и так) и импорт ключей в БД.
Доводилось таким заниматься.
В 5G начинается внедрение SUCI (Subscription Concealed Identifier). Это как раз технология, основанная на асимметричной криптографии (Elliptic Curve Integrated Encryption Scheme - ECIES). Публичный ключ оператора используется для шифрования постоянного идентификатора абонента (SUPI) прямо в телефоне, прежде чем он отправится в эфир. Это предотвращает его перехват. Однако сама аутентификация сессии по-прежнему основана на симметричном ключе Ki (или его производной в 5G — K).
Ассиметричная криптография много ресурсов требует в сравнении с симметричной, так что и в эфире данные тоже шифруются симметричным потоковым шифром.
Добавлю, возможность установить 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 например такое не прощает и выдаёт ошибку.
Подсчётом тактов и делением на тактовую частоту, после чего инкрементировать счётчик секунд изредка?
Хм, помнится у меня тоже wd blue был, там история была с тем, что понадобилось мне раздел подвигать туда-сюда, так первая операция длилась сильно дольше второй, хотя объем данных был тот же, свободных ячеек тоже примерно одинаковое количество. TRIM работал, ноут работал каждый день.
Иногда было бы удобно иметь такой.
Сейчас у меня есть Type-C тестер, но он добавляет два разъёма и свой шунт (что не добавляет стабильности). Это не очень удобно, зато даёт прекрасную возможность выломать разъём. Вот хороший мощный измерительный кабель с минимальным сопротивлением (и возможно с размыкателем линий данных) я бы взял.
А про двухпроводное подключение - это да, боль. Его подключаешь, и ничего не происходит. И идёшь искать Type-A порт. Кнопочка включающая подтяжку CC (и тем самым запускающая зарядник Type-C PD на дефолтных 5 вольтах) тоже была бы приятным бонусом.
А без шунта никак?
К примеру, почему нельзя линию CC на стороне заряжаемого устройства замкнуть на VCC (у них даже имена друг другу соответствуют!), а на стороне зарядки измерять напряжение между этими линиями (то есть, на шунте из самой жилы VCC)?
Или даже лучше CC на GND замкнуть, чтобы не было большого напряжения и можно было низковольтными выводами измерять.
Реально не понятно, зачем добавлять доп.сопротивление в кабель. По идее, это же можно реализовать на кабеле с двумя подобными чипами (один замыкает кратковременно CC на GND, второй измеряет)? Но наверное придётся в этот момент CC от разъёма отключать с обоих сторон. Или зарядка от такого сбросится?
Когда только открывал статью - было предположение про то, что какая-то конкретная пачка может как-то забавно реагировать на температуру и к примеру лопаться если температура выхлопа оборудования поднимается выше какой-то безопасной. Не угадал(
там еще ДВА контроллера. HL2EP3 confirmed))
Да не, всё как было так и останется, только линуксоиды будут рады расширению парка работающих через Steam и возможно Proton игр.
Не только SteamOS, но и весь Linux получит буст.
Но хуже не станет - PC игра не перестаает быть PC от того что станет работать и на Linux'е.
Когда-то Microsoft добились того, что Windows стала игровой платформой, сейчас Valve делают с Linux примерно то же самое.
Думаю, логика тут в том, что если накормить либу чем-то интересным - она сделает что-то забавное.
И если есть способ открыть в ffmpeg произвольный файл. - кто-то может подсунуть его именно в таком формате 1995 года, да ещё и с бережно подготовленным эксплойтом.
Когда открываешь видеофайл, а у тебя загорается светик на камере - это ниразу не прикольно)
Конечно, конкретно этот баг похоже не особо страшный, да.
Знаю точно, что в LTE (и древнее) ключи Ki (уникальный ключ симки) и OP (групповой ключ оператора) являются рандомными 128бит последовательностями.
Потом.вычисляется OPc=AES(OP, Ki), Ki и OPC сохраняются в сим-карте, а затем Ki шифруются транспортным ключом K4 (выбирая один из шифроблокнота) и превращаются в eKi, шифроблокнот и сами eKi (обычно разными путями) попадают оператору, там на HSS происходит расшифровка eKi обратно до Ki, возможно ещё предгенерация OPc (OP оператор уже знает и так) и импорт ключей в БД.
Доводилось таким заниматься.
В 5G начинается внедрение SUCI (Subscription Concealed Identifier). Это как раз технология, основанная на асимметричной криптографии (Elliptic Curve Integrated Encryption Scheme - ECIES). Публичный ключ оператора используется для шифрования постоянного идентификатора абонента (SUPI) прямо в телефоне, прежде чем он отправится в эфир. Это предотвращает его перехват. Однако сама аутентификация сессии по-прежнему основана на симметричном ключе Ki (или его производной в 5G — K).
Ассиметричная криптография много ресурсов требует в сравнении с симметричной, так что и в эфире данные тоже шифруются симметричным потоковым шифром.
Вы хорошо понимаете принципы работы мобильных сетей и что именно тогда клонировали?
Там из симки извлекались её ключи, они же хранятся у оператора в базе данных и используются HSS для авторизации симки.
Хоть на тысячу симок эти ключи клонируй - оператору достаточно заблокировать в своей БД ключ который клонировали, и вся тысяча клонов дружно отомрёт.
Я уж не говорю про возможные причуды и глюки при одновременной работе нескольких клонов.
А можно чуть детальнее вот про это? Лазером вроде чип вскрывали и читали ячейки как-то хитро поляризуя свет, но вычислительно?
Не подсказывайте им!!!
Добавлю, возможность установить 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 например такое не прощает и выдаёт ошибку.