Добавлю, что по крайней мере в программировании, бывают и вообще "дикие" модули -- никто не помнит точно для чего они и как действуют, но оставляют "а то вдруг что без него сломается".

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

Кстати, ещё пример в ту же копилку:
для CD-ROM существует последовательность символов (порядка 20 байтов), которая вызывает сбой чтения. То есть, прочитать эту последовательность с диска в принципе нельзя. Но, тем не менее, никто этого не исправляет, так как вероятность нарваться на неё очень мала, а переделывать протокол довольно затратно. Так и живёт масса СД устройств со "встроенной ошибкой". :)

Не знал. Занятно.

Пруфлинк?

Попробую поискать, но не гарантирую -- дело уже давненько было, года 4 назад. Статья была с подробным описанием. Насколько я помню, глюк состоял в том, что эта последовательность воспринималась контроллером как управляющая, при этом никаких возможностей для её "эскейпа" предусмотрено не было.

Нашёл (пять лет назад дело было) ;)
http://www.ixbt.com/optical/magia-chisel.shtml

Не наблюдаем ли мы тут начало новой формы жизни?

А кто её поймёт. Пожуём-увидим...
Обычно такие модули характерны для давно живущих продуктов; чем дольше живёт, тем больше их там...

Естественный отбор в чистом виде.

ну, все же - искусственный

Это зависит от того, как определять. Если всё, что под влиянием человека -- искуственное, тогда конечно, но при этом и городские комары, и крысы тоже типа "искуственно выведены", это странно. А если искуственным называть только такой отбор, который проводится специально и со вполне конкретной целью, тогда нет.

А, ну вот.

У Дарвина искусственный отбор - который бессознательно проводит человек на домашних животных. смысл там примерно в том. что у такого отбора и в самом деле есть цель - хотя проводящие отбор о ней явным образом не знают. А у естественного отбора никакой такой цели нет. Именно по этой причине в результате иск. отбора могут получаться породы, нежизнеспособные в природе - типа с короткими ногами etc.

Да нет. "Искуственный" - это когда кто-то целенаправленно отбирает. А тут отбор естественный. "Само получилось, не виновата я".

Бессознательный искусственный отбор - обычное дело. "Не виновата - а отвечай"

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

(с чувством) да, очень печальны

Но как печальны бы были результаты регулирования!

в том смысле, что для посылки Вам ответа я должен был бы получить 3 (три) справки. что это не коммерческое послание и мне не нужно на него получать разрешение?

И не тольо. Даже сейчас существуют накладки. Например, мой IP был внесён в блэк-лист одного крупного объединения, с которым я работа. В связи с этим понадобилось несколько дней разобраться в чём дело.
А при массированной охоте на ведьм ошибок будет масса.
Так что будет огромная пирамида проблем разрешительного толка, и не меньшая - пеницитарного.
Причём на всё это наложится проблема распознавания - что считать спамом.
Поскольку решения будут принимать компьютеры, а аппелировать придётся к бурократам - тут-то мы и попляшем.

я понял. печальные результаты ждут нас при любом решении.

Ну, мы можем выбирать между более или менее печальными результатами. Это как с воспитанием детей: мы можем отшлёпать их сами, а можем передать в руки полицейского офицера.

маленькая плата за каждый email в принципе должна работать: я полылаю от силы десять emailов в день, а что бы прокормить спаммера, нужно послать десять миллионов. как только возникнет надежная система маленьких анонимных электронных платежей, emailы начнут приходить с марками.

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

ну зачем же сразу так пессимистично! с обыкновенной почтой простейшая система с одним тарифом неплохо работает, не больше двух-трех реклам в день, и с довольно высокой вероятностью полезности... спам - он потому и раздражает, что по определению не целенаправленный. ну, а "более дорогие тарифы, которые снижают число спама" называются секретарями :)

конечно, всегда неприятно, когда бесплатное становится платным, кто ж спорит...

Ну, с одной стороны да. С другой - железки вполне себе становятся эффективны (для начала задумаемся о слове "эффективный" - есть разные методы оценки). По простому наблюдению (например, лазерные принтеры) - проблем вообще нет. Новые принтеры дешевеют, не ломаются, обеспечивают большую скорость и качество. Потроха уже никого не интересуют (ведь оно не ломается).

С софтом сложнее, т.к. софт постепенно захватывает всё более сложные функции (организационные) и оценивать эффективность сложно (то, что раньше делалось просто, теперь сложно и трудно - но ведь зато оно делает ещё и ...).

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

Ну, хочется включить технофрический коммунизм и заявить о некоем техническом идеале. Но мы-то живём в реальном мире.

И, например, возможность легко менять картридж (т.е. использовать для замены картриджа кого угодно) значит больше, чем, например, эффективность подачи тонера. До тех пор, пока оно нормально печатает, удобство обслуживания значит больше, чем техническое совершенство.

да не надо от меня защищать машинны, я не собираюсь ломать их больше, чем они уже сломаны.
Просто мысль забавная. раньше не думал, хотя должен был бы.

Иначе там будут экономические оценки эффективности. что. простите, даже упоминать скучно.
Простите, не затруднит ли Вас рассказать более подробно о критериях эффективности машин, не являющихся в конечном счете денежными?

Длина программы в байтах плюс время работы в тактах. С коэффициентами и поправками для различных архитектур. Это для программ, для машин опять таки время выполнения задачи (если зависит от конструкции), количество использованных в конструкции материалов, количество необходимой энергии.

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

