Как человек, весьма много работавший с ETW, хочу ответственно заявить, что автор статьи совершенно не понимает о чем говорит. И дело даже не в самом ETW API (которое, скажем прямо, далеко от идеального) — дело в непонимании кучи БАЗОВЫХ вещей.
Начнем с того, что автор пытается использовать низкоуровневое API и с удивлением обнаруживает, что оно… НИЗКОУРОВНЕВОЕ. Ну явно какие то дебилы писали. Использовать к примеру StartKernelTrace было бы можно, но как же тогда писать возмущенную статью. Если нужно более гибкое, но высокоуровневое API, можно использовать WPRControl (это тем более удобно, что тот же самый профайл можно будет запускать отдельно от собственной программы, а также менять состав собираемого лога без перекомпиляции — простой правкой конфигурационного файла).
Возмущение по поводу GUID вообще не в кассу. Здесь человеку нужно почитать о размещении значимых типов в C/C++ и единицах трансляции. Отличие INITGUID в том, что оно заставляет макрос DEFINE_GUID определять переменную (с выделением места в data секции для текущей единицы трансляции). По умолчанию (без INITGUID) данный макрос только объявляет (extern) переменную и предоставляет линкеру позаботиться о поиске определения (и, соответственно, размещения). Да-да, тупой Майкрософт «не смог найти способ внедрить их в заголовочные файлы (я могу насчитать несколько возможных способов, но, я полагаю, им не понравился не один из них)». На минуточку, здесь прозвучало предложение внедрять ОПРЕДЕЛЕНИЯ переменных (то есть выделение памяти для них) в заголовочне файлы ПО УМОЛЧАНИЮ. Конечно же, что может быть лучше заголовочных файлов с непустым вкладом в объектный файл? Ведь всегда можно налепить сверху хак вроде __declspec(selectany). Динамически выделяемую память, кстати, за собой тоже можно не чистить — достаточно просто прибить процесс и никто и не заметит утечек.
Возмущение по поводу ограниченного количества «флагов» в «kernel trace» провайдере забавны в свете того, что вот прямо сейчас вон там из 33, а «xperf -providers K» из Windows 8.1 SDK выдает список из 55 возможных флагов (это только публичная часть — возможно для «внутреннего потребления» их еще больше).
Предложенные варианты API забавны, ибо совершенно не попадают в сценарии использования ETW. Самое главное требование — низкая стоимость (околонулевая в случае, когда на событие никто не подписан и не более пары тысяч тактов, если подписан). При этом необходимо обеспечить возможность работы на *всех* IRQL (к примеру есть возможность писать в лог с IPI или CLOCK уровней, когда не только диспетчер не работает, но и большинство прерываний от устройств замаскированы). При этом все должно продолжать работать на многопроцессорных системах (из чего следует, что использование любых видов блокировок запрещено). Необходимо иметь возможность писать в кольцевой буфер (подумайте о флаге REFSET который трейсит все ОБРАЩЕНИЯ к памяти — хотите ли Вы в пользовательском режиме обрабатывать все такие события? В реальном времени?). Нужно иметь возможность начать лог до старта не только первого пользовательского процесса, который мог бы в ETWBeginTrace, а и до старта, собственно, ядра (да-да, winload умеет писать в ETW лог — предлагаю угадать как он это делает). Это только то, что пришло в голову прямо сейчас (мне даже представлять не хочется этап сбора требований в команде, которая разрабатывала этот компонент).
Собственно разделение сессий трассировки и потребителей трейса — вполне логичное следствие даже тех поверхностных требований, которые я уже привел. Поэтому и разделение StartTrace/OpenTrace — трейс запускается в сессии, а потреблять его может кто угодно (собственно, это ОСНОВНОЙ режим работы API — запуск трейса xperf/wpr на тестовой/проблемной машине и анализ лога на машине разработчика — я даже и не припомню когда бы мне пришлось сталкиваться с «realtime» трейсами).
Ну, не совсем. Очевидно, что Вы не хотите, чтобы любой процесс мог украсть отслеживание лога ядра у другого процесса. Поэтому Microsoft решила, что лучшим решением проблемы будет просто запрещение доступа до лога ядра всем процессам, кроме тех, которые имеют права администратора.
Это даже комментировать не хочется. Ну конечно, канал «утечки» системной информации не имеет никакого значения для того, что требуется права администратора. Это было сделано исключительно для того, чтоб никто не мог вырвать сессию.
Кстати, по поводу «безумия». SystemTraceProvider и его же сессия — действительно выделены в отдельный специальный случай, что выглядит несколько некрасиво. Но, как и многие другие компромиссы, этот был сделан ради производительности — уж сильно много всего трейсит данный провайдер. Для остальных провайдеров API более универсально, но за универсальность, как обычно платят производительностью. Начиная с Win8, его можно включить до восьми раз. В принципе в моей практике почти всегда хватало одного. Исключения — это всякие когда запущен какой нибудь Process Explorer/Process Hacker (я активно исследую что-либо) и при этом мне хочется собрать трейс. Если включить эти случаи, то мне изредка нужно 2-3 сессии. И при этом я, в отличие от автора статьи, действительно не один год провел ковыряясь в производительности.
Сложно серьёзно относиться к постам и словам человека, который заявил, что настроенная винда без ущербных вирусов, а в линуксе их в любом случае полно.
Во-первых я не заявлял ни того ни другого.
Я лишь отметил, что профиль распространения «настоящей малвари» (в соответствии с определением моего оппонента) несколько отличается от «общеизвестного». Пожалуйста, не приписывайте мне заведомо ошибочных суждений
Правильно настроенная ОС это уже 95% защиты от вирусов. Только вот… В большинстве случаев ОС настроена не правильно, что линкус, что виндовс, что убунта.
Да, но ведь речь идет о «абы как» (хорошо если по умолчанию, но ведь полно ж твикеров, зверсиди, отключателей апдейтов для того чтоб «активация не слетела» и прочих — и они все попадают в общую статистику) настроенном Windows и о Linux (я говорю обобщенно о всем стеке, а не только о ядре), который настраивают хорошо оплачиваемые профессионалы с многолетним стажем.
Если же сравнивать «apples to apples» — сервера на Linux против серверов на Windows, то есть очень существенный перекос (гораздо выше, чем можно было бы ожидать просто от распространенности технологий, даже учитывая нелинейность зависимости). В прошлый раз, когда я просил показать мне high-profile взломы серверов на основе Windows, то всплыл только T-Mobile. При том, что на Linux кого только не ломали — и kernel.org и linuxfoundation и savannah.gnu.org и redhat.com (дважды) и mysql.com и кучу других, не говоря уже о просто коммерческих/вебдваноль вендорах типа target, gawker, sony, hyper-vm и пр…
На всякий случай: я не спорю, что Linux можно захарденить практически до непробиваемости (к примеру, я не думаю, что Google будет так или иначе взломан в обозримом будущем), но все таки это весьма нетривиально (не думаю, что у RedHat или kernel.org не хватило денег либо опыта в Linux для того, чтобы предотвратить взломы).
Из-за того, что соц инженерия — наиболее частый вектор проникновения, люди и придумывают всякие SafeBrowsing/SmartScreen. До некоторой степени помогают также антивирусы. В целом ставки постоянно поднимаются, но ситуация выглядит более-менее стабильной — существенного перевеса нет ни у одной из сторон.
Про повышение цены вопроса согласен.
то в одних случаях (Линукс) возможно заломить поднебесную цену вопроса, а в других (Вин и Мак) принципиально невозможно.
Вы очень сильно ошибаетесь. Причем в обеих оценках.
Файлы останутся совместимыми. Я предлагаю настроить KeePass под «конкретной ОС» так, чтобы получить бОльшую часть преимуществ работы под отдельными пользователями и практически без неудобств. Если ту же базу нужно использовать под Linux/OSX то для достижения подобного эффекта таки придется пользоваться отдельным пользователем.
Включите secure desktop для мастер пароля. Если злоумышленник сможет вытащить пароль оттуда, то система все равно уже не ваша — можете перестать беспокоиться :-)
Кстати, хром/хромиум и IE используют очень качественные песочницы для запуска недоверенного кода. Исследователи оттуда периодически выбираются, но для злоумышленников это пока нецелесообразно.
Разные пользователи помогут от части атак, но далеко не ото всех. У того же KeePass есть опция, которая спрашивает мастер пароль в другой сессии — фактически проникнуть туда без повышения привилегий все равно нельзя. Собственно, эта опция помогает противостоять подавляющему большинству атак, против которых помогает отдельный пользователь и не помогает в случаях, когда отдельный пользователь тоже бессилен. И при этом secure desktop практически не влияет на удобство использования keepass.
chroot — небезопасен. Его нельзя использовать для ограничения доступа. Вот парассылок. По большому счету я бы и «настоящей» виртуализации не слишком бы доверял, если бы меня паранойя замучила («не слишком» — это только в случае запуска недоверенного кода на доверенном хосте, но в виртуалке, если же хост потенциально скомпрометирован, то любая виртуалка на нем точно также скомпрометирована). Только физическая изоляция — только хардкор.
Кстати, как в вашем случае защититься от вируса, который логирует все содержимое буфера обмена? Или еще лучше содержимое буфера обмена сразу после очередного изменения и скриншот экрана?
Здесь опять же нужно моделировать угрозы. Если речь идет о массовом сборе паролей, то вполне можно допустить, что когда-нибудь (когда это станет экономически целесообразно) будет использоваться модуль автоматического вытаскивания паролей из популярных менеджеров паролей. Простая обфускация keepass в этом случае отлично помогает, хотя, как Вы отметили, и является security through obscurity. Делать же постоянные снимки буфера обмена да еще и скриншоты — попросту не масштабируется и, соответственно, такие угрозы в ближайшем будущем ожидать не стоит.
Второй возможный вид угрозы — таргетированная атака конкретно на Вас лично. Ну в таком случае вообще никакая ОС общего назначения не поможет.
Ну право же, не стоит так подставляться. Нет, серьезно (Hint: еще раз перечитайте список Ваших собственных публикаций).
Но давайте все же поговорим предметно. Возьмем класс
реальное малваре (множество включающее вирусы), а не «пользователь скачал хз что и откуда и сам установил с максимальными правами»
и попробуем «хотя бы поверхностно поинтересоваться вопросом». В контексте данного топика нас интересуют только то «реальное малваре», которое привело либо к крупной утечке пользовательских данных либо к крупной эпидемии (пусть будет 0.5% популяции)
В качестве «ОС, распространенных на сегодня» возьмем Windows, OSX и Linux (используется в пределах погрешности измерения на «десктопах», но довольно широко распространена в некоторых других сегментах). Также возьмем мобильные ОС: Android, iOS и Windows Phone
1. Мобильные ОС можно сразу исключить из рассмотрения — ни по одной из платформ я не смог найти достоверной информации по «реальному малваре», которое бы привело к «реальному ущербу»
2. Windows — за последние 15 лет (включая Summer of Worms) я не смог обнаружить ни единого случая, когда «реальное малваре» (да-да, то которое может заразить полностью пропатченную ОС без явного согласия пользователя), которое бы привело к «реальному ущербу». Искренне надеюсь на Вашу помощь. Очень рекомендую «поверхностно поинтересоваться вопросом» перед тем как предлагать варианты.
3. OSX — есть как минимум Flashback который использовал 0-day уязвимость в «Apple Java» (на тот момент Sun Java была пропатчена, но Apple распространяла JRE по собственным каналам и в этом канале распространения патча еще не было — это на тот момент была историческая норма для Apple). Flashback привел к заражению 600к машин, что на тот момент составляло более процента популяции.
4. Linux. Здесь примеров полно. От червей в роутерах до крупных утечек данных (их десятки — могу привести еще, но можно ограничиться и утечкой 160 миллионов профайлов за раз).
Хотелось бы услышать про Ваш взгляд на то, что такое «нормальная ОС». Заранее спасибо
Конечно, всегда пожалуйста: будет время — обязательно помогу. Стоить ли рассматривать Ваш «сарказм», как категорический отказ «хотя бы поверхностно поинтересоваться вопросом»?
Да, я таки переборщил. Подход в статье сам по себе имеет право жизнь, более того, конфигурирование фреймворков (хоть чужих хоть самописных) — зачастую действительно гораздо более поддерживаемый подход, чем клепание всего под конкретную задачу. Спасибо, что поправили — я полностью с Вами согласен.
Очень сильно не хватает пункта «Пользуюсь метапрограммированием давно, но то, что описано в статье — бред собачий».
Следим за руками.
Метаданные — это данные, описывающие данные
Метамодель — это модель, описывающая модели
Метаисследование — исследование, имеющее объектом другие исследования
…
Метапрограммирование — это парадигма программирования, построенная на программном изменении структуры и поведения программ.
Хм, «меня терзают какие то смутные сомнения» (с)
А почему бы не последовать за всем остальным миром и не пытаться переопределить существующие понятия (и метапонятия, хехе).
Метапрограммирование — это программы, которые генерируют программы. ВСЕ!
Скажем, старый добрый
#define MIN(a, b) ((a) < (b) ? (a) : (b))
Это метапрограммирование. Да, да, какой бы примитивной ни была сишная макросистема — она генерирует новый код в месте использования (который потом может быть а может и не быть «выброшен» оптимизатором) и поэтому является метапрограммированием.
template <typename T> T min(T lhs, T rhs) {return lhs < rhs ? lhs : rhs; }
Это тоже метапрограммирование. Для каждого типа порождается (инстанцируется) новая функция
И даже уродство вроде
$db->query("select * from users where name='" . $user . "'")
Это, очевидным образом, тоже метапрограммирование.
Логичнее всего метапрограммирование выражено в Scheme. Компиляция явным образом разделена на метауровни. Уровень meta-0 — это то, что, собственно, компилируется. Meta-1 — уровень который может генерировать код для meta-0 (собственно, макросы), meta-2 — уровень генерирующий код для meta-1 (макросы, генерирующие макросы). Количество метауровней стандартом не регламентируется.
Ну а то, что описано в статье — это именно, что «бред собачий» и попытка переопределить существующую терминологию
Здравствуйте, спасибо за интересные статьи, но мне кажется, что напрасно Вы пытаетесь «натянуть» реляционную модель на ваши данные.
Наиболее близким представлением, опять же, на мой взгляд, является triplestore/RDF, то есть тройки субъект-предикат-объект. Каждая такая тройка задает одно ребро направленного графа «знаний».
Да там половина топ-менеджмента такая.
Что же до стереотипов, мне кажется, что здесь — один из немногих случаев, когда под идиотское «ну тупы-ы-ы-ы-ые» вполне уместно идиотское «сперва добейся».
Еще раз, для самых бестолковых. Есть 2D принтер, у которого есть LPT разъем. Требуется подключить к свежекупленному лэптопу, у которого в принципе нет LPT порта. Ололо, Линукс «не встроил» поддержку 2D принтеров — «заявил о поддержке пары принтеров, причем сам принтер должен появляться как устройство».
для случая 3D принтеров это несколько слишком сильное заявление, поскольку и свойства материала и свойства «печатающей головки» могут несколько меняться
Вы осознаете, что свойства головок и материалов «обычных» 2d принтеров тоже очень сильно различаются. Для того и существуют АБСТРАКЦИИ. Драйвер реализует один абстрактный интерфейс, приложение — другой. И, бац, они автоматически умеют работать друг с другом.
Перестаньте болтать ерундой.
ВЫ либо прикидываетесь, либо действительно не имеете ни малейшего представления о том, для чего в операционных системах существуют драйверы (и, в частности, модели драйверов для классов устройств). Возможно, Вам будет проще понять по аналогии:
вот я — ТП
Скачал(а) Линукс, купил(а) принтер (обычный 2d), втыкаю в USB… и ничего. Значит ли это, что линукс не имеет модели драйверов для 2d принтеров или, может быть, это всего лишь означает, что ОС не имеет драйверов под данный конкретный принтер?
Windows 8.1 имеет встроенный пайплайн для 3d печати (таким образом, производителям устройств и прикладного ПО не нужно ничего знать друг о друге — только об интерфейсах ОС) — и от Вашего отношения к этому факту, сам факт не изменится.
Вот как описывает ее функции википедия:
The executive functions of the frontal lobes involve the ability to recognize future consequences resulting from current actions, to choose between good and bad actions (or better and best), override and suppress socially unacceptable responses, and determine similarities and differences between things or events.
Способность распознавать будущие последствия текущих действий, выбирать между хорошим и плохим (или хорошим и лучшим) и умение находить абстракции (определять сходства и различия между вещами и событиями) — это вообще основа программирования. Можно сказать, что это, фактически, дистиллированное программирование.
А теперь, самое главное: «In humans, the frontal lobe reaches full maturity around only after the 20s» (у человека фронтальная кора полностью развивается после 20-ти лет — в статье ссылка на МРТ исследования реальных людей). Полное развитие, в общем то и не нужно для начала обучению программированию. Лобная кора развивается «достаточно» примерно ко времени «полового созревания» — те самые 12 лет.
Начнем с того, что автор пытается использовать низкоуровневое API и с удивлением обнаруживает, что оно… НИЗКОУРОВНЕВОЕ. Ну явно какие то дебилы писали. Использовать к примеру StartKernelTrace было бы можно, но как же тогда писать возмущенную статью. Если нужно более гибкое, но высокоуровневое API, можно использовать WPRControl (это тем более удобно, что тот же самый профайл можно будет запускать отдельно от собственной программы, а также менять состав собираемого лога без перекомпиляции — простой правкой конфигурационного файла).
Возмущение по поводу GUID вообще не в кассу. Здесь человеку нужно почитать о размещении значимых типов в C/C++ и единицах трансляции. Отличие INITGUID в том, что оно заставляет макрос DEFINE_GUID определять переменную (с выделением места в data секции для текущей единицы трансляции). По умолчанию (без INITGUID) данный макрос только объявляет (extern) переменную и предоставляет линкеру позаботиться о поиске определения (и, соответственно, размещения). Да-да, тупой Майкрософт «не смог найти способ внедрить их в заголовочные файлы (я могу насчитать несколько возможных способов, но, я полагаю, им не понравился не один из них)». На минуточку, здесь прозвучало предложение внедрять ОПРЕДЕЛЕНИЯ переменных (то есть выделение памяти для них) в заголовочне файлы ПО УМОЛЧАНИЮ. Конечно же, что может быть лучше заголовочных файлов с непустым вкладом в объектный файл? Ведь всегда можно налепить сверху хак вроде __declspec(selectany). Динамически выделяемую память, кстати, за собой тоже можно не чистить — достаточно просто прибить процесс и никто и не заметит утечек.
Возмущение по поводу ограниченного количества «флагов» в «kernel trace» провайдере забавны в свете того, что вот прямо сейчас вон там из 33, а «xperf -providers K» из Windows 8.1 SDK выдает список из 55 возможных флагов (это только публичная часть — возможно для «внутреннего потребления» их еще больше).
Предложенные варианты API забавны, ибо совершенно не попадают в сценарии использования ETW. Самое главное требование — низкая стоимость (околонулевая в случае, когда на событие никто не подписан и не более пары тысяч тактов, если подписан). При этом необходимо обеспечить возможность работы на *всех* IRQL (к примеру есть возможность писать в лог с IPI или CLOCK уровней, когда не только диспетчер не работает, но и большинство прерываний от устройств замаскированы). При этом все должно продолжать работать на многопроцессорных системах (из чего следует, что использование любых видов блокировок запрещено). Необходимо иметь возможность писать в кольцевой буфер (подумайте о флаге REFSET который трейсит все ОБРАЩЕНИЯ к памяти — хотите ли Вы в пользовательском режиме обрабатывать все такие события? В реальном времени?). Нужно иметь возможность начать лог до старта не только первого пользовательского процесса, который мог бы в ETWBeginTrace, а и до старта, собственно, ядра (да-да, winload умеет писать в ETW лог — предлагаю угадать как он это делает). Это только то, что пришло в голову прямо сейчас (мне даже представлять не хочется этап сбора требований в команде, которая разрабатывала этот компонент).
Собственно разделение сессий трассировки и потребителей трейса — вполне логичное следствие даже тех поверхностных требований, которые я уже привел. Поэтому и разделение StartTrace/OpenTrace — трейс запускается в сессии, а потреблять его может кто угодно (собственно, это ОСНОВНОЙ режим работы API — запуск трейса xperf/wpr на тестовой/проблемной машине и анализ лога на машине разработчика — я даже и не припомню когда бы мне пришлось сталкиваться с «realtime» трейсами).
Это даже комментировать не хочется. Ну конечно, канал «утечки» системной информации не имеет никакого значения для того, что требуется права администратора. Это было сделано исключительно для того, чтоб никто не мог вырвать сессию.
Кстати, по поводу «безумия». SystemTraceProvider и его же сессия — действительно выделены в отдельный специальный случай, что выглядит несколько некрасиво. Но, как и многие другие компромиссы, этот был сделан ради производительности — уж сильно много всего трейсит данный провайдер. Для остальных провайдеров API более универсально, но за универсальность, как обычно платят производительностью. Начиная с Win8, его можно включить до восьми раз. В принципе в моей практике почти всегда хватало одного. Исключения — это всякие когда запущен какой нибудь Process Explorer/Process Hacker (я активно исследую что-либо) и при этом мне хочется собрать трейс. Если включить эти случаи, то мне изредка нужно 2-3 сессии. И при этом я, в отличие от автора статьи, действительно не один год провел ковыряясь в производительности.
Во-первых я не заявлял ни того ни другого.
Я лишь отметил, что профиль распространения «настоящей малвари» (в соответствии с определением моего оппонента) несколько отличается от «общеизвестного». Пожалуйста, не приписывайте мне заведомо ошибочных суждений
Да, но ведь речь идет о «абы как» (хорошо если по умолчанию, но ведь полно ж твикеров, зверсиди, отключателей апдейтов для того чтоб «активация не слетела» и прочих — и они все попадают в общую статистику) настроенном Windows и о Linux (я говорю обобщенно о всем стеке, а не только о ядре), который настраивают хорошо оплачиваемые профессионалы с многолетним стажем.
Если же сравнивать «apples to apples» — сервера на Linux против серверов на Windows, то есть очень существенный перекос (гораздо выше, чем можно было бы ожидать просто от распространенности технологий, даже учитывая нелинейность зависимости). В прошлый раз, когда я просил показать мне high-profile взломы серверов на основе Windows, то всплыл только T-Mobile. При том, что на Linux кого только не ломали — и kernel.org и linuxfoundation и savannah.gnu.org и redhat.com (дважды) и mysql.com и кучу других, не говоря уже о просто коммерческих/вебдваноль вендорах типа target, gawker, sony, hyper-vm и пр…
На всякий случай: я не спорю, что Linux можно захарденить практически до непробиваемости (к примеру, я не думаю, что Google будет так или иначе взломан в обозримом будущем), но все таки это весьма нетривиально (не думаю, что у RedHat или kernel.org не хватило денег либо опыта в Linux для того, чтобы предотвратить взломы).
Про повышение цены вопроса согласен.
Вы очень сильно ошибаетесь. Причем в обеих оценках.
Кстати, хром/хромиум и IE используют очень качественные песочницы для запуска недоверенного кода. Исследователи оттуда периодически выбираются, но для злоумышленников это пока нецелесообразно.
Разные пользователи помогут от части атак, но далеко не ото всех. У того же KeePass есть опция, которая спрашивает мастер пароль в другой сессии — фактически проникнуть туда без повышения привилегий все равно нельзя. Собственно, эта опция помогает противостоять подавляющему большинству атак, против которых помогает отдельный пользователь и не помогает в случаях, когда отдельный пользователь тоже бессилен. И при этом secure desktop практически не влияет на удобство использования keepass.
chroot — небезопасен. Его нельзя использовать для ограничения доступа. Вот пара ссылок. По большому счету я бы и «настоящей» виртуализации не слишком бы доверял, если бы меня паранойя замучила («не слишком» — это только в случае запуска недоверенного кода на доверенном хосте, но в виртуалке, если же хост потенциально скомпрометирован, то любая виртуалка на нем точно также скомпрометирована). Только физическая изоляция — только хардкор.
Здесь опять же нужно моделировать угрозы. Если речь идет о массовом сборе паролей, то вполне можно допустить, что когда-нибудь (когда это станет экономически целесообразно) будет использоваться модуль автоматического вытаскивания паролей из популярных менеджеров паролей. Простая обфускация keepass в этом случае отлично помогает, хотя, как Вы отметили, и является security through obscurity. Делать же постоянные снимки буфера обмена да еще и скриншоты — попросту не масштабируется и, соответственно, такие угрозы в ближайшем будущем ожидать не стоит.
Второй возможный вид угрозы — таргетированная атака конкретно на Вас лично. Ну в таком случае вообще никакая ОС общего назначения не поможет.
Желаю удачи, но все же повторюсь со своей рекомендацией «хотя бы поверхностно поинтересоваться вопросом».
Но давайте все же поговорим предметно. Возьмем класс
реальное малваре (множество включающее вирусы), а не «пользователь скачал хз что и откуда и сам установил с максимальными правами»
и попробуем «хотя бы поверхностно поинтересоваться вопросом». В контексте данного топика нас интересуют только то «реальное малваре», которое привело либо к крупной утечке пользовательских данных либо к крупной эпидемии (пусть будет 0.5% популяции)
В качестве «ОС, распространенных на сегодня» возьмем Windows, OSX и Linux (используется в пределах погрешности измерения на «десктопах», но довольно широко распространена в некоторых других сегментах). Также возьмем мобильные ОС: Android, iOS и Windows Phone
1. Мобильные ОС можно сразу исключить из рассмотрения — ни по одной из платформ я не смог найти достоверной информации по «реальному малваре», которое бы привело к «реальному ущербу»
2. Windows — за последние 15 лет (включая Summer of Worms) я не смог обнаружить ни единого случая, когда «реальное малваре» (да-да, то которое может заразить полностью пропатченную ОС без явного согласия пользователя), которое бы привело к «реальному ущербу». Искренне надеюсь на Вашу помощь. Очень рекомендую «поверхностно поинтересоваться вопросом» перед тем как предлагать варианты.
3. OSX — есть как минимум Flashback который использовал 0-day уязвимость в «Apple Java» (на тот момент Sun Java была пропатчена, но Apple распространяла JRE по собственным каналам и в этом канале распространения патча еще не было — это на тот момент была историческая норма для Apple). Flashback привел к заражению 600к машин, что на тот момент составляло более процента популяции.
4. Linux. Здесь примеров полно. От червей в роутерах до крупных утечек данных (их десятки — могу привести еще, но можно ограничиться и утечкой 160 миллионов профайлов за раз).
Хотелось бы услышать про Ваш взгляд на то, что такое «нормальная ОС». Заранее спасибо
Следим за руками.
Метаданные — это данные, описывающие данные
Метамодель — это модель, описывающая модели
Метаисследование — исследование, имеющее объектом другие исследования
…
Метапрограммирование — это парадигма программирования, построенная на программном изменении структуры и поведения программ.
Хм, «меня терзают какие то смутные сомнения» (с)
А почему бы не последовать за всем остальным миром и не пытаться переопределить существующие понятия (и метапонятия, хехе).
Метапрограммирование — это программы, которые генерируют программы. ВСЕ!
Скажем, старый добрый
Это метапрограммирование. Да, да, какой бы примитивной ни была сишная макросистема — она генерирует новый код в месте использования (который потом может быть а может и не быть «выброшен» оптимизатором) и поэтому является метапрограммированием.
Это тоже метапрограммирование. Для каждого типа порождается (инстанцируется) новая функция
И даже уродство вроде
Это, очевидным образом, тоже метапрограммирование.
Логичнее всего метапрограммирование выражено в Scheme. Компиляция явным образом разделена на метауровни. Уровень meta-0 — это то, что, собственно, компилируется. Meta-1 — уровень который может генерировать код для meta-0 (собственно, макросы), meta-2 — уровень генерирующий код для meta-1 (макросы, генерирующие макросы). Количество метауровней стандартом не регламентируется.
Ну а то, что описано в статье — это именно, что «бред собачий» и попытка переопределить существующую терминологию
Наиболее близким представлением, опять же, на мой взгляд, является triplestore/RDF, то есть тройки субъект-предикат-объект. Каждая такая тройка задает одно ребро направленного графа «знаний».
Что же до стереотипов, мне кажется, что здесь — один из немногих случаев, когда под идиотское «ну тупы-ы-ы-ы-ые» вполне уместно идиотское «сперва добейся».
Вы осознаете, что свойства головок и материалов «обычных» 2d принтеров тоже очень сильно различаются. Для того и существуют АБСТРАКЦИИ. Драйвер реализует один абстрактный интерфейс, приложение — другой. И, бац, они автоматически умеют работать друг с другом.
Еще раз, перестаньте болтать ерундой.
ВЫ либо прикидываетесь, либо действительно не имеете ни малейшего представления о том, для чего в операционных системах существуют драйверы (и, в частности, модели драйверов для классов устройств). Возможно, Вам будет проще понять по аналогии:
вот я — ТП
Скачал(а) Линукс, купил(а) принтер (обычный 2d), втыкаю в USB… и ничего. Значит ли это, что линукс не имеет модели драйверов для 2d принтеров или, может быть, это всего лишь означает, что ОС не имеет драйверов под данный конкретный принтер?
Windows 8.1 имеет встроенный пайплайн для 3d печати (таким образом, производителям устройств и прикладного ПО не нужно ничего знать друг о друге — только об интерфейсах ОС) — и от Вашего отношения к этому факту, сам факт не изменится.
Вот как описывает ее функции википедия:
The executive functions of the frontal lobes involve the ability to recognize future consequences resulting from current actions, to choose between good and bad actions (or better and best), override and suppress socially unacceptable responses, and determine similarities and differences between things or events.
Способность распознавать будущие последствия текущих действий, выбирать между хорошим и плохим (или хорошим и лучшим) и умение находить абстракции (определять сходства и различия между вещами и событиями) — это вообще основа программирования. Можно сказать, что это, фактически, дистиллированное программирование.
А теперь, самое главное: «In humans, the frontal lobe reaches full maturity around only after the 20s» (у человека фронтальная кора полностью развивается после 20-ти лет — в статье ссылка на МРТ исследования реальных людей). Полное развитие, в общем то и не нужно для начала обучению программированию. Лобная кора развивается «достаточно» примерно ко времени «полового созревания» — те самые 12 лет.