Отвечая буквально на ваш вопрос, в данном случае он «за» GPL и «против» DRM. Однако, по моему сугубо личному мнению, суть позиции Реми — это активно продвигать свои убеждения путем прямого опускания альтернатив оным. Знаете, есть такой прием, сначала что-то обверзать, найти нестыковки, несоответствия и изьяны, а поток указать на то, что этих недостатков как бы не имеет. И хотя далеко не факт что указанное не имеет других недостатков, но вот как бы обратите внимание.

Вот и тут этот человек использовал GPL как элемент для выскахывания своего личного «фи» в сторону Apple и iPhone с последующей отсылкой к Linux платформам для которых эта лицензия — дом родной. То что он зачем-то походя прокинул и Applidium, который получил согласие VideoLANа на портирование в iOS, и сам VideoLAN, в принципе заинтересованный в распространении VLC на как можно большее количество платформ, его мало волновало. В этом суть моего предыдущего комментария.

Простите, не смог удержаться от комментария. Насколько я помню, пулл аут Аплидиумовской версий из магазина был связан не просто с жалобой разработчика Video LAN, а с целой идеологической подоплекой с его стороны. При этом остальные разработчики ничего против как бы не имели. А вот идеологическая подоплека товарища по имени Remi Denis-Courmount, напрямую была связана с GPL и DRM. Происходило это все, когда Реми работал в Нокиа над Миго и еще над кое-чем, что он в своем послании обозвал «более открытыми мобильными платформами». Такой вот был прогиб в сторону Нокиа в частности и Linux / Open Source вообще. В Video LAN большинство людей покрутили у виска на эту выходку, но слово как известно, не воробей. Зная Реми лично, скажу что это далеко не самая пафосная его выходка, человек реально готов ради принципа бросаться резкими словами и идейными лозунгами, даже если он в итоге обсирают негативно влияют на его собственные результаты труда и вообще на то сообщество в котором он работает. Вобщем тут был и бенефис и кризис жанра отдельного артиста в одном флаконе, нежели какие-то разногласия между Applidium и VideoLAN.

Сечение проводов в спецификации не указывается. Есть требования по падению напряжения (по земле 375mV и по VBus 625mV), сопротивлению в контактах (30mO) которые кабель должен обеспечивать и по температуре — допустимая температура на всем протяжении соединения, включая контакты, не должна превышать 30 градусов цельсия при комнатной температуре 25.

Пример, если считать однометровый кабель с стандартным A и микро B коннекторами по третьему профилю (3A):
1. По земле:
a. Сопротивление кабеля — Rcable(GND) = V / I = 375mV / 3A = 125mΩ
b. Макс. сопротивление в контактах 30mΩ x два коннектора = 60mΩ
c. Общее допустимое сопротивление провода — 125mΩ — 60 mΩ = 65mΩ
2. По VBus:
a. Сопротивление кабеля — 625mV / 3 = 208mΩ
b. Сопротивление контактов — 30mΩ * 2 = 60mΩ
c. Общее допустимое сопротивление провода — 208mΩ — 60mΩ = 148mΩ

Теперь лезем например в AWG и выбираем по сопротивлению подходящие провода. В данном случае для метрового провода нам подойдет для земли нумер 22 (52.94mΩ на метр) а для VBus подойдет номер 26 (134mΩ на метр). Если метраж увеличивается, то соответственно пересчитываем.

Если в соединении есть адаптеры и переходники, то соответственно формула общего сопротивления удлинняется.



Надеюсь что ответил на ваш вопрос.

Я думаю что логика простая — если кому-то интересны характеристики, то по маркировке человек разберется. Если нет, то достаточно знать что порт или кабель поддерживает USB PD.

Ну очевидно, никак :) Попробую упростить, порты после сертификации маркируются вышеприведенными обозначениями. Однако конечному пользователю не нужно заботиться о соответствии кабелей профилям и наоборот.

Кабели, предназначенные для USB Power Delivery, как сказано в посте, имеют дополнительные пины. Эти пины, вместе с типом коннектора, используются для определения электрических характеристик кабеля, включая профиль электропитания и максимальные токи. Например для микро USB коннектора установлен лимит в 60W, независимо от жырности проводов, и т.д.

Кабели не предназначенные для PD все равно будут работать на минимальном профиле.

Конечному пользователю нужно только знать — совместим ли данный порт или кабель с Power Delivery или нет. Для этого нужны обобщенные иконки. Все остальное делает логика. В спецификации есть четкие электрические и блок-схемы, как детектировать тип кабеля и его соответствие установленным профилям.

Надеюсь что ответил на ваш вопрос.

Совершенно справедливый вопрос. Эти обозначения предназначены для сертификации, а не для конечного пользователя. Для пользователя обобщенные иконки USB PD выглядят вот так:

Для стирания информации существуют различного рода стандарты которые однозначно объясняют почему надо делать так а не иначе. Самые известные — это DoD 5220.22-M и метод Гутмана. Есть еще всякие местечковые и специальные стандарты типа военных AFSSI и NAVO, думаю что и в России тоже.

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

Интересно чем вам не нравится одновременное сочетание и автономные и A-GNSS и почему надо выбирать или то или другое?

Приемники GPS обычно выполняют интегрированными на одной базе с модемом. Берешь такое устройство и видишь в нем сразу тройку ACM интерфейсов проброшенных до AT процессора — один для PPP/PDP, второй для контроля GPS приемника, а по третьему сразу NMEA валится после включения приемника. Так вот такие комбинированные приемники объединены с радиомодулем и стартовать в режиме оффлайн не могут и девайсов на таких решениях — большинство. Автономный, в данном случае — это независимый от основного радиомодуля.

Не очень понятно зачем вообще лезть в эти дебри в статье информационного характера. Я вроде попытался понятно написать, что стартовать и определять текущее местоположение 920 и 820 будут за считанные секунды даже в режиме оффлайн.

Ну про такой хардкор я бы никогда не стал тут писать :)

Вот и я о том же. Там где начинается хардкор — теряется вся наглядность…

Ок. Тогда придется-таки копаться в IAT :)

Я не стал возиться с CreateRemoteThread() из за соображений наглядности. Глобальный хук это самое простое решение не требующее возни с чужим процессом извне. Чтобы избежать дополнительной возни с релокациями и импортами есть более простое решение. Делается оно так:

1. Открываем процесс на запись:

	HANDLE hp = OpenProcess(PROCESS_CREATE_THREAD | PROCESS_QUERY_INFORMATION | 
							PROCESS_VM_OPERATION | PROCESS_VM_WRITE | PROCESS_VM_READ, 
							FALSE, <ИДЕНТИФИКАТОР ПРОЦЕССА>);

2. Резервируем кусок памяти для имени подгружаемой DLL:

	void *pLibName = VirtualAllocEx(hp, NULL, MAX_PATH, MEM_COMMIT, PAGE_READWRITE);

3. Пишем туда собственно имя:

	WriteProcessMemory(hp, pLibName, (void *) <ИМЯ DLL>, MAX_PATH, NULL)

4. Делаем трюк с kernel32.dll — он всегда грузится по одному и тому же адресу в разных процессах:
FARPROC pLoadLibrary = GetProcAddress(GetModuleHandle(«Kernel32»), «LoadLibraryA»);
5. Запускаем поток:
HANDLE ht = CreateRemoteThread(hp, NULL, 0, (LPTHREAD_START_ROUTINE) pLoadLibrary,
pLibName, 0, NULL);

После этого ждем выхода и все дела. DLL точно так же прогрузится в чужой процесс и поставит там хуки.

На эту тему можно спорить бесконечно. Начать с того что Ваш фильтр для AdBlock так же не перехватит RTMP и тоже не универсален, потому что это плагин под конкретный браузер. Закончить можно тем что RTMP инкапсулированный в HTTP ловится точно очень даже легко как, за исключением того что помимо GET надо еще отсматривать POST.

А «чистый» RTMP протокол (который на порту 1935 под префиксом rtmp://) технически к браузерам имеет мало отношения и не всегда дружит с проксями. То есть да, его можно перехватить, но не с перепиливанием в смысле рефакторинга, а вообще с дописыванием отдельного обработчика, равно как и для rtp, rtsp, mms и тому подобные. Мой простенький пример даже HTTP-то через пень-колоду обрабатывает — это в целях наглядности.

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

Видимо, я вкладываю другой смысл в выражение «перехват из браузера», извините. Другие люди не стесняются писать для этого целый драйвер…

Постараюсь на следующей неделе написать апдейт или отдельный пост на эту тему и скомпилить x64, как обещал ранее.

Критика справедливая и принимается. Я не зря написал что перезапись кода это недостаток именно данного примера. В данном посте мне стоило некоторых усилий держаться в рамках научно-популярной статьи и не сорваться в хардкор. К сожалению если бы я стал копать в сторону анализа инструкций, то хардкора было бы не избежать. Уверяю Вас что у меня есть другая реализация, очень похожая на ту что Вы описали.

Писал я это все не далее как вчера, 31 августа 2012 года. Проверял в последней версии Google Chrome Beta, SRWare Iron и IE 9. Видимо дело в том что плагины и расширения в данном случае не играют существенной роли, независимо от того где их хром держит…

Полностью согласен что LSP был бы более корректным методом. Но моей скрытой целью было показать как работает перехват функций DLL в принципе и возиться с написанием сервис провайдера для WinSock не хотелось :)

Постараюсь на неделе найти время и все это сделать для x64.

Честно говоря я не знаю готового софта для этих целей. Написать его с нуля не такая уж и тяжелая работа, тем более что для WMP будет достаточно привинтить YouTube каталоги к DLNA серверу типа Twonky и объявить себя медиа сервером. SmartTV по умолчанию работает с DLNA серверами на ура. Но я пока не готов что-то подобное делать из-за отсутствия времени.