Исходное сообщение
"Фонд CПО выпустил полностью свободный вариант Linux-ядра 2.6..." Отправлено User294, 08-Ноя-10 22:57
А вот здесь то мы и приходим к одному довольно интересному моменту: что есть данные, а что есть код? Или где кончается жесткая логика и начинаются процессоры? Если по вашей логике рассуждать - ну тогда картинка в PNG - тоже "блоб" :). Можно ее рассмотреть как "программу" описывающую "виртуальной машине" (парсеру формата) как раскидать пиксели по монитору. И тем не менее, мы не считаем PNG программой. По той же причине по которой мы не считаем набор данных для записи в регистры программой. Это все-таки данные. Ну, как картинка в PNG. > не, блоб пусть будет в /lib/блобс Это нормальная идея, имхо :).Правда если заниматься перегибами типа борьбы с инициализацией регистров :))) - тогда туда надо будет и все PNG в системе позапихать заодно. Если уж все данные туда грузить. Кстати, начиная с какого объема - блоб, а с какого - не блоб? MOV R0, #1 - единичка в этом случае - блоб? А если так: MOV R0, #1 MOV R1, #2 Тут числа 1 и 2 - уже блоб, или еще нет? А можно и проабузить чуток: MOV R0, #1 MOV CustomReg29765, #127 ... MOV CustomReg47192, #183 ... и еще 5 кило в том же духе :) Кстати а вы никогда не думали что ранняя инициализация многих процов происходит именно в таком стиле и по другому там не очень то и катит? Давайте вы тогда определите - с какого размера блобы начинаются? А то MOV R0, #1 объявленный блобом "единичка" - это все-таки перегиб, да? Тогда окажется что даже в самой опенсорсной программе - блобы :) Кстати, а массивы - сразу запретим? Особенно инициализированные? Или ограничимся лимитом на их размер? :) Яркий пример - CRC Tables. Давайте теперь таблицы CRC еще с диска грузить начнем? Типа блоб, при том довольно таки жирный. И в ядре CRC есть. Чего б модулю не грузить свой "блоб" таблицы с диска?! :)

Ваше сообщение
Имя*:
EMail:	Для отправки ответов на email укажите знак ! перед адресом, например, !user@host.ru (!! - не показывать email). Более тонкая настройка отправки ответов производится в профиле зарегистрированного участника форума.
Заголовок*:
Сообщение*:	> А вот здесь то мы и приходим к одному довольно интересному моменту: > что есть данные, а что есть код? Или где кончается жесткая > логика и начинаются процессоры? Если по вашей логике рассуждать - ну > тогда картинка в PNG - тоже "блоб" :). Можно ее рассмотреть > как "программу" описывающую "виртуальной машине" (парсеру формата) как раскидать пиксели > по монитору. И тем не менее, мы не считаем PNG программой. > По той же причине по которой мы не считаем набор данных > для записи в регистры программой. Это все-таки данные. Ну, как картинка > в PNG. >> не, блоб пусть будет в /lib/блобс > Это нормальная идея, имхо :).Правда если заниматься перегибами типа борьбы с инициализацией > регистров :))) - тогда туда надо будет и все PNG в > системе позапихать заодно. Если уж все данные туда грузить. > Кстати, начиная с какого объема - блоб, а с какого - не > блоб? > MOV R0, #1 - единичка в этом случае - блоб? > А если так: > MOV R0, #1 > MOV R1, #2 > Тут числа 1 и 2 - уже блоб, или еще нет? > А можно и проабузить чуток: > MOV R0, #1 > MOV CustomReg29765, #127 > ... > MOV CustomReg47192, #183 > ... и еще 5 кило в том же духе :) > Кстати а вы никогда не думали что ранняя инициализация многих процов происходит > именно в таком стиле и по другому там не очень то > и катит? Давайте вы тогда определите - с какого размера блобы > начинаются? А то MOV R0, #1 объявленный блобом "единичка" - это > все-таки перегиб, да? Тогда окажется что даже в самой опенсорсной программе > - блобы :) Кстати, а массивы - сразу запретим? Особенно инициализированные? > Или ограничимся лимитом на их размер? :) Яркий пример - CRC > Tables. Давайте теперь таблицы CRC еще с диска грузить начнем? Типа > блоб, при том довольно таки жирный. И в ядре CRC есть. > Чего б модулю не грузить свой "блоб" таблицы с диска?! :)
	Введите код, изображенный на картинке: