Она оказалась удачным примером по двум причинам:
1) первая после текущей в списке поиска Хабра по запросу «linux device drivers»;
2) удачная в плане изложения и структуры.
Самое простое и понятное определение символьного драйвера — это драйвер для символьных устройств (классификация типов устройств приведена во введении LDD). А Вы привели определение именно Вашего драйвера с учетом его функционального назначения — это не верно.
Литературу приводят обычно в первой части цикла статей, либо в аннотации к циклу.
Да, вы правы, действительно статьи есть, но та статья, которую вы упомянули требует дополнительного аппаратного обеспечения, символьный же драйвер, не требует, по сути, ничего.
Открою Вам секрет, LPT-порт — это символьное устройство, а значит и драйвер к нему тоже символьный)) (опять Вы «по верхам» смотрели)
И еще одно важное замечание, не все драйвера, которые работают с памятью ядра, являются символьными — например, драйвер RAM-диска блочный. Об этом Вы еще прочитаете в других разделах LDD, чего я искренне желаю, если не потеряете интерес к этому после диплома.
Почти все разделы LDD (как 2, так и 3) уже переведены вроде бы… Да и на Хабре подобные посты есть, например, вот…
То, что вы разбирались с проблемой «написания драйверов под Linux» по LDD (Linux Device Drivers), видно сразу — название структур драйвера даже не удосужились поменять))) Тогда вопрос/рекомендация: «Как Вы считаете, стоит упомянуть LDD в списке литературы поста?»
Второе, о что споткнулся мой мозг — это определение «Символьного драйвера». Оно без понимания сути и контекста просто выдернуто из аннотации к разделу про символьные драйвера из LDD. Хотя, правильное и полное определение дается еще во Введении.
И да, в посте Вы не указали, под какое ядро Linux пишете драйвер, а это важно.
Спасибо за статью. Но есть у меня одна «придирка» (не относится к предоставленному туториалу) — дистрибутивы Astra Linux на территории РФ славятся тем, что имеют «все мыслимые и немыслимые» сертификаты от наших регуляторов, а Вы приводите пример с иностранными криптоалгоритмами. Почему? И какие дополнительные действия нужно совершить, чтобы то же самое осуществить на базе отечественных криптоалгоритмов?
А что Вас смущает в ограниченном сроке жизни CRL? Ведь процедура проверки электронной подписи базируется на доказательстве того, что, во-первых, электронная подпись корректна и, во-вторых, что сертификат подписанта был действующим на момент подписи.
Эксперименты с PDF мы проводили для «архивного хранения» электронных документов — тогда мы в тело PKCS#7-сообщения вкладывали еще и OCSP-ответы и TSS-ответы.
В документе по предложенной мной ссылке содержится мануал, как Adobe подписывает документы (с. 56).
Но в нем нет панели Подписи. Нет поля с подписью в теле документа. И не может быть.
Я это делал (в качестве эксперимента) лет 5 назад, когда еще свой УЦ делали. Возможно Adobe что то поменяли в своих алгоритмах. А Вы в CMS помещали цепочку сертификатов и списки отозванных сертификатов?
Не совсем точно. «Электронная подпись в формате PDF» — это обывательский термин, который лишь отражает тот факт, что в теле PKCS#7 (в нашем случае «Подписанные данные») содержится PDF-файл, так же там содержится «штамп времени» и, по-умолчанию, сертификат подписанта. В итоге, мы имеем обычное PKCS#7-сообщение. Кстати, я в свое время просто формировал PKCS#7-сообщение по всем требованиям (в разделе «подписываемые данные» пихал содержимое pdf-ки), расширение файлу делал ".pdf" и PDF-ридеры нормально открывали этот файл и верифицировали электронную подпись.
Вот ссылка, подтверждающая мои доводы.
Та же «сеть Фейстеля», что и в старом добром ГОСТ 28147-89. Немного «припудренная» и ослабленная. Если нет математического доказательства стойкости, то это очередная забава — «поиграться в криптографа» — в качестве дипломного проекта и для домашних поделок сойдет.
Вот ссылка на диссертацию Иванова Александра Ивановича — начальника «Лаборатории биометрико-нейросетевых технологий» АО ПНИЭИ, д.т.н. А вот статьи и монография на эту тему с места его работы.
Надеюсь, это будет Вам интересно. Желаю удачи.
Диалог с Вами мне стал неинтересен, раз Вы не можете адекватно воспринимать критику и не воспринимаете подтекст моих выражений))) На этом предлагаю закончить бестолковый диалог адепта «старой школы» с адептом «пяти медных кабелей». Удачи в постижении «основ»!
Заметьте, что слово «кабелей» я взял в кавычки, а это означает, что я пытался Вашей же терминологией из статьи выразиться. Так что про некомпетентность говорить Вам надо осторожнее)))
Вот уж не надо мне таких «основ», увольте)) Я осваивал этот материал по «нормальным» материалам, общепринятым, по которым в витой паре пятой категории немного больше «кабелей», чем оговаривается в Ваших «основах».
Я по википедии и не изучал этот материал. Ссылку я привел ту, которая в поисковике верхняя была. А вот про «еретическую» вашу «пятиуровневую модель TCP/IP» слышу впервые. Даже поисковик выдал Вашу статью, как самую релевантную. А про «читать чуть-чуть внимательнее», тут сложнее, особенно после фразы про витую пару и пяти медным кабелям)))
Спасибо за Ваш нужный труд. Я сам тоже диабетик-инсулинщик и в своё время столкнулся с той же проблемой поиска удобного приложения. Мой выбор, после пробы нескольких приложений, пал на приложение «Диабет». Основным критерием, по которому оно было одобрено — наличие пополняемого списка продуктов с соответствующими им ХЕ на порцию или на 100 грамм. Ещё автор этого приложения позаботился о синхронизации баз данных приложения между версиями для андроид-устройств и яблочных устройств. Так же в приложении есть возможность «обратной связи» с разработчиком для внесения предложений. Желаю Вам удачи в улучшении приложения и, конечно, неухудшения здоровья)))
1) первая после текущей в списке поиска Хабра по запросу «linux device drivers»;
2) удачная в плане изложения и структуры.
Литературу приводят обычно в первой части цикла статей, либо в аннотации к циклу.
Открою Вам секрет, LPT-порт — это символьное устройство, а значит и драйвер к нему тоже символьный)) (опять Вы «по верхам» смотрели)
И еще одно важное замечание, не все драйвера, которые работают с памятью ядра, являются символьными — например, драйвер RAM-диска блочный. Об этом Вы еще прочитаете в других разделах LDD, чего я искренне желаю, если не потеряете интерес к этому после диплома.
То, что вы разбирались с проблемой «написания драйверов под Linux» по LDD (Linux Device Drivers), видно сразу — название структур драйвера даже не удосужились поменять))) Тогда вопрос/рекомендация: «Как Вы считаете, стоит упомянуть LDD в списке литературы поста?»
Второе, о что споткнулся мой мозг — это определение «Символьного драйвера». Оно без понимания сути и контекста просто выдернуто из аннотации к разделу про символьные драйвера из LDD. Хотя, правильное и полное определение дается еще во Введении.
И да, в посте Вы не указали, под какое ядро Linux пишете драйвер, а это важно.
Эксперименты с PDF мы проводили для «архивного хранения» электронных документов — тогда мы в тело PKCS#7-сообщения вкладывали еще и OCSP-ответы и TSS-ответы.
Я это делал (в качестве эксперимента) лет 5 назад, когда еще свой УЦ делали. Возможно Adobe что то поменяли в своих алгоритмах. А Вы в CMS помещали цепочку сертификатов и списки отозванных сертификатов?
Вот ссылка, подтверждающая мои доводы.
Надеюсь, это будет Вам интересно. Желаю удачи.
«еретическую»вашу «пятиуровневую модель TCP/IP» слышу впервые. Даже поисковик выдал Вашу статью, как самую релевантную. А про «читать чуть-чуть внимательнее», тут сложнее, особенно после фразы про витую пару и пяти медным кабелям)))Для iOS есть более новая версия — продавец тот же, название то же)