Длина программы в байтах плюс время работы в тактах.
Этот критерий является как раз сводимым к денежному: циклы процессора и память стоят денег. ( кстати, Вы забыли что в большинстве случаев важен суммарный расход памяти, а не только длине кода )
Но если так определять то, само собой, весь современный софт хорошо если на процент по эффективности вытягивает, что отдельно по скорости, что по размеру.
Это очень сомнительное утверждение.
Возьмем самый очевидный пример - домашний/оффисный настольный компьютер.
Предположим что сегодня XP/Office требует 512 мегабайт памяти, а Линукс в состоянии предоставить сходную функциональность в 256 мегабайтах. Вы утверждаете, если понимать Вас буквально, что ту же функциональность и гибкость можно предоставить на основе компьютера с 3 мегабайтами оперативной памяти, у меня же это утверждение вызывает вполне обоснованные сомнения.

Этот критерий является как раз сводимым к денежному
---
Я очень за Вас рад, что вы умеете сводить любые критерии к денежным. В данном случае я не вижу причин это делать, разве что если хочется получить эффективность в виде одного числа, соответственно придётся откуда-то брать коэффициенты для объединения разных параметров, вроде размера образа, скорости работы и да, размера working set. Но я бы предпочёл всё-таки не делать этого, потому что тогда ведь придётся ещё и трудозатраты (точнее, зарплату специалистам) учитывать, и маркетинг, и всё остальное, и картина неоправданно запутается.

