Увы, дроппера мне не встречалось. Но даже не в дроппере дело. В BootExecute он, AFAIK, не прописывается, он вроде драйвер. Да и не уверен я, что он из BootExecute запустится как exe, когда у него флаг DLL в хедере установлен.
Честно признаться, я сам в нем не ковырялся. Рекомендую ознакомиться с подробностями тут, здесь, еще немного там.
Ну, не скажите. Без знания ассемблера абсолютно нечего делать в, скажем, геймдеве. И это не единственная такая область.
И, кстати, демок именно на С++, а не С, я не встречал.
Повторюсь - непосредственно с руткитами там очень сложно. Проще спамбота гнать в юзермод - одна фигня, пока его еще удалят, он успеет не один мегабайт спама разослать.
Не надо меня обзывать виндузятником. =) Просто вопрос распространения под Linux довольно труден, одна установка всего из пакетов уже сильно затрудняет распространение.
Не путайте, рут - это тоже юзер-левел. И права рута, если постараться, можно получить методами а-ля social engineering.
Заплатки, не заплатки... Про уровень ядра - тут другая проблема. В ядре linux, AFAIK, значительно сложнее поиск необходимых руткиту структур и функций. Плюс к этому, руткиту не помогут hardcoded адреса чего-то ему необходимого, ибо адреса могут меняться с версией ядра.
Знаете, веселее был бы бенчмарк не на одном 4-хядернике, а на, скажем, 20 таковых в кластере. Или даже не в кластере, а просто в локалке. Ну и, разумеется, крайне интересно было бы бы посмотреть на С-реализацию под это все оптимизированную.
Ну, это само собой разумеется. Я вообще изначально старался избегать вопроса производительности, чтобы избежать конкретики, ибо производительность уже зависит в-основном от реализации.
Простите, а что есть императивность и декларативность в случае интерфейса? Точнее, являются ли они чем-то кроме методики реализации его?
Веб-фреймворк - это уровень абстракции, "учитывать и использовать" это его задача. Причем тут непосредственно UI, о которых изначально шла речь?
Это скорее интерфейс преобразования.
Это интерфейс связи между UI и серверной частью. Формально говоря, это даже интерфейс связи между веб-сервером и непосредственно обаботчиком. Повторяюсь, причем здесь собственно UI?
На уровне Erlang VM, опять таки, это должно быть очень оптимизировано. Разницы-то особой и нет, что фреймворк поймает сообщение от ОС и вызовет метод объекта, что фреймворк отправит соответственное сообщение процессу.
Это сильно зависит от их количества.
Которое уже зависит "от задачи и того как реализовано".
Кстати, еще интересно, что "тяжеловеснее" - множество процессов, обменивающихся сообщениями, или множество объектов, обменивающихся вызовами методов. =)
А можно более конкретно? Что вы назовете аналогом CGI в том же QT? Я просто не могу провести аналогию... Вообще, AFAIK, CGI - это стандарт имеющий мало отношения к непосредственно интерфейсу пользователя, это интерфейс связи.
Далее, латентность. Как она зависит от парадигмы языка реализации интерфейса? Латентность, в данном случае, вопрос лишь канала связи.
http протокол...
А это-то причем? Для кода UI это все закрыто бесчисленными абстракциями.
вызов метода объекта по событию будет менее трудоемко
Интересный вопрос. По идее, реализация приема сообщения и реакции на него в Erlang должна быть просто безукоризненной - это ключевой элемент языка. А принципиальных различий в этих методиках, AFAIK, нет.
Процессы вместо объектов, судя по все тем же стандартным примерам, нисколько не усложняют код, он остается абсолютно прозрачным и логичным.
Процесс плодить для каждого примитива не придется. Значительная часть примитивов обслуживается фремворком или ОС.
657243320380
388830538744
143052496539
763997159171
920381875736
123193923742
769590207023
182063077510
441323866986
619115866961
948615415426
397192000093
168255392242
234434004604
430100461798
Честно признаться, я сам в нем не ковырялся. Рекомендую ознакомиться с подробностями тут, здесь, еще немного там.
Вдруг вам покажется интересным... Вы случайно Rustoсk.C не хотите поковырять для саморазвития? =) Вот образец, пароль 000.
И, кстати, демок именно на С++, а не С, я не встречал.
Заплатки, не заплатки... Про уровень ядра - тут другая проблема. В ядре linux, AFAIK, значительно сложнее поиск необходимых руткиту структур и функций. Плюс к этому, руткиту не помогут hardcoded адреса чего-то ему необходимого, ибо адреса могут меняться с версией ядра.
Это только пока. Когда станет популярной среди обычных юзверей - появятся.
Приходилось, хотя значительно реже десктопных.
Простите, а что есть императивность и декларативность в случае интерфейса? Точнее, являются ли они чем-то кроме методики реализации его?
Веб-фреймворк - это уровень абстракции, "учитывать и использовать" это его задача. Причем тут непосредственно UI, о которых изначально шла речь?
Это интерфейс связи между UI и серверной частью. Формально говоря, это даже интерфейс связи между веб-сервером и непосредственно обаботчиком. Повторяюсь, причем здесь собственно UI?
Который рискует проиграть в других факторах - скорость и стоимость разработки, надежность, масштабируемость...
Хотя это все уже вопрос реализации.
Значит, он еще просто не популярен в этой отрасли. Кстати, наверняка, зря не используют. В моем понимании, Erlang там очень подойдет.
На уровне Erlang VM, опять таки, это должно быть очень оптимизировано. Разницы-то особой и нет, что фреймворк поймает сообщение от ОС и вызовет метод объекта, что фреймворк отправит соответственное сообщение процессу.
Которое уже зависит "от задачи и того как реализовано".
Кстати, еще интересно, что "тяжеловеснее" - множество процессов, обменивающихся сообщениями, или множество объектов, обменивающихся вызовами методов. =)
А можно более конкретно? Что вы назовете аналогом CGI в том же QT? Я просто не могу провести аналогию... Вообще, AFAIK, CGI - это стандарт имеющий мало отношения к непосредственно интерфейсу пользователя, это интерфейс связи.
Далее, латентность. Как она зависит от парадигмы языка реализации интерфейса? Латентность, в данном случае, вопрос лишь канала связи.
А это-то причем? Для кода UI это все закрыто бесчисленными абстракциями.
Интересный вопрос. По идее, реализация приема сообщения и реакции на него в Erlang должна быть просто безукоризненной - это ключевой элемент языка. А принципиальных различий в этих методиках, AFAIK, нет.
Процессы вместо объектов, судя по все тем же стандартным примерам, нисколько не усложняют код, он остается абсолютно прозрачным и логичным.
Процесс плодить для каждого примитива не придется. Значительная часть примитивов обслуживается фремворком или ОС.