Вы утверждаете, если понимать Вас буквально, что ту же функциональность и гибкость можно предоставить на основе компьютера с 3 мегабайтами оперативной памяти, у меня же это утверждение вызывает вполне обоснованные сомнения.
---
Если, опять же, ставить задачу "реально" -- до какого размера могут ужать working set линукса+опеноффиса тысяча разработчиков за десять лет, то да, сомнительно, конечно. Если же интересоваться, как выглядит эталонный, идеальный результат, то, как мне кажется, цифра вполне соответствует действительности. Я исхожу из своего опыта программирования на ассемблере и разглядывания разнообразных демок (в смысле, 64k demo, например). В частности, kkrieger (http://www.theprodukkt.com/kkrieger) довольно хорошо показывает, сколько функциональности можно запихать в 96 килобайт, если задасться именно такой целью.

Я очень за Вас рад, что вы умеете сводить любые критерии к денежным.
Любые - не могу. Эти как раз могу, и это относительно не сложно. Во всяком случае, не сложнее чем сравнивать наборы чисел разной размерности вроде длины кода и оценой времени выполнения.
В данном случае я не вижу причин это делать, разве что если хочется получить эффективность в виде одного числа, соответственно придётся откуда-то брать коэффициенты для объединения разных параметров, вроде размера образа, скорости работы и да, размера working set. Но я бы предпочёл всё-таки не делать этого, потому что тогда ведь придётся ещё и трудозатраты (точнее, зарплату специалистам) учитывать, и маркетинг, и всё остальное, и картина неоправданно запутается.

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

1. Если, опять же, ставить задачу "реально" -- до какого размера могут ужать working set линукса+опеноффиса тысяча разработчиков за десять лет, то да, сомнительно, конечно.
2. Если же интересоваться, как выглядит эталонный, идеальный результат, то, как мне кажется, цифра вполне соответствует действительности.

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

Я исхожу из своего опыта программирования на ассемблере и разглядывания разнообразных демок (в смысле, 64k demo, например).

В 64К можно вместить многое, но вот универсальную, многозадачную, аппаратно-независимую ОС с поддержкой графики, сети и прочей аппаратуры, плюс графический пакет оффисных аппликаций - нельзя.

Нет, эффективность программы (или другой инженерной конструкции) -- это эффективность программы и не более того, совершенно незачем включать в неё эффективность процесса разработки и прочее. Если Вы хотите говорить про общую эффективность жизненного цикла программы, говорите про общую эффективность жизненного цикла программы, а не про эффективность программы, иначе ничего хорошего у Вас не выйдет. Например, когда Вам захочется разбить общую эффективность жизненного цикла программы (которую вы желаете называть "эффективностью программы") на части, то у вас получится отдельно эффективность разработки, отдельно эффективность использования, которая в свою очередь определяется количеством пользователей, важностью их задач и -- сюрприз, сюрприз -- эффективностью программы. Если вы и то, что было наверху, будете называть эффективностью программы, то в этот момент у вас переполнится стек, если не случится ещё чего похуже, как с Шалтаем-болтаем, который очень любил приписывать словам свой личный смысл, а потом внезапно разбился!


Из этих двух утверждений только одно может быть верным
---
Почему?

Напомню, кстати, что изначально шла речь не о 64к, а о трёх мегабайтах, и не кода, а используемой памяти.

Я привёл пример с целью продемонстрировать наглядно, как функциональность, для получения которой обычному программисту понадобилось бы несколько десятков мегабайт (и кода, и ресурсов) укладывается в 96к. Вы посмотрите, посмотрите на ккригер, всё же, чтобы не говорить о сферических конях. Так вот, вполне резонно предположить, что коэффициент возможного сжатия при увеличении размера сжимаемых данных как минимум не уменьшается. Увеличивается время, необходимое реальным программистам, чтобы добиться нужного эффекта, но мы его договорились пока не рассматривать, правда?

Нет, эффективность программы (или другой инженерной конструкции) -- это эффективность программы и не более того, совершенно незачем включать в неё эффективность процесса разработки и прочее.
Я не могу с Вами согласиться. Эффективность любой инженерной конструкции измеряется как способность выпонять определенные полезные функции ценой V с издержками размерами E. Чем выше соотношение V/E, тем выше эффективность продукта.
Длина же кода/требования к памяти/время выполнения есть мера оптимизации программы, входящая в эффективность продукта только одним параметром. Хуже того, оптимизация поодному из этих параметров в большинстве случаев ведет к ухудшению иных показателей, это такой известный и неизбежный компромисс между размером необходимой памяти и временем выполнения.
Далее, как Вы справедливо отмечаете, оптимизация программы является лишь одной из составляющих оценки эффективности продукта; для весьма широкого класса проектов стоимость разработки критичнее степени оптимизации ( вот видите, опять денежное измерение, куда же от него деться ).
Почему?
Потому что никакми человечески силами невозможно впихнуть универсальную, аппаратно- независимую, моногозадачную, графическую операционную среду вместе с оффисным пакетом в 3 Мб памяти, хоть 10,000 человеко-лет потрать, хоть 100,000.
Я привёл пример с целью продемонстрировать наглядно, как функциональность, для получения которой обычному программисту понадобилось бы несколько десятков мегабайт (и кода, и ресурсов) укладывается в 96к. Вы посмотрите, посмотрите на ккригер, всё же, чтобы не говорить о сферических конях.
Здается мне, этот kkreiger как раз и есть сферический конь в вакууме. Источников они не дают, так что где именно они срезают углы, понять затруднительно. Но вот один только клон OpenGL занимает 15 Мб.

Отлично, давайте пока называть эффективностью программы/конструкции именно то, что предложил я, за неименем лучшего термина для обозначения этой штуки и потому, что обсуждается в посте и комментариях что-то очень похожее на неё, и закончим с этой ветвью дискуссии?

Почему?
Потому что никакми человечески силами невозможно впихнуть универсальную, аппаратно- независимую, моногозадачную, графическую операционную среду вместе с оффисным пакетом в 3 Мб памяти, хоть 10,000 человеко-лет потрать, хоть 100,000.
---
Почему?


где именно они срезают углы
---
А какая разница? Есть факт: если бы среднестатистический программист захотел написать такую штуку, она бы скорее всего не влезла в девять мегабайт, вместе со всеми текстурами, модельками и прочими ресурсами. Согласны?

При чём тут клоны опенГЛ, написанные среднестатистическими программистами, мне не очень понятно. Ну да, они большие. И линукс большой, и опеноффис, и винда с офисом. Мы же как раз и обсуждаем, во сколько раз их можно уменьшить.

Да, я, кстати, понимаю разницу между уменьшением существующей программы и созданием маленькой программы, демонстрирующей некоторую на первый взгляд (а так же на второй и третий) функциональность _похожую_ на функциональность некоторой другой, большой программы. Но это не очень важно, в данном случае, потому что нам не нужна точная копия винды, вместе со всеми её глюками, нам похожей функциональности вполне достаточно.

Я прекрасно понимаю, что моё утверждение кажется контринтуитивным. Ну и что? Я думаю, если бы я дал Вам вначале ссылку на ютуб с роликом геймплея, то и в то, что эта штука может уложиться в 96к, Вы не поверили бы. И всё же она существует.

Окей, окей. Правда, меня несколько смущает тот факт, что "эффективность продукта" в Вашем понимании не принадлежит продукту, поэтому как-то странно звучит, "эффективность чья? Продукта. А принадлежит кому? Процессу его изготовления", ну да ладно, надоело уже немножко, если честно.

Если часть этих предположений верна, средний программист уложил бы такую программу не в 96к, а в 196.
---
Ну нет, это не так.

Я видел текстовый редактор, предоставляющий 60 примерно процентов фунцкиональности Emacs'а, уложенный в 120К.
---
Отлично, вот видите, Вы сами себя опровергаете. Обычный емакс, как я могу видеть, весит 37 мегабайтов, то есть в 300 раз больше. Неужели Вы считаете, что оставшиеся 40% функциональности (в Вашей формулировке) никак не могут быть ужаты на те же два порядка? А почему?

Ещё раз повторю, на всякий случай: чем больше программа, тем легче её сжимать, насколько я понимаю.

Отлично, вот видите, Вы сами себя опровергаете. Обычный емакс, как я могу видеть, весит 37 мегабайтов, то есть в 300 раз больше. Неужели Вы считаете, что оставшиеся 40% функциональности (в Вашей формулировке) никак не могут быть ужаты на те же два порядка? А почему?
Emacs просто продукт иного класса, на эти самые два порядка более универсальный. Чудес не бывает, и при всем уважении к авторам Микромира, они не в 100 раз сильнее Столлмана.
Oпять же сравним Mesa и эту Вашу замечательную игрушку. Если взять игрушку, спортировать на Mesa с той же компресией текстур и статически слинковать, получится 15 с небольшим мегабайт, как раз те самые два порядка. Но сравнение это будет не вполне корректным, не так ли?
Ещё раз повторю, на всякий случай: чем больше программа, тем легче её сжимать, насколько я понимаю.
Вот эта мысль от меня ускользает.

То есть 40% функциональности это два порядка универсальности? Что-то я в Ваших утверждениях запутываюсь уже. И, это, как измеряется универсальность? С функциональностью понятно, берём, например, Windows API, это функциональность. Если некто утверждает, что уложил реализацию винапи в три мегабайта, это можно легко проверить. А "универсальность" это что?


Меня начинает глодать нехорошее подозрение, что Вы сейчас начнёте утверждать, что виндовс вы рассматривать вообще не хотите, а от аналога линукса с опеноффисом будете требовать ещё и всех возможности подправлять сурцы. Очень забавно получится, если так.


К чему Вы завели разговор про портирование, я не понимаю. Я знаю, сколько весят playable demo современных игр, я знаю, сколько весит ккригер и в состоянии сравнить функциональность. Портирование тут при чём? К слову: перестаньте, пожалуйста, говорить про сжатие текстур, весь контент там процедурно генерируемый, иначе такие штуки не делаются. Конечно, если Вы предполагаете, что я говорю о банальной архивации, то да, стократное сжатие получить вряд ли возможно, но я говорю не о ней.


Ещё раз повторю, на всякий случай: чем больше программа, тем легче её сжимать, насколько я понимаю.
Вот эта мысль от меня ускользает.
---
Я не уверен, что могу это обосновать. Грубо говоря, функциональность может расти чуть ли не экспоненциально от объёма -- за счёт разнообразных DSL, повторного использования и прочих штук. Если у нас есть некоторая программа, в функциональность которой входит рисование одного окошка, то в её оптимизированной версии будет соответствующая функция, если в функциональность исходной программы входит рисование десяти разных окошек, то умному оптимизатору (в отличие от среднестатистического программиста) вовсе не придётся писать в десять раз больше кода.

Или, скажем, если мы мерям размер исходного кода программы, то: если у нас есть программа на С в триста строк, то существенно ужать её мы вряд ли сможем (оставаясь в рамках С), если у нас есть программа на С в тридцать тысяч строк, то мы можем написать маленький интерпретатор лиспа и переписать программу как-бы на лиспе (используя строковые константы и компиля её по-прежнему сишным компилятором), ужав её очень существенно, в процентном соотношении. Причём при увеличении исходной программы размер интерпретатора меняться не будет, так что у нас будет оставаться всё больше и больше свободного места, которое можно потратить на встраивание другого, ещё более мощного интерпретатора, и так далее.

Но это, конечно, не строгое обоснование, а попытка передать ощущение, я надеюсь, Вы это учтёте.

Хотя эмпирически правило вроде подтверждается.

С функциональностью понятно, берём, например, Windows API, это функциональность. Если некто утверждает, что уложил реализацию винапи в три мегабайта, это можно легко проверить. А "универсальность" это что?
В данном случае универсальность как раз и есть поддержание полногоценного API, WIN32 с наворотами для виндов, Linux kernel API + X11+ Qt3/Gtk для Линукса или иной, но столь же полный функционал ОС для настольного компьютера
Противоположностью универсальной ОС в данном случае является специализированное устройство вроде богатого word processor'а.
К слову: перестаньте, пожалуйста, говорить про сжатие текстур, весь контент там процедурно генерируемый, иначе такие штуки не делаются.
Я рад за них и готов признать за ними мастерское владение всем инструментарием трехмерной графики. К сожалению, это нисколько не приближает нас к возможности ужать на два порядка количество ресурсов для настольного компьютера.
Портирование тут при чём?
При том что одна только библиотека OpenGL весит 15 без малого мегабайт бинарного кода.
Или, скажем, если мы мерям размер исходного кода программы, то: если у нас есть программа на С в триста строк, то существенно ужать её мы вряд ли сможем (оставаясь в рамках С), если у нас есть программа на С в тридцать тысяч строк, то мы можем написать маленький интерпретатор лиспа и переписать программу как-бы на лиспе (используя строковые константы и компиля её по-прежнему сишным компилятором), ужав её очень существенно, в процентном соотношении. Причём при увеличении исходной программы размер интерпретатора меняться не будет, так что у нас будет оставаться всё больше и больше свободного места, которое можно потратить на встраивание другого, ещё более мощного интерпретатора, и так далее.
Вот и Столлман так думал когда разрабатывал Emacs.

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



При том что одна только библиотека OpenGL весит 15 без малого мегабайт бинарного кода.
---
И что? Почему вы считаете, что _её_ нельзя ужать?

Давайте ещё раз, сначала: есть винда с директХ и всем прочим, предоставляющая определённое АПИ. Есть среднестатистическая игра, использующая это АПИ и прочее для рисования чего-то такого, что показано в ккригере. Она весит много мегабайт, больше девяти, что бы вы там не думали по этому поводу. И есть ккригер, использующий _то же самое_ апи и весящий 96к. Вот такая вот удивительная штука, в которую очень тяжело поверить, даже увидев собственными глазами.

Ваше возражение о том, что АПИ тоже что-то весит некорректно. Ну весит, ну и что? Его же не пытались ужать, как бы. Кстати говоря, можете посмотреть на старые демки, не использующие никаких ДХ/ГЛ и пишущие прямо в видеопамять, они тоже вполне показательны. Более того, у меня есть ощущение, что в жанре 4к демо и сейчас мало кто использует ДХ/ГЛ -- как раз по той причине, на которую я указываю, слишком много кода уходит на инициализацию и работу через интерфейс, для таких объёмов это невыгодно, а для 16к уже выгодно и весьма.


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

Вы на это отвечаете, дескать, нет, этого не может быть, потому что не может быть никогда. Всё, больше ни одного аргумента, одни категорические, но от того не более обоснованные утверждения.

Бедный Юникс. Он и вымолвить не смеет, что его разработали на 64 килобайтном адресном пространстве. Низзя!

Юникс времен 64К не давал очень многого из того что дают современные Юниксы. Увы.

Но динамическая подгрузка страниц известна с пятидесятых :-)

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

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

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

Не знаю насчет ядра, сначала вроде не только о нем говорили, но и об иксах и о сетевых приладах, которые снаружи. Само то ядро крохотное, минимальная конфигурация Линокса вообще на дискетку влезает. Но, повторяю, так как нам не известны физические ограничения по плотности функциональности, ничто не мешает считать что и ядро можно ужать во много раз. Другое дело - нафиг не нужно.

А вот как отделить "эффективность" машины идеально-инженерной, вроде близости к альшуллеровскому ИКР(идеальноый конечный результат) от "эффективности" инженерно-реальной, которая включает также кучу добавок вроде самой стоимости ИКР(инж-констр работ), предпологаемый срок службы, ремонтопотребность, патентную чистоту, комфорт использования существующим персоналом и т.д. и т.п.?

На дискетку влезает сильно урезанное ядро, которое к тому же требует памяти больше чем занимает на диске.
Так что мимо.
Но, повторяю, так как нам не известны физические ограничения по плотности функциональности, ничто не мешает считать что и ядро можно ужать во много раз.
Кроме физических, бывают и другие ограничения.
Например, неизбыточность информации.
А вот как отделить "эффективность" машины идеально-инженерной, вроде близости к альшуллеровскому ИКР(идеальноый конечный результат) от "эффективности" инженерно-реальной, которая включает также кучу добавок вроде самой стоимости ИКР(инж-констр работ), предпологаемый срок службы, ремонтопотребность, патентную чистоту, комфорт использования существующим персоналом и т.д. и т.п.?
Только по деньгам.

1) Само ядро урезать нельзя, на то оно и ядро - оно же не микроядерное а цельносшитое. Информационная неизбыточность, согласен, но даже если тупо пройтись упаковщиком, и то раза в полтора-два упакуется. А ведь есть еще конструкторская избыточность - более чистописанный код, и функциональная избыточность - когда той же функциональности можно добится за счет совмещения функций, оббобщения, замены и т.д.

2) Где лежат деньги в ИКР Альтшуллера? "Идеальная машина - это когда машины нет а ее функции исполняются. Идеальный конечный результат - действие совершается само по себе, без наших усилий". Самые сильные тех.решения всегда идут в этом направлении. В одном из первых спутников нужно было разместить дополнительный прибор весом в несколько кило. Плотность монтажа была пиковой по тем временам, общий вес жестко лимитирован возможностями ракеты-носителя. Прибор засунули, удалив балансировочный груз - свинцовую чушку на дне корпуса. Прибор сам стал такой чушкой, исполняя ее функциональность заодно со своей. Мне неизвестны физические ограничения компактности и мультифункциональности конструкций, во всяком случае на мультиатомном уровне. Предела просто нет, пока не уходишь на уровень химии.

Вмешиваюсь в ваш спор --- а почему бы не считать как еще один критерий эффективности _модифицируемость_ программы. То есть то, насколько легко ее можно будет менять в предположительном наборе обстоятельств.
Этот критерий ИМХО не менее важен, чем длина программы в байтах, а то и более.
Потому что "программу всегда нужно будет менять"(с)я

Можно я попробую ответить по-простому, как велосипедист-любитель? На некоторых велосипедах ездить приятнее и быстрее, чем на других. Чем это не критерий эффективности велосипеда?

На велосипеде который стоит 10,000 долларов, ездить еще приятнее, но лишь немногие полагают это удовольствие оправдывающим эту цену.

Ну, (если это так), то он, как велосипед, эффективнее. А что тут не так?

Кстати, (хотя это совершенно другая тема), я сильно подозреваю, что могущих различить велосипеды, скажем, за пять и за десять тысяч, гораздо меньше, чем таки покупающих за десять.

Ну, (если это так), то он, как велосипед, эффективнее. А что тут не так?
Не так. Для большинства людей рост удовольствия от езды на велосипеде не оправдывает такой рост цены, следовательно, этот велосипед эффективен лишь для очень узкого круга покупателей.
Кстати, (хотя это совершенно другая тема), я сильно подозреваю, что могущих различить велосипеды, скажем, за пять и за десять тысяч, гораздо меньше, чем таки покупающих за десять.
Это соображение отчасти компенсируется тем что людей, способных на глаз отличить велосипед за 1000 долларов и за 10,000, очень мало.

Ну, если вы вводите денежный фактор в оценку эффективности, то без денежного фактора в оценке эффективности никак.

Вопрос же ваш был о критерии эффективности, не связанном с деньгами. Тот, что я привёл - не связан: на каком ехать быстрее (или приятнее) - тот и эффективнее.

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

В общем, качество машинки, конечно же, связано с её эффективностью. Хотя, например, велосипед с облупившейся на другой день краской качественным как-то не очень назовёшь. А вот эффективным (именно как механическое устройство эффективным) - вполне, если ездит хорошо.

Мне кажется что качества велосипеда включают в себя довольно много взаимосвязанных параметров, из которых качество покраски не влияет немедленно на усилия, необходимые для езды или удобство управления.

Вот тут я согласен.

Не ломаются они, ага, как же :) За последние четыре года при не слишком напряжной работе в дом. офисе вышли из строя: HP LaserJet 1010, HP LaserJet 1012, HP LaserJet 1018. Причём ремонт экономически нецелесообразен. Сейчас работает Xerox Phaser 3124, посмотрим, на сколько его хватит. Что-то я разочаровался в HP.

У меня 4 этажа офисного здания на HP сделана. За полтора года как я там работаю, умер один принтер, который перекормили скрепками. А в бухгалтерии на складе народ отжигает - по 2-3 картриджа в месяц (53X, не хухры мухры) ухлопывает.

PS Картриджи, я наюсь, вы новые покупали? У меня очень печальный опыт эксплуатации "перезаправлёнышей".

Новые всегда. А вот Xerox официально разрешает перезаправку.

И дохли HP'шные принтеры кучей? Не верю. Просто интуитивно не верю.

Офицально перезаправленные картриджи от Зиракса я видел. У нас до сих пор у офис-менеджера 3110 стоит. Буэ. В смысле, оно всё измученное до невозможности. Хотя, наверное, просто ресурс принтера за 7 лет того уже...

Хотите верьте, хотите нет. Могу вам подарить последний сдохший 1018, он на шкафу стоит. Январь этого года. Остальные отдал или выбросил. Но дохли не кучей, конечно, а по очереди. Нагрузка реально маленькая, 1500, ну 2000 страниц в месяц максимум, а часто и того меньше.

Ну, странно. Чес-слово, странно. Против фактов возражать не буду, но с моей стороны другие факты -_-.

У последнего сломался датчик закрытия дверцы (???). При замене картриджа пишет «закройте дверцу», от кратриджа не зависит. Может, конечно, мне так не повезло, но теперь доверия к HP у меня нет. Кстати у меня был ещё планшетный сканер от HP, не сломался, но этой покупкой я очень недоволен. До того у меня пять лет проработал сканер Umax, он был гораздо быстрее и удобнее, хотя примерно одного класса. А сейчас пользуюсь листовым сканером HP N6010. Не могу сказать что доволен (например, у него есть такой глюк — через некоторое время сканер становится недоступен, приходится его включать/выключать), но альтернатив такому аппарату не вижу.

Первые ХП были совсем не такие. У нас LaserJet III работал 10 лет и умер от несчастного случая (кто-то кинул кирпич в окно и попал принтеру в лоток)

У моего директора какой-то древний LaserJet типа 5L что ли, до сих пор работает, только механизм подачи бумаги глючит, если в лотке 30 листов и меньше, все их засасывает за один проход.

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

ну, мне в данном случае интереснее именно как машину смотреть. Про "быть проданным" пусть желающие смотрят... Как я понимаю, в таких недостатка нет.

интереснее, но корректно ли? В данном случае, по-моему, сам "идеал" не определен. Оттого и отталкиваться от него затруднительно.

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

Не думаю, что он имел в виду рекламу, маркетинг. соотношение цена-качество и учет объема продаж.

Боже мой, а ведь и это тоже может стать реальностью.

конечно, и мы оба понимаем, почему он был неправ. Я улавливаю, о чем вы говорите и в какую логику укладываете. Идеальная машина тем и идеальна, что на нее не накладываются ограничения реальных условий, в которых ей придется "быть эффективной". Ни одна реальная машина не делается так. А биологической машине надо еще ползать, кушать и размножаться, помимо исполнения той функции, которую мы произвольно выделим, как потенциально улучшаемую. Вот идеальная паровая машина, которая размножается,...будет, боюсь, уступать по конструктивной эффективности "простой" идеальной машине.
Так и идеальный конструктивный телефон для меня непредставим. Точнее, если его обозначить, он будет лишен многих свойств современного телефона, и я скажу: он менее эффективен как машина презентации определенного "образа жизни". Ведь именно такую машину создают изначально, а ни какую другую.

Да, аналогия с биологией всегда в таких случаях хорошо работает. Тоже множество сложных систем, выделение одной-единственной функции у которых зачастую делается произвольно. А эволюция не работает с функцией, она имеет дело с системой, которая пытается выживать, стреляя в разных направлениях одновременно. Ну да зачем я это пишу, вы хорошо это знаете. Ну может, кому-то...

да, понимаю, согласен

хотя очень непривычно слышать про машину, что ее основная функция - презентация образа жизни. А что делать?

неудивительно, машина делается для живых людей, и выживает в их среде. А критерии у нас, существ не только рациональных, но и эмоциональных, сами знаете, далеко не всегда сводятся к конструктивной эффективности.

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

Поэтому мне кажется имеет место равновесие - с одной стороны технология обрастает тиной и кораллами, с другой - сама себя тащит из болота за волосы.

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

но ведь и тут возникает учет побочного момента - например патентоведения, т.е. правовой ситуации

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

Согласен. Прорыв происходит тогла, когда технология застоялась

Я вроде, про что-то такое в самом конце упомянул. Это вообще мне кажется очень важным, что "обрастание" и "самовытаскивание", не противоположны, а являются частями одного процесса. (то есть, что конкретным методом самовытаскивания вполне может оказаться несколько изменённое использования коралла).

Новинку надо продать, как можно дороже. Поэтому на неё навешивают прибамбасы, которые абсолютно не нужны. Скажем, дешевого, самого простого мобильника, по которому можно только звонить и слать эсэмески не найти. обязательно, чтобы был фотоаппарат, интернет, калькулятор, телевизор, магнитофон... На хрен все эти навороты? Ну, цена - это раз. Два - вещь НЕ должна служить долго. Иначе, количество покупателей резко сократится. Поэтому вещь должна ломаться как раз сразу после истечения гарантийного срока. Я понимаю, что все это усложняет работу человека в процессе создания данной вещи. Такова цена прогресса.

Соль на раны. и сам искал простой мобильник, и часто вижу в сети. как народ его же ищет, болезного, а - нету. Да, понятное дело. Сложное дороже и сломается, а платить за надежность... видимо, на этом не наваришь.

однажды прочла рассказ про наше будущее ( увы, забыла, кто написал). Человек радовался, что успел донести табуретку до дома, и она не развалилась.

а, да, помню. http://lib.ru/RUFANT/MUSLIN/42-09.txt
Борис Зубков, Евгений Муслин. Непрочный, непрочный, непрочный мир...

Правильнее сказать, такова цена "рыночной экономики".

как немного учавствующий в процессе человек, считаю своим долгом заметить, что в по-настоящему сложных проектах человеческий фактор несущественнен, потому что от человека уже отказались. Никакой гениальный конструктор или программист уже не способен разработать современный процессор или, скажем, драйвер к видеокарте. Максимум, что зарождается в человеческой голове - это "архитектура", самое общее представление. Дальше машины разрабатывают себя сами.

"от человека уже отказались"
что ви говорите!

А можно чуть подробнее? Поскольку я в процессе не участвую, - может быть. там ниже архитектуры и всамо деле весьма простые. задаваемые счетным количеством параметров процедуры... Так что это как претензия к архитектору, что он не сам кирпичи кладет для дома - ясное дело. не сам. но дом строит архитектор... как-то так. Нет?

да, так и есть. Я лишь хотел подчеркнуть, что потери эффективности идут всё больше не от того, что люди "путаются в технологиях", а от того, что люди после какого-то приближения уже просто не знают, как работает технология. Никто не знает, как на самом деле ведёт себя каждый из миллиарда транзисторов процессора, когда на него подается команда. Поэтому и надеятся, что этот процесс оптимален, сложно.
То же и с ПО. Автоматически сгенерированный драйвер никогда не будет оптимальным, потому что его разработчик лишь грубо набросал рамки, а создатель системы автоматической разработки заложил в нее лишь некоторое, пусть и весьма большое, количество пред-заданных "кирпичиков", которые далеко не всегда дают оптимальный стык. Именно поэтому сейчас уже обычное явление, когда выход следующей версии драйвера (отшлифованной вручную или посроенной более специализированной САР) дает прирост производительности больший, чем выход новой железки. Еще десять лет назад это звучало бы анекдотом.

потому что от человека уже отказались

Значит, осталось только грамотно его утилизовать?

упаковать и продать

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

То есть, отказаться от человека можно лишь там где не надо "формировать архитектуру".

Ну если я правильно понял -- это еще одно подтверждение закона убывающей полезности. Человеческий фактор здесь играет роль усилителя.

а что это за закон? а. сообразил - з-н убывающей предельной полезности... Но я - простите - не соображу. Там речь о новой единице такого же товара, а здесь все рассуждение идет внутри одного изделия - что конструктивно оно неэффективно.

Вы говорите о его строгой экономической формулировке. Я же тут немного вольно пользуюсь терминологией (уж простите) -- как в случае со вторым началом термодинамике -- когда его истинный физический смысл очень сложен и не-специалистом не может применен правильно -- но при этом перенос его на бытовой уровень очень даже работает ;-)
Фактически я рассматриваю полезность (прирост) добавления функционала в систему.

м-мм.. как-то так: в сложной машине. состоящей более чем из n узлов. добавление каждого следующего узла после m все менее эффективно по сравнению с добавленными узлами... да. я понимаю, почему винтики не докручивают - кому это нафиг надо при таком законе.

ну да. Я конечно понимаю что могу вас рассмешить как биолога -- но с аппендиксом не совсем так разве получилось ;-)

Ну а если совсем серьезно -- можно вернуться к мобильникам, чуть выше затронутым. Есть у меня мобильник, а в нем можно иузыку слушать. Но я вумный -- слушаю музыку в плеере 8).
Посмотрите на программное обеспечение -- новые версии только цифирками и отличаются.
Посмотрите на (специальные) книги -- есть широко а есть глубоко.
У erienman с "потому что от человека уже отказались" есть доля истины -- в тех областях где мы близки к потолку этот потолок очень хорошо чувствуется -- рост-то замедляется. Поэтому пока не произойдет качественного прорыва система обречена приносить всё меньше и меньше пользы от ее подновления

Если КПД первой части устройства 70%, и КПД второй части 70%, и при том функционал второй полностью зависит от результатов первой, а результат работы устройства есть выходной результат второй части, то КПД устройства будет 49%.
КПД: 1(70%)->2(70%)-> результат(49%)

Плюс дефицит внимания разработчика, плюс тот же эффект падения КПД в организации процесса разработки.

Можно, наверное, подсчитать, насколько компьютер неэффективноее молотка. должна астрономическая цифирь получиться.

Оно да -- но к счастью КПД не измеряется абсолютными величинами -- посему всё не так страшно 8).
И всё же у albiel есть небольшая натяжка -- это если архитектура система сделана (получилась) по pipeline принципу -- тогда расчёты верны. Но это ж не всегда

Я показал наиболее яркий и прозрачный пример схемы падения эффективности. В двухколёсном велосипеде по сравнению с одноколёсным частично pipeline, а частично нет.

Компьютер не есть производное от молотка. Вообще, любая новая система приобретает новые свойства.

Учитывая огромную стоимость R&D, эффективными могут быть только очень массовые изделия. В остальных случаях дешевле потратиться на дополнительные материалы и т.п., чем увеличивать сроки и стоимость разработки.

я не знаю даже. что такое R&D

Это такое умное иностранное слово, которое используют, чтобы показать свою вовлечённость в контекст современной бизнес культуры (1 уровень сложности).
Означает прикладные исследования (примерный сов. аналог - отраслевая наука).

спасибо. постараюсь запомнить умное иностранное слово.

прикладные исследования и разработка.

спасибо

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

а, да. вспоминаю эти споры по авторскому праву.

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

Здесь неявно не учитываются затраты на разработку. Т.е. сравнивается эффективность _уже_разработанных_ машин - реальной и идеальной. Понятно, откуда это идёт - считается, что время работы/жизни машины много больше времени конструирования, и в пределе любые затраты на конструирование окупятся.

Однако в реальной жизни это не так - "время жизни" машины (детали) ограниченно, а стоимость разработки заметна. Поэтому и получается, что выгодней использовать знакомый инструментарий, чем незнакомый (учитывая затраты на освоение), и т.п. Если эффективность всего процесса, от начала разработки через производство до списания машины, считать честно, то соотношение будет не такое уж очевидное.

Неэффективность машин искупается их быстрым устареванием.

Ну да, примерно так.

Вернее сказать, первое - это косвенное следствие второго. А второе - это следствие общего ускорения эффективности машин со временем.

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

да, понимаю. Каждая машина - только частичка социума.

Не машины становятся менее эффективны. А старые производственные процессы становятся менее эффективны. Производственные отношения, я бы сказал.

Пожалуй, в приложении к конкретному обсуждению я этого не понимаю. Разве что - как сказал Юрвор - это о том, что стареет быстро.

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

Вообще, обсуждаемое явление следует разделить на два. Первое явление - это упомянутые мною производственные отношения не позволяют эффективно производить сложные системы и механизмы. Второе, совершенно другое явление - когда по экономико-политическим причинам сложные системы и механизмы создаются намеренно неэффективными, или неэффективным способом. Результат как будто один, а причины разные.

У дискавери есть фильм, где владелец катера, инженер по совместительству, переставляет винт на подвесном моторе, таким образом, что он, грубо говоря, "смотрит" не назад, а вперед (так, что надвигающейся по ходу движения жидкости не мешает привод винта) - скорость увеличивается чуть не на 20% (я не помню точно, но цифра очень серьезная)

удивительно

Не только это. Нужно задать вопрос: а кому сейчас нужны эффективные добротные машины?...потребителю? - безусловно, только он ли решает тут дело? Производителям такое не нужно...они отлично понимают что это приведёт к коллапсу промышленности...нужны машины требующие бесконечной доработки, ремонта, периодической замены на новые. Помню один фантастический рассказ, муж в тайне от закона (запрещающего такие изделия) везёт жене в подарок простую деревянную табуретку...по закону разрешена покупка и использование только таких изделий, срок жизни которых не более 1-го 2-х дней.

http://ivanov-petrov.livejournal.com/910564.html?thread=39256036#t39256036

(всегда меня немножко удивлял обычай, довольно распространённый в ЖЖ, - не стремиться прочесть предыдущие комментарии... да, их, правда, иногда - слишком много, не дотерпишь:)- но в них же порой и самое интересное бывает - вот ведь и весь этот постинг без внимания к этому Хозяина Журнала - просто не родился бы:)).

Rainaldo

Извините если повторил кого-то. Когда реплик 5-6 я читаю все, но если их переваливает за сто, считаю вполне нормальным просто отозваться на сам исходный пост. Ещё раз извиняюсь перед автором поста за повтор и лишнее беспокойство.

да что Вы. сущие пустяки

Да я же не в упрёк, и тем более - я-то не один их тех, кто бог бы заслужить право на Ваши извинения, и они, уверен - нисколько не в претензиях. Хотел просто обратить Ваше внимание на тот сходный тред, а потом что-то сказанулось-проворчалось:). Вы знаете, я, конечно, и сам сколько раз "не дотерпел" в огромных порой ветвях обсуждений, к тому же заКАТанных, - потом, правда, не раз и жалел, когда именно в нераскатанных мной вдруг обнаруживалось "самое интересное:)", самое близкое моим собственным отзвукам. Но тут - ещё и некий "выбор привычек", я вот (совершенно, опять-таки, не в противовес кому бы то... просто из собственного перфекционизма:)) совершенно не хочу для себя делать это "нормой". "Ах, чёрт, сил не хватает:)" - да, "как жаль, - может, ещё дочитаю" - да, но чтоб не принять для себя "вполне нормальным", не избавиться от тех сожалений:). Потому что привычка - она ж такая искусительница: образ действий, который сегодня привычен "когда за сто", завтра себя воспроизводит и без особых оглядок на...

Но это такой всё пустяк и, скорее, бестактность с моей стороны. Так что, не заслужив ни в малейшей мере Ваших извинений, это я просто обязан их Вам принести!

Rainaldo

Да, ещё. Вы задели больную тему, так что я о ней сейчас думал... В принципе, начиная с некоего предела само изделие по себе никого не интересует. Важна инфраструктура.

Вот молоток можно делать исключительно из соображений молоткастости. И топор можно. А вот гаечный ключ уже нет. Надо думать о том, какие гайки им будут откручивать. Уже надо думать не о функционале самого устройства, а о совместимости.

И гайки - это очень просто. В действительно сложных устройствах совместимость с типовыми узлами и стандартами занимает львиную долю сложности.

В тот момент, когда мы от механики переходим к электронике появляется ещё больший объём того, с чем надо быть совместимым. Переходим от электроники к софту - и вырисовывается картина ужасающего размера. Идеальная операционная система никому нафиг не нужна, если она не совместима с остальными. Причём точек совместимости слишком много - откуда растёт монополизм некоторых фирм. Сделать совместимым во всём - это слишком сложно. А значит, теряется ценность.

Есть радикальный вариант - переделать стандарты под себя (это и есть путь к монополизму). Но на такое надо очень много ресурсов и получившееся людей не радует...

Легко догадаться, что теперь и топор тоже должен быть совместимым... С ящиком инструментов, рюкзаком, дрова им колоть или перед друзьями красоваться, туристический - чтоб смотрелся и легкий был, для дров - увесистый... Я понимаю. Особенно электроника. Стандарты, протоколы... О том и речь. Как только мы вписываем изделие в техноценоз, как пропадает, по сути. прямая оценка эффективности. Можно говорить - в пределе - только о техноценозе в целом. В нем могут быть даже прямо вредные вещи, они обусловлены только тем. что техноценоз в целом хорош (или ему нет замены), а сама вещь может быть много хуже своего "изолированного" аналога. Отсюда - в сложных системах становится размытым представление о функции и об эффективности и на первое место выходят показатели устойчивости.

вот к топору как раз требования, касающиеся его самого (т.е. его атрибутов). А вот дальше именно так.

Единственное, что: в рамках набора интерфейсов и требований совместимости может таки быть конкуренция. И в этом случае возможность сравнения всё-таки появляется.

И в программировании (как области работы человека, не ограниченной материальными объектами) очень распространены методы локализации функциональности. Грубо говоря, мы сводим функциональность программы к некоему ТЗ, набору интерфейсов, выделяя её как отдельную сущность (хороший пример - SQL сервер, почтовый сервер), реализации и собственная архитектура которых может быть произвольной.

В принципе, мы приходим к одной из сложнейших (и никем толком не исследованной) области системного проектирования (а оттуда, видимо, в кибернетику). Стихийно развивающиеся структуры всегда неэффективны (по сравнению с планируемыми), но, обычно, обладают большим запасом вариативности (опять биология начинается -_-).

Какая из них лучше - сложно сказать. Но постепенно приходит мысль о том, что "глобальная система стандартизации" есть хорошо только в условиях хорошей (идеальной) системы стандартизации. В условиях "всякой фигни" конкурирующие стандарты оказываются более гибким решением. Хотя это увеличивает стоимость реализации, это же позволяет в случае "и что же за хрень мы во второй день сморозили-то... и как это переделывать?" переключиться на альтернативную систему.

да, конечно, с более общей точки зрения кконкурирующие стандарты безопаснее. Более того - не надо даже платить за риск. То есть ежели выделять специальных таких испытателей, которые бы перли против рожна - дорогое удовольствие, а тут они даром прут и делают другие стандарты, сами страдают - поскольку ясно. что любой немассовый стандарт - это большая головная боль... И все даром. Радоваться надо.