Поставил себе сегодня альфу Ubuntu после того, как прочел о ней описание на Slashdot (http://linux.slashdot.org/article.pl?sid=08/02/02/2219233&from=rss).

Самое классное, что там есть — PolicyKit (тут есть скриншот: http://arstechnica.com/news.ars/post/20080202-first-look-ubuntu-8-04-hardy-heron-alpha-4.html).

Эта штуковина позволяет делать почти полноценный code access security для обычных приложений. Если кратко, то оно работает так — есть шина обмена сообщениями D-BUS (это COM с человеческим лицом), на нее вешаются сервисы, выполняющие restricted-операции, они работают в контекстах безопасности, с достаточными правами.

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

Кроме того, тут в дело вступает еще один компонент системы — AppArmor. Это ядерный модуль, который позволяет ограничить права одного конкретно взятого процесса. Например, можно сделать так, чтобы FireFox не имел доступа ни к каким файлам кроме своего каталога плугинов. Совместно с PolicyKit он может использоваться для изоляции опасных процессов.

В пользовательском интерфейсе это все выглядит так:


Если я нажимаю на кнопку "Unlock" — то у меня появляется окно, в котором я ввожу свой пароль, после чего приложение "Network Settings" получает права на работу с настройками сети, но ни с чем иным.

Уже делается интеграция с FireFox — чтобы можно было безопасно сохранять файлы через диалог "Save as", но при этом, чтобы FireFox не мог заниматься, например, шпионством за файлами пользователя.

В общем, как оказалось, для CAS совсем не нужно переписывать все на managed-код.

Здравствуйте, Cyberax, Вы писали:

C>В общем, как оказалось, для CAS совсем не нужно переписывать все на managed-код.

Угу, надо только _все_ restricted-операции переписать через сообщения D-BUS. И не забывать собирать _все_ программы с контролем стека и проч. и проч.

Заканчивается эпоха "искусства и романтики", в полный "промышленный" рост встаёт эпоха ремеслиничества. Осталось дождаться ISO на контроль качества

Здравствуйте, cl-user, Вы писали:

CU>Здравствуйте, Cyberax, Вы писали:

C>>В общем, как оказалось, для CAS совсем не нужно переписывать все на managed-код.

CU>Угу, надо только _все_ restricted-операции переписать через сообщения D-BUS. И не забывать собирать _все_ программы с контролем стека и проч. и проч.

CU>Заканчивается эпоха "искусства и романтики", в полный "промышленный" рост встаёт эпоха ремеслиничества. Осталось дождаться ISO на контроль качества

А чем 9000 не подходит? В купе с CMM?
Имхо про искусство/ремеслинечество это зря, просто по-моему люди начинают понимать, что "лажовое" ПО им боком выходит (мы не настолько богаты чтоб покупать плохие вещи (ц))

Здравствуйте, cl-user, Вы писали:

CU>Заканчивается эпоха "искусства и романтики", в полный "промышленный" рост встаёт эпоха ремеслиничества. Осталось дождаться ISO на контроль качества

А потом станки и мануфактуры придут

Но это не станет помехой прогулке романтика (с)

Здравствуйте, Курилка, Вы писали:

C>>>В общем, как оказалось, для CAS совсем не нужно переписывать все на managed-код.

CU>>Угу, надо только _все_ restricted-операции переписать через сообщения D-BUS. И не забывать собирать _все_ программы с контролем стека и проч. и проч.

CU>>Заканчивается эпоха "искусства и романтики", в полный "промышленный" рост встаёт эпоха ремеслиничества. Осталось дождаться ISO на контроль качества

К>А чем 9000 не подходит? В купе с CMM?

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

К>Имхо про искусство/ремеслинечество это зря, просто по-моему люди начинают понимать, что "лажовое" ПО им боком выходит (мы не настолько богаты чтоб покупать плохие вещи (ц))

Имхо не зря. Посмотрите на "оформленный" java-код (с комментариями, причём с подробными но не "глупыми") — без IDE что-то искать в файле или просто разбираться (быстро) с кодом практически невозможно — там чистого кода меньше половины. "Противоположность" — CL — не лучше — после заголовка объявления функции страница документации, потом 10 строк текста и 15 строк комментариев. И это только документирование. Плюс прочая "стандартизация" (использование протоколов, соглашений, библиотек, прочего — а-ля EJB или CLOS) — и о правиле "класс/функция на страницу/экран" можно забыть даже с 21' моником и "8-м шрифтом".

И вот ещё приходят "стандарты" на restricted-операции. И на очереди ещё много чего — та-же мультизадачность (erlang всё равно всех потребностей мульти-[процессов/тредов/ядер/процессоров/хостов/кластеров/сетей] "не покрывает") и т.д.

Я к тому, что место для подобия искусства остаётся только на этапе составления ТЗ (т.е. "конструирования"). А далее должно быть "как по рельсам": с одной стороны — список необходимой функциональности, с другой — стандарты. Хотя "искусство" лавирования между этими "сторонами одной монеты" тоже "имеет место быть", но это уже совсем другая история.

P.S. Я не "жалуюсь" — наоборот, я искренне рад что может быть в ближайшем будущем "софтостроение" начнёт обретать "индустриальный" характер

Здравствуйте, cl-user, Вы писали:

C>>В общем, как оказалось, для CAS совсем не нужно переписывать все на managed-код.
CU>Угу, надо только _все_ restricted-операции переписать через сообщения D-BUS. И не забывать собирать _все_ программы с контролем стека и проч. и проч.
Естественно, все restricted-операции должны идти через D-BUS, но они в большинстве своем прекрасно будут через нее работать. Пожалуй, доступ к файлам разве что надо в отдельный случай вынести. Но это уже вроде бы есть — возможность передать дескриптор файла между процессами.

Защита стека в программах — пофиг. Суть в том, что даже взломанное приложение не вырвется за пределы своей клетки (спасибо AppArmor'у) и не сможет выполнить ничего, кроме авторизованых операций (спасибо PolicyKit'у). Ну и гранулярность разрешений тоже спасает — не надо каждой программе давать полный root.

CU>Заканчивается эпоха "искусства и романтики", в полный "промышленный" рост встаёт эпоха ремеслиничества. Осталось дождаться ISO на контроль качества
Так вроде есть же?

Здравствуйте, Cyberax, Вы писали:

C>>>В общем, как оказалось, для CAS совсем не нужно переписывать все на managed-код.
CU>>Угу, надо только _все_ restricted-операции переписать через сообщения D-BUS. И не забывать собирать _все_ программы с контролем стека и проч. и проч.
C>Естественно, все restricted-операции должны идти через D-BUS, но они в большинстве своем прекрасно будут через нее работать. Пожалуй, доступ к файлам разве что надо в отдельный случай вынести. Но это уже вроде бы есть — возможность передать дескриптор файла между процессами.

Вот именно работу с файлами я и имел в виду. Особенно учитывая что в POSIX "всё есть файл" (я знаю, что утрирую) — это не мало.

C>Защита стека в программах — пофиг. Суть в том, что даже взломанное приложение не вырвется за пределы своей клетки (спасибо AppArmor'у) и не сможет выполнить ничего, кроме авторизованых операций (спасибо PolicyKit'у). Ну и гранулярность разрешений тоже спасает — не надо каждой программе давать полный root.

"пофиг" там, где _всю_ безопасность бдут контролировать именно AppArmor и PolicyKit. Но сть куча программ, которые сами за неё отвечают (сейчас). Их переписывать?

CU>>Заканчивается эпоха "искусства и романтики", в полный "промышленный" рост встаёт эпоха ремеслиничества. Осталось дождаться ISO на контроль качества
C>Так вроде есть же?

В IT области? Не слышал... И я уже писал — это должно быть "вершиной айсберга", а не его основой.

Здравствуйте, cl-user, Вы писали:

CU>И вот ещё приходят "стандарты" на restricted-операции. И на очереди ещё много чего — та-же мультизадачность (erlang всё равно всех потребностей мульти-[процессов/тредов/ядер/процессоров/хостов/кластеров/сетей] "не покрывает") и т.д.

There is no silver bullet.

CU>Я к тому, что место для подобия искусства остаётся только на этапе составления ТЗ (т.е. "конструирования"). А далее должно быть "как по рельсам": с одной стороны — список необходимой функциональности, с другой — стандарты. Хотя "искусство" лавирования между этими "сторонами одной монеты" тоже "имеет место быть", но это уже совсем другая история.

Дак по сути всё софтостроение есть перевод из желаемого в работающее на компе, правда вводят кучу стадий для простоты: польз. требования, разработческие, HLD, программа, под которой VM какой-нибудь, под которой ОС какая-нибудь
А вообще стандартные задачи софтом решаются на ура, но они решаются софтом. Тогда как написание софта есть решение, как правило (если откинуть излишнее велосипедописание), новых задач.
Так что тут я склонен работу разработчика скорее с изобретательством сравнивать. А промышленное производтство тут — клепание болванок или хттп-сервер, где лежат бинарники или исходники

Здравствуйте, Cyberax, Вы писали:

C>Поставил себе сегодня альфу Ubuntu после того, как прочел о ней описание на Slashdot (http://linux.slashdot.org/article.pl?sid=08/02/02/2219233&from=rss).

C>Самое классное, что там есть — PolicyKit (тут есть скриншот: http://arstechnica.com/news.ars/post/20080202-first-look-ubuntu-8-04-hardy-heron-alpha-4.html).

C>Эта штуковина позволяет делать почти полноценный code access security для обычных приложений. Если кратко, то оно работает так — есть шина обмена сообщениями D-BUS (это COM с человеческим лицом), на нее вешаются сервисы, выполняющие restricted-операции, они работают в контекстах безопасности, с достаточными правами.

> uname -rs
FreeBSD 7.0-RC1
> pkg_info | grep policykit
policykit-0.1.20060514_4 Framework for controlling access to system-wide components

Так шо не одной Ubuntой это дело движется.

Здравствуйте, SergH, Вы писали:

CU>>Заканчивается эпоха "искусства и романтики", в полный "промышленный" рост встаёт эпоха ремеслиничества. Осталось дождаться ISO на контроль качества

SH>А потом станки и мануфактуры придут

SH>Но это не станет помехой прогулке романтика (с)

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

Здравствуйте, Курилка, Вы писали:

CU>>Я к тому, что место для подобия искусства остаётся только на этапе составления ТЗ (т.е. "конструирования"). А далее должно быть "как по рельсам": с одной стороны — список необходимой функциональности, с другой — стандарты. Хотя "искусство" лавирования между этими "сторонами одной монеты" тоже "имеет место быть", но это уже совсем другая история.

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

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

Осла и слона достаточно, чтобы оба "не спали", но большая разноплановость ведёт к распылению ресурсов, что на уровне всего общества/отрасли слишком затратно.

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

Только "разработчиков" должно остаться как "сенаторов", а не как "юристов" (как сейчас)

Здравствуйте, cl-user, Вы писали:

C>>Естественно, все restricted-операции должны идти через D-BUS, но они в большинстве своем прекрасно будут через нее работать. Пожалуй, доступ к файлам разве что надо в отдельный случай вынести. Но это уже вроде бы есть — возможность передать дескриптор файла между процессами.
CU>Вот именно работу с файлами я и имел в виду. Особенно учитывая что в POSIX "всё есть файл" (я знаю, что утрирую) — это не мало.
Ну тогда это уже решили. Открываешь файл с помощью D-BUS, получаешь от него дескриптор и работаешь с ним как обычно.

C>>Защита стека в программах — пофиг. Суть в том, что даже взломанное приложение не вырвется за пределы своей клетки (спасибо AppArmor'у) и не сможет выполнить ничего, кроме авторизованых операций (спасибо PolicyKit'у). Ну и гранулярность разрешений тоже спасает — не надо каждой программе давать полный root.
CU>"пофиг" там, где _всю_ безопасность бдут контролировать именно AppArmor и PolicyKit. Но сть куча программ, которые сами за неё отвечают (сейчас). Их переписывать?
Зачем? Смысл в том, чтобы посадить в клетку программу, которая выполняет опасные действия (такие как просмотр web-страничек). Программы из "доверяемого периметра" можно в клетку не сажать.

C>>Так вроде есть же?
CU>В IT области? Не слышал... И я уже писал — это должно быть "вершиной айсберга", а не его основой.
ISO 9000 везде действует.

Здравствуйте, cl-user, Вы писали:

CU>Это не станет помехой прогулке _"художника"_ (или "мастера" по Булгакову). Но это превратит большинство "кузниц" в чугуно/сталелитейных "монстров". А "кузнечество" останется либо как хобби, либо как "тяжёлый" вариант "ювелирки".

Где конвеер, где паровой двигатель хотя бы?

Здравствуйте, cl-user, Вы писали:

CU>Имхо, на данном этапе _большая_ часть пишущегося софта (даже без учёта "хоумпагов" и "хелловордов" и упомянутых "велосипедов") вполне могла бы быть заменена [до]настройкой существующих "монстров". Возможно с некоторыми потерями, но с огромной экономией ресурсов.

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

CU>Осла и слона достаточно, чтобы оба "не спали", но большая разноплановость ведёт к распылению ресурсов, что на уровне всего общества/отрасли слишком затратно.

И двух писателей тоже достаточно? давай оставим только Достоевского и Толстого

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

CU>Только "разработчиков" должно остаться как "сенаторов", а не как "юристов" (как сейчас)

Скорее писателей.

Здравствуйте, cl-user, Вы писали:

CU>Осла и слона достаточно, чтобы оба "не спали", но большая разноплановость ведёт к распылению ресурсов, что на уровне всего общества/отрасли слишком затратно.

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

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

CU>Только "разработчиков" должно остаться как "сенаторов", а не как "юристов" (как сейчас)

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

Здравствуйте, FR, Вы писали:

CU>>Это не станет помехой прогулке _"художника"_ (или "мастера" по Булгакову). Но это превратит большинство "кузниц" в чугуно/сталелитейных "монстров". А "кузнечество" останется либо как хобби, либо как "тяжёлый" вариант "ювелирки".

FR>Где конвеер, где паровой двигатель хотя бы?

Конвееры есть уже сейчас. А паровые двигатели (aka кодогенерация) пока сложны, опасны и, возможно, не достаточно удобны/гибки, (особенно в руках большинства старых "кузнецов"). Хотя "зачатки" добрались уже практически до всех — в частности в виде шаблонов (как программных, так и IDE-шных).

Здравствуйте, Курилка, Вы писали:

К>С чего это? Не вижу логичесной связи
К>От обычного изобретательство софтописание, по мне, отличается тем, что системы выходят заметно сложнее каких-нибудь "газонокосилок" (если в последней нет чипов )

Ну в техническом изобретательстве уже есть работающий аналог "серебрянной пули" ТРИЗ

Здравствуйте, cl-user, Вы писали:

FR>>Где конвеер, где паровой двигатель хотя бы?

CU>Конвееры есть уже сейчас.

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

А паровые двигатели (aka кодогенерация) пока сложны, опасны и, возможно, не достаточно удобны/гибки, (особенно в руках большинства старых "кузнецов"). Хотя "зачатки" добрались уже практически до всех — в частности в виде шаблонов (как программных, так и IDE-шных).

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

Здравствуйте, FR, Вы писали:

FR>Здравствуйте, Курилка, Вы писали:

К>>С чего это? Не вижу логичесной связи
К>>От обычного изобретательство софтописание, по мне, отличается тем, что системы выходят заметно сложнее каких-нибудь "газонокосилок" (если в последней нет чипов )

FR>Ну в техническом изобретательстве уже есть работающий аналог "серебрянной пули" ТРИЗ

Только АРИЗ всё усложнялся и усложнялся и для него надо уже, наверное, вводить ТРИЗ второй степени

Кстати, один из принципов ТРИЗ — устранение "промежуточных" звеньев в системе. Интересно — когда программеры будут напрямую для ПЛИС писать?

Здравствуйте, FR, Вы писали:

CU>>Имхо, на данном этапе _большая_ часть пишущегося софта (даже без учёта "хоумпагов" и "хелловордов" и упомянутых "велосипедов") вполне могла бы быть заменена [до]настройкой существующих "монстров". Возможно с некоторыми потерями, но с огромной экономией ресурсов.

FR>При этом появится профессия "настройщик" и их потребуется не меньше чем сейчас программистов

Добавить их к админам (совместить с ...) — делов то...

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

О всех речь и не шла. Но о большинстве (не ниш, а случаев написания программ).

CU>>Осла и слона достаточно, чтобы оба "не спали", но большая разноплановость ведёт к распылению ресурсов, что на уровне всего общества/отрасли слишком затратно.

FR>И двух писателей тоже достаточно? давай оставим только Достоевского и Толстого

Как "кузнеца и жнеца"? Это будет ещё хуже натурального хозяйства.

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

CU>>Только "разработчиков" должно остаться как "сенаторов", а не как "юристов" (как сейчас)

FR>Скорее писателей.

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

Здравствуйте, cl-user, Вы писали:

FR>>При этом появится профессия "настройщик" и их потребуется не меньше чем сейчас программистов

CU>Добавить их к админам (совместить с ...) — делов то...

Это разные профессии, притом платят "настройщикам" сейчас побольше чем админам

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

CU>О всех речь и не шла. Но о большинстве (не ниш, а случаев написания программ).

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

FR>>Скорее писателей.

CU>Писатель, сертифицтрованный ISO 9000, выдающий "произведения" в жёстко ограниченные сроки, "пишущий" их по строгим установленным стандартам, дающий гарантии на результат их использования?... Нет-уж нет-уж, сами такое читайте...

Ты про литературных негров не слышал

Здравствуйте, Курилка, Вы писали:

CU>>Осла и слона достаточно, чтобы оба "не спали", но большая разноплановость ведёт к распылению ресурсов, что на уровне всего общества/отрасли слишком затратно.

К>Ресурсов стало много, поэтому общество в итоге и расходует их неэкономно

Это причина, но не оправдание.

К>Изменить что-то тут сможет лишь какой-то глобальный катаклизм

"здоровая конкуренция" + стандарты и необходимость гарантий — и большая часть "пены" сама уйдёт.

CU>>Только "разработчиков" должно остаться как "сенаторов", а не как "юристов" (как сейчас)

К>С чего это? Не вижу логичесной связи

Ну это я в далёкое будущее "плюнул" — а-ля "конструкторы автоматических сборочных линий".

Не должен кто попало не то что "конструировать", а даже и собирать (хотел написать "автомобили", а потом подумал, что хоть "тостеры" напиши — результат будет лучше чем с ПО).

К>От обычного изобретательство софтописание, по мне, отличается тем, что системы выходят заметно сложнее каких-нибудь "газонокосилок" (если в последней нет чипов )

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

Здравствуйте, cl-user, Вы писали:

CU>Здравствуйте, Курилка, Вы писали:

CU>>>Осла и слона достаточно, чтобы оба "не спали", но большая разноплановость ведёт к распылению ресурсов, что на уровне всего общества/отрасли слишком затратно.

К>>Ресурсов стало много, поэтому общество в итоге и расходует их неэкономно

CU>Это причина, но не оправдание.

CU>Не должен кто попало не то что "конструировать", а даже и собирать (хотел написать "автомобили", а потом подумал, что хоть "тостеры" напиши — результат будет лучше чем с ПО).

Как-то от строчек выше очень шовинизмом веет

К>>От обычного изобретательство софтописание, по мне, отличается тем, что системы выходят заметно сложнее каких-нибудь "газонокосилок" (если в последней нет чипов )

CU>"Изобретательство" — это "хоумпаги". А "софтописание" — это "конструирование", т.е. занятие для обладающего "инженерными знаниями". Прочее — это "настройка" — "за 3 часа для чайников/идиотов".
Странная у вас терминология, ну да бог с ним

Здравствуйте, Cyberax, Вы писали:

CU>>Вот именно работу с файлами я и имел в виду. Особенно учитывая что в POSIX "всё есть файл" (я знаю, что утрирую) — это не мало.
C>Ну тогда это уже решили. Открываешь файл с помощью D-BUS, получаешь от него дескриптор и работаешь с ним как обычно.

таки это нади писать

C>>>Защита стека в программах — пофиг. Суть в том, что даже взломанное приложение не вырвется за пределы своей клетки (спасибо AppArmor'у) и не сможет выполнить ничего, кроме авторизованых операций (спасибо PolicyKit'у). Ну и гранулярность разрешений тоже спасает — не надо каждой программе давать полный root.
CU>>"пофиг" там, где _всю_ безопасность бдут контролировать именно AppArmor и PolicyKit. Но сть куча программ, которые сами за неё отвечают (сейчас). Их переписывать?
C>Зачем? Смысл в том, чтобы посадить в клетку программу, которая выполняет опасные действия (такие как просмотр web-страничек). Программы из "доверяемого периметра" можно в клетку не сажать.

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

Имхо, контроль стека "гуардам" не противовес и не помеха, а доп. кирпич в "стенку безопасности", но и то и другое "2-й эшелон" по сравнению с качеством самих программ.

C>>>Так вроде есть же?
CU>>В IT области? Не слышал... И я уже писал — это должно быть "вершиной айсберга", а не его основой.
C>ISO 9000 везде действует.

Но везде ли применяется?

Здравствуйте, FR, Вы писали:

FR>>>При этом появится профессия "настройщик" и их потребуется не меньше чем сейчас программистов

CU>>Добавить их к админам (совместить с ...) — делов то...

FR>Это разные профессии, притом платят "настройщикам" сейчас побольше чем админам

И это есть перекос...

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

CU>>О всех речь и не шла. Но о большинстве (не ниш, а случаев написания программ).

FR>Только реально это будет гораздо менее эффективно чем сейчас. Просто появится еще один слой, притом в большинстве своем паразитирующий.

Критерии эффективности? Только не говорите про скорость работы на втором пне — купите соответствующий хард — это может оказаться эффективнее. По 3 кодера на задачку, которую можно допинать "автоматизацией офиса"? Это эффективно? Да плюс отладка...

FR>>>Скорее писателей.

CU>>Писатель, сертифицтрованный ISO 9000, выдающий "произведения" в жёстко ограниченные сроки, "пишущий" их по строгим установленным стандартам, дающий гарантии на результат их использования?... Нет-уж нет-уж, сами такое читайте...

FR>Ты про литературных негров не слышал

Слышал, но не читал (если не считать Дюма-старшего). И это не распространяется на качество и гарантии

Здравствуйте, Курилка, Вы писали:

CU>>Не должен кто попало не то что "конструировать", а даже и собирать (хотел написать "автомобили", а потом подумал, что хоть "тостеры" напиши — результат будет лучше чем с ПО).

К>Как-то от строчек выше очень шовинизмом веет

Не понял — отменим сертификацию всех видов производства/прочей деятельности?

К>>>От обычного изобретательство софтописание, по мне, отличается тем, что системы выходят заметно сложнее каких-нибудь "газонокосилок" (если в последней нет чипов )

CU>>"Изобретательство" — это "хоумпаги". А "софтописание" — это "конструирование", т.е. занятие для обладающего "инженерными знаниями". Прочее — это "настройка" — "за 3 часа для чайников/идиотов".
К>Странная у вас терминология, ну да бог с ним

Да я просто стараюсь двести мысль, что "программирование" в массе своей _должно_ (не спрашивайте "кому?" ) выйти из сферы "кто хочет — тот и пишет" (оговорюсь — если это не хобби) в разряд "индустриального производства" — с контролем качества, гарантиями и прочим. А "для всех" но "по работе" пусть будет "безопасное скриптование" для какой-нибудь VM в safe mode

Здравствуйте, cl-user, Вы писали:

FR>>Это разные профессии, притом платят "настройщикам" сейчас побольше чем админам

CU>И это есть перекос...

Ну даже в профессиях не требующих высокой квалификации знание-сила

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

CU>>>О всех речь и не шла. Но о большинстве (не ниш, а случаев написания программ).

FR>>Только реально это будет гораздо менее эффективно чем сейчас. Просто появится еще один слой, притом в большинстве своем паразитирующий.

CU>Критерии эффективности?

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

CU>Только не говорите про скорость работы на втором пне — купите соответствующий хард — это может оказаться эффективнее.

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

CU>По 3 кодера на задачку, которую можно допинать "автоматизацией офиса"? Это эффективно? Да плюс отладка...

Ну будет три "настройщика", какая разница?

FR>>>>Скорее писателей.

CU>>>Писатель, сертифицтрованный ISO 9000, выдающий "произведения" в жёстко ограниченные сроки, "пишущий" их по строгим установленным стандартам, дающий гарантии на результат их использования?... Нет-уж нет-уж, сами такое читайте...

FR>>Ты про литературных негров не слышал

CU>Слышал, но не читал (если не считать Дюма-старшего). И это не распространяется на качество и гарантии

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

Здравствуйте, FR, Вы писали:

FR>>>Это разные профессии, притом платят "настройщикам" сейчас побольше чем админам

CU>>И это есть перекос...

FR>Ну даже в профессиях не требующих высокой квалификации знание-сила

Это не отменяет перекоса на общем фоне. Ну или админы у нас такие...

FR>>>Только реально это будет гораздо менее эффективно чем сейчас. Просто появится еще один слой, притом в большинстве своем паразитирующий.

CU>>Критерии эффективности?

FR>Критерий простой сколько денег будет потреблять IT отрасль при той же отдаче, по моему с новым слоем гораздо больше чем сейчас.

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

CU>>Только не говорите про скорость работы на втором пне — купите соответствующий хард — это может оказаться эффективнее.

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

Я имел в виду не HDD, а "железо" вообще

CU>>По 3 кодера на задачку, которую можно допинать "автоматизацией офиса"? Это эффективно? Да плюс отладка...

FR>Ну будет три "настройщика", какая разница?

три не будет, а если и будет, то "быстрее"

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

Его _надо_ проверять! Уже и сейчас. Но все до сих пор шарахаются от этого. В харчевнях тоже никакого "сан/эпида" не было — ничего, привыкли

Здравствуйте, cl-user, Вы писали:

CU>Да я просто стараюсь двести мысль, что "программирование" в массе своей _должно_ (не спрашивайте "кому?" ) выйти из сферы "кто хочет — тот и пишет" (оговорюсь — если это не хобби) в разряд "индустриального производства" — с контролем качества, гарантиями и прочим. А "для всех" но "по работе" пусть будет "безопасное скриптование" для какой-нибудь VM в safe mode

Пока в производстве софта и близко нет аналога вот этого http://stovelikih.ru/IZOB/page75.html то есть "серебряной пули" все это нереально.
Да если лень читать, то тот же Форд добился того, что используя более низкоквалифицированную рабочую силу смог поднять производительность труда (в том числе в расчете на человека) на порядки. В производстве же софта только научились кое как использовать низкоквалифицированную рабочую силу при этом производительность в расчете на человека наооборот падает, то есть уровень мануфактур.

Здравствуйте, FR, Вы писали:

FR>>>Где конвеер, где паровой двигатель хотя бы?

CU>>Конвееры есть уже сейчас.

FR>Можно примеры, притом чтобы конвеер как и в промышленности поднимал, а не уменьшал производительность труда на порядок

"Конвеер" даёт возможность вообще создать что-то "большое" — невозможно написать что-то типа ОС или мощного сервера БД или "офиса" без труда многих, где каждый делает отдельные кусочки — параллельности любой промышленный конвеер позавидует.

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

Я ж и говорю — ещё не "развились" до "промышленного использования", но уже есть. Надо работать дальше...

Здравствуйте, cl-user, Вы писали:


FR>>Критерий простой сколько денег будет потреблять IT отрасль при той же отдаче, по моему с новым слоем гораздо больше чем сейчас.

CU>При "индустриализации" IT отрасль сможет выдавать "на гора" намного больше, при этом без "подавляющего велосипедостроительства". Возможно сначала это будет и "дороже", но в перспективе — нет. Хотя как средство "дополнительной занятости населения"...

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

CU>>>Только не говорите про скорость работы на втором пне — купите соответствующий хард — это может оказаться эффективнее.

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

CU>Я имел в виду не HDD, а "железо" вообще

Я тоже

CU>>>По 3 кодера на задачку, которую можно допинать "автоматизацией офиса"? Это эффективно? Да плюс отладка...

FR>>Ну будет три "настройщика", какая разница?

CU>три не будет, а если и будет, то "быстрее"

Угу настройщиков будет 5

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

CU>Его _надо_ проверять! Уже и сейчас. Но все до сих пор шарахаются от этого. В харчевнях тоже никакого "сан/эпида" не было — ничего, привыкли

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

Здравствуйте, cl-user, Вы писали:

CU>"Конвеер" даёт возможность вообще создать что-то "большое" — невозможно написать что-то типа ОС или мощного сервера БД или "офиса" без труда многих, где каждый делает отдельные кусочки — параллельности любой промышленный конвеер позавидует.

Нет конвеер дает возможность используя малоквалифицированную рабочую силу давать более массовый и качественный продукт.
А что-то большое позволяет создавать мануфактура ( http://wapedia.mobi/ru/Мануфактура ) в которой уже вполне развито разделение труда.
Кстати самые "большие", например космическая отрасль, производство самолетов и судов обходятся без конвеера

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

CU>Я ж и говорю — ещё не "развились" до "промышленного использования", но уже есть. Надо работать дальше...

По моему гораздо выгоднее для нас ( программистов ) идти в другую сторону
Тем более сам вид дейтельности к этому располагает.

Здравствуйте, FR, Вы писали:

CU>>Да я просто стараюсь двести мысль, что "программирование" в массе своей _должно_ (не спрашивайте "кому?" ) выйти из сферы "кто хочет — тот и пишет" (оговорюсь — если это не хобби) в разряд "индустриального производства" — с контролем качества, гарантиями и прочим. А "для всех" но "по работе" пусть будет "безопасное скриптование" для какой-нибудь VM в safe mode

FR>В производстве же софта только научились кое как использовать низкоквалифицированную рабочую силу при этом производительность в расчете на человека наооборот падает, то есть уровень мануфактур.

Ну так это же не конец...

Здравствуйте, FR, Вы писали:

FR>Один вопрос за счет чего оно будет выдавать больше?

Унификация? Стандарты? Уменьшение "велосипедостроительства"?

CU>>Его _надо_ проверять! Уже и сейчас. Но все до сих пор шарахаются от этого. В харчевнях тоже никакого "сан/эпида" не было — ничего, привыкли

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

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

Здравствуйте, FR, Вы писали:

FR>По моему гораздо выгоднее для нас ( программистов ) идти в другую сторону

В какую же? Но только с качеством, гарантиями и прочим...

FR>Тем более сам вид дейтельности к этому располагает.

Чем?

Здравствуйте, FR, Вы писали:

FR>В производстве же софта только научились кое как использовать низкоквалифицированную рабочую силу при этом производительность в расчете на человека наооборот падает, то есть уровень мануфактур.

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

Здравствуйте, Cyberax, Вы писали:

C>В общем, как оказалось, для CAS совсем не нужно переписывать все на managed-код.

Да, достаточно перейти на тотальный message passing. St — ау-у!

Здравствуйте, cl-user, Вы писали:

FR>>Один вопрос за счет чего оно будет выдавать больше?

CU>Унификация? Стандарты? Уменьшение "велосипедостроительства"?

Это, проценты а не порядки.

CU>А я предлагал "загонять"? Сорри, если мои слова могли сойти за такое... Нет, я имел в виду, что _большинство_ "мелких ремесленников" (и не только) "отвалится" при необходимости внедрять системы контроля качества, проходить сертификацию, давать гарантии и прочее. Не более того.

В результате лишимся мелочи и не улучшим качества.

Здравствуйте, FR, Вы писали:

CU>>Унификация? Стандарты? Уменьшение "велосипедостроительства"?

FR>Это, проценты а не порядки.

+качество, которое так просто не "опроцентуешь"

CU>>А я предлагал "загонять"? Сорри, если мои слова могли сойти за такое... Нет, я имел в виду, что _большинство_ "мелких ремесленников" (и не только) "отвалится" при необходимости внедрять системы контроля качества, проходить сертификацию, давать гарантии и прочее. Не более того.

FR>В результате лишимся мелочи и не улучшим качества.

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

Здравствуйте, cl-user, Вы писали:

CU>Здравствуйте, FR, Вы писали:

FR>>По моему гораздо выгоднее для нас ( программистов ) идти в другую сторону

CU>В какую же? Но только с качеством, гарантиями и прочим...

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

FR>>Тем более сам вид дейтельности к этому располагает.

CU>Чем?

Тем что

Если вы разрабатываете ПО, вашим основным строительным материалом является интеллект,
а главным инструментом — вы сами.

Здравствуйте, Трурль, Вы писали:

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

Угу, только разделение труда приводило не только к снижению, но и повышению требований к квалификации. Конвеер же приводит только к снижению.

Здравствуйте, FR, Вы писали:

FR>>>По моему гораздо выгоднее для нас ( программистов ) идти в другую сторону

CU>>В какую же? Но только с качеством, гарантиями и прочим...

FR>В такую чтобы производительность и качество труда росли с ростом квалификации.

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

FR>Кстати в другой стороне гарантий тоже никаких.

Пока — да, никаких (или мне о них не известно). Но за это и боремся...

FR>>>Тем более сам вид дейтельности к этому располагает.

CU>>Чем?

FR>Тем что
FR>

FR>Если вы разрабатываете ПО, вашим основным строительным материалом является интеллект,
FR>а главным инструментом — вы сами.

<joke-mode>
И эти люди, так кичащиеся своим интеллектом, будут меня обвинять в шовинизме?
<joke-mode/>

Если вы такие умные — пишите "программы группы А/I", если не такие — пишите "байткод" для "группы А/II". А всем остальным оставьте "безопасный скриптинг в группе Б"

Здравствуйте, cl-user, Вы писали:

CU>+качество, которое так просто не "опроцентуешь"

И получать которое с помощью массовости в производстве ПО еще не научились. В ту же висту вложили просто гигантские средства для улучшения качества, но его что-то не очень заметно.

CU>>>А я предлагал "загонять"? Сорри, если мои слова могли сойти за такое... Нет, я имел в виду, что _большинство_ "мелких ремесленников" (и не только) "отвалится" при необходимости внедрять системы контроля качества, проходить сертификацию, давать гарантии и прочее. Не более того.

FR>>В результате лишимся мелочи и не улучшим качества.

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

На собственной шкуре будем испытывать "качество" продуктов типа Windows Vista.

Здравствуйте, FR, Вы писали:

CU>>+качество, которое так просто не "опроцентуешь"

FR>И получать которое с помощью массовости в производстве ПО еще не научились.

Но это же не значит, что это невозможно в принципе?

FR>На собственной шкуре будем испытывать "качество" продуктов типа Windows Vista.

Вас заставляют? Меня — нет. В офисе везде ещё W2k стоят — и ничего... А уж дома и подавно — зачем? Вот добровольно испытывать качество OS продуктов (нужных мне) я согласен.

Здравствуйте, cl-user, Вы писали:

FR>>В такую чтобы производительность и качество труда росли с ростом квалификации.

CU>Ах да, я как-то совсем упустил из виду "выгоднее для нас ( программистов )"... Извините, но похоже что пользователям всё больше и больше "с вами не по пути"

Угу им по пути с ms, в их продуктах скоро чтобы просто запустить программу надо будет получать разрешения из ЦК тьфу от собрания акционеров

Пользователям по пути с тем кто делает реально качественные продукты, к счасть качество с размеров фирмы производителя практически не коррелирует.

FR>>Кстати в другой стороне гарантий тоже никаких.

CU>Пока — да, никаких (или мне о них не известно). Но за это и боремся...

А вдруг сучок допилите

FR>>Тем что
FR>>

FR>>Если вы разрабатываете ПО, вашим основным строительным материалом является интеллект,
FR>>а главным инструментом — вы сами.

CU><joke-mode>
CU>И эти люди, так кичащиеся своим интеллектом, будут меня обвинять в шовинизме?
CU><joke-mode/>

Тебя и Макконнелл в этом уже обвинил?

CU>Если вы такие умные — пишите "программы группы А/I", если не такие — пишите "байткод" для "группы А/II". А всем остальным оставьте "безопасный скриптинг в группе Б"

Вот кстати, такие указания вполне повод для обвинения

Здравствуйте, cl-user, Вы писали:

FR>>И получать которое с помощью массовости в производстве ПО еще не научились.

CU>Но это же не значит, что это невозможно в принципе?

Нуу в _принципе_ и обратное вполне возможно

FR>>На собственной шкуре будем испытывать "качество" продуктов типа Windows Vista.

CU>Вас заставляют? Меня — нет. В офисе везде ещё W2k стоят — и ничего... А уж дома и подавно — зачем? Вот добровольно испытывать качество OS продуктов (нужных мне) я согласен.

Так пока не заставляют, но если ваши мечты сбудутся то уже никуда ни дется будет.

Здравствуйте, FR, Вы писали:

FR>>>В такую чтобы производительность и качество труда росли с ростом квалификации.

CU>>Ах да, я как-то совсем упустил из виду "выгоднее для нас ( программистов )"... Извините, но похоже что пользователям всё больше и больше "с вами не по пути"

FR>Угу им по пути с ms, в их продуктах скоро чтобы просто запустить программу надо будет получать разрешения из ЦК тьфу от собрания акционеров

не надо всё мерять "в пересчёте на домохозяек" — той же IBM как-то MS не так чтобы поперёк горла стояла...

FR>Пользователям по пути с тем кто делает реально качественные продукты, к счасть качество с размеров фирмы производителя практически не коррелирует.

Только пора уже научится определять качество "не субъективными" методами. И ставить на продукции соответствующее клеймо. А к размерам фирмы — да, никаких претензий...

FR>>>Кстати в другой стороне гарантий тоже никаких.

Да их нигде не будет, пока их не начнут требовать.

CU>>Пока — да, никаких (или мне о них не известно). Но за это и боремся...

FR>А вдруг сучок допилите

нереально

CU>>Если вы такие умные — пишите "программы группы А/I", если не такие — пишите "байткод" для "группы А/II". А всем остальным оставьте "безопасный скриптинг в группе Б"

FR>Вот кстати, такие указания вполне повод для обвинения

Нет, это, в первую очередь, желание "обезопасить" группу A/I, а остальные и так "подтянуться".

Здравствуйте, FR, Вы писали:

FR>>>И получать которое с помощью массовости в производстве ПО еще не научились.

CU>>Но это же не значит, что это невозможно в принципе?

FR>Нуу в _принципе_ и обратное вполне возможно

Я и не спорю — я говорю: давайте определять качество

CU>>Вас заставляют? Меня — нет. В офисе везде ещё W2k стоят — и ничего... А уж дома и подавно — зачем? Вот добровольно испытывать качество OS продуктов (нужных мне) я согласен.

FR>Так пока не заставляют, но если ваши мечты сбудутся то уже никуда ни дется будет.

Как контроль качества и требование гарантий помогут MS одолеть конкурентов?

Здравствуйте, cl-user, Вы писали:

CU>Да их нигде не будет, пока их не начнут требовать.

Не требовать бесполезно, вот если будут готовы за это платить, тогда да.

Здравствуйте, cl-user, Вы писали:

FR>>Так пока не заставляют, но если ваши мечты сбудутся то уже никуда ни дется будет.

CU>Как контроль качества и требование гарантий помогут MS одолеть конкурентов?

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

Здравствуйте, FR, Вы писали:

CU>>Да их нигде не будет, пока их не начнут требовать.

FR>Не требовать бесполезно, вот если будут готовы за это платить, тогда да.

Во-первых, _уже_ платят за гарантии в виде поддержки или за готовые sw+hw комплексы "под ключ". Понятно, что это только увеличит цену. Но и требовать таки надо (возможно не сразу и на всё, а постепенно). Но как в итого срок годности должен быть на любом продукте, так и на софт должны распространятся гарантии. Это не гарантии того, что софт совсем глючить не будет (как нет и гарантии не отравиться годным продуктом) — это гарантии того, что производитель кровно заинтересован свести риски к минимуму.

Здравствуйте, FR, Вы писали:

FR>Тык вроде разговор начинался с того что разгоним всю мелочь а монстров заставим ходить строем, тьфу соблюдать качество

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

Здравствуйте, cl-user, Вы писали:

CU>Не, это я "перепрыгнул" сразу к следствиям: при наличии требований качества и гарантий большинство кодеров пойдут искать другой хлеб

Угу только большинству пользователей от этого станет хуже

Здравствуйте, cl-user, Вы писали:

FR>>Не требовать бесполезно, вот если будут готовы за это платить, тогда да.

CU>Во-первых, _уже_ платят за гарантии в виде поддержки или за готовые sw+hw комплексы "под ключ". Понятно, что это только увеличит цену. Но и требовать таки надо (возможно не сразу и на всё, а постепенно). Но как в итого срок годности должен быть на любом продукте, так и на софт должны распространятся гарантии. Это не гарантии того, что софт совсем глючить не будет (как нет и гарантии не отравиться годным продуктом) — это гарантии того, что производитель кровно заинтересован свести риски к минимуму.

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

Здравствуйте, FR, Вы писали:

CU>>Не, это я "перепрыгнул" сразу к следствиям: при наличии требований качества и гарантий большинство кодеров пойдут искать другой хлеб

FR>Угу только большинству пользователей от этого станет хуже

Ну, у большинства любые перемены вызывают ощущение "хуже" и им не докажешь, что "без перемен" — это смерть (и то не уверен )

Здравствуйте, cl-user, Вы писали:

FR>>Угу только большинству пользователей от этого станет хуже

CU>Ну, у большинства любые перемены вызывают ощущение "хуже" и им не докажешь, что "без перемен" — это смерть (и то не уверен )

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

Здравствуйте, FR, Вы писали:

CU>>Во-первых, _уже_ платят за гарантии в виде поддержки или за готовые sw+hw комплексы "под ключ". Понятно, что это только увеличит цену. Но и требовать таки надо (возможно не сразу и на всё, а постепенно). Но как в итого срок годности должен быть на любом продукте, так и на софт должны распространятся гарантии. Это не гарантии того, что софт совсем глючить не будет (как нет и гарантии не отравиться годным продуктом) — это гарантии того, что производитель кровно заинтересован свести риски к минимуму.

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

Я подозреваю что большая часть "софт областей" и не нужна. По крайней мере тонны варезников с мелкими утилитками по 5$ с громкими названиями и описаниями — жизни не хватит если доверится описаниям и начать пробовать... Ходят ведь в итоге практически все в однотипной одежде, ездят в ещё более однотипных машинах, жуют одно и тоже (специи не в счёт) — и ничего? Опять же, я не про музыку и литературу — я исключительно про производство

Здравствуйте, cl-user, Вы писали:

CU>Я подозреваю что большая часть "софт областей" и не нужна.

А вот это уже определяет пользователь своим кошельком.

CU>По крайней мере тонны варезников с мелкими утилитками по 5$ с громкими названиями и описаниями — жизни не хватит если доверится описаниям и начать пробовать... Ходят ведь в итоге практически все в однотипной одежде, ездят в ещё более однотипных машинах, жуют одно и тоже (специи не в счёт) — и ничего? Опять же, я не про музыку и литературу — я исключительно про производство

Тык большинство этих утилит как раз их области "музыки и литературы"

Здравствуйте, FR, Вы писали:

FR>Тут все будет очень объективно, программ станет меньше, они станут сложнее в использовании, и стоить существенно дороже. При этом разница в качестве для простого пользователя будет почти незаметна

Программ станет меньше — да.

Сложнее в использовании — с чего? В написании — да. В сопровождении — да. В использовании — почему? Конкуренты не дремлют...

Стоить дороже — да.

Для простого пользователя? А может не надо его так сильно "упрощать". Я в своих дествиях на 80% (если не 95) могу себя отнести к "простым пользователям" — этого хватает чтобы очень часто вспоминать "незлым тихим словом" авторов программ и судорожно принимать выбор — лезть в инет за решением или "по быстрому" решить всё с copy&paste. К хорошему привыкаешь быстро — кого сейчас заставишь регулярно "перебирать движок 21-й", а когда-то водитель==автослесарь.

Здравствуйте, FR, Вы писали:

CU>>Я подозреваю что большая часть "софт областей" и не нужна.

FR>А вот это уже определяет пользователь своим кошельком.

ну — с одеждой и едой уже рассудили

CU>>По крайней мере тонны варезников с мелкими утилитками по 5$ с громкими названиями и описаниями — жизни не хватит если доверится описаниям и начать пробовать... Ходят ведь в итоге практически все в однотипной одежде, ездят в ещё более однотипных машинах, жуют одно и тоже (специи не в счёт) — и ничего? Опять же, я не про музыку и литературу — я исключительно про производство

FR>Тык большинство этих утилит как раз их области "музыки и литературы"

Для авторов — да. Для пользователей — гербалайф и биодобавки...

Здравствуйте, cl-user, Вы писали:

CU>Здравствуйте, FR, Вы писали:

FR>>Тут все будет очень объективно, программ станет меньше, они станут сложнее в использовании, и стоить существенно дороже. При этом разница в качестве для простого пользователя будет почти незаметна

CU>Программ станет меньше — да.

CU>Сложнее в использовании — с чего? В написании — да. В сопровождении — да. В использовании — почему? Конкуренты не дремлют...

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

CU>Стоить дороже — да.

CU>Для простого пользователя? А может не надо его так сильно "упрощать". Я в своих дествиях на 80% (если не 95) могу себя отнести к "простым пользователям" — этого хватает чтобы очень часто вспоминать "незлым тихим словом" авторов программ и судорожно принимать выбор — лезть в инет за решением или "по быстрому" решить всё с copy&paste. К хорошему привыкаешь быстро — кого сейчас заставишь регулярно "перебирать движок 21-й", а когда-то водитель==автослесарь.

Так будет еще хуже, без "настройщика" ничего ни сможешь

Здравствуйте, cl-user, Вы писали:


CU>ну — с одеждой и едой уже рассудили

Угу мелочь живет в этой отрасли очень неплохо

CU>>>По крайней мере тонны варезников с мелкими утилитками по 5$ с громкими названиями и описаниями — жизни не хватит если доверится описаниям и начать пробовать... Ходят ведь в итоге практически все в однотипной одежде, ездят в ещё более однотипных машинах, жуют одно и тоже (специи не в счёт) — и ничего? Опять же, я не про музыку и литературу — я исключительно про производство

FR>>Тык большинство этих утилит как раз их области "музыки и литературы"

CU>Для авторов — да. Для пользователей — гербалайф и биодобавки...

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

Здравствуйте, FR, Вы писали:

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

И выходит несколько странное (мертворождённое?) явление — "эволюция без мутаций"

Здравствуйте, FR, Вы писали:

CU>>Сложнее в использовании — с чего? В написании — да. В сопровождении — да. В использовании — почему? Конкуренты не дремлют...

FR>Конкуренты уже все разорились

далеко не все. Только любители "безответственности" и "халявы"

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

Т.е. если бы вместо ОО было 48 маленьких программ (да ещё и каждая со своим а не унифицированным интерфейсам) никак друг с другом не взаимодействующие (разве что через потоки I/O) — было бы лучше и проще? Странные у вас понятия...

CU>>Для простого пользователя? А может не надо его так сильно "упрощать". Я в своих дествиях на 80% (если не 95) могу себя отнести к "простым пользователям" — этого хватает чтобы очень часто вспоминать "незлым тихим словом" авторов программ и судорожно принимать выбор — лезть в инет за решением или "по быстрому" решить всё с copy&paste. К хорошему привыкаешь быстро — кого сейчас заставишь регулярно "перебирать движок 21-й", а когда-то водитель==автослесарь.

FR>Так будет еще хуже, без "настройщика" ничего ни сможешь

1C-ника "дороже" обучить нежели кодера? Опять непонятки...

Здравствуйте, FR, Вы писали:

CU>>ну — с одеждой и едой уже рассудили

FR>Угу мелочь живет в этой отрасли очень неплохо

Угу, после того как "приняла" стандарты/правила.

CU>>Для авторов — да. Для пользователей — гербалайф и биодобавки...

FR>Нет для авторов часто как раз часто наоборот, каторжный труд

"каторжный" — это когда завтра доделывать то, что не сделал сегодня. Многие пишут хоть с малейшим предположением дальнейшего сопровождения? Не смешите меня.

FR>А для пользователей скорей рюшечки и бантики а не гербалайф

То-же самое — хорошо если вреда нет, но пользы точно никакой.

Здравствуйте, Курилка, Вы писали:

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

К>И выходит несколько странное (мертворождённое?) явление — "эволюция без мутаций"

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

Здравствуйте, cl-user, Вы писали:

CU>Здравствуйте, Курилка, Вы писали:

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

К>>И выходит несколько странное (мертворождённое?) явление — "эволюция без мутаций"

CU>Да нет — с мутациями. Только "выход годных" догнать бы хоть до совковой микроэлектроники, а то подозреваю он ещё на порядок меньше...

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

Здравствуйте, cl-user, Вы писали:

C>>Ну тогда это уже решили. Открываешь файл с помощью D-BUS, получаешь от него дескриптор и работаешь с ним как обычно.
CU>таки это нади писать
?

C>>Зачем? Смысл в том, чтобы посадить в клетку программу, которая выполняет опасные действия (такие как просмотр web-страничек). Программы из "доверяемого периметра" можно в клетку не сажать.
CU>Либо доверяемых программ будет слишком мало (и будет очень сложно регулировать уровни безопасности большинства программ) либо основная опасность так и останется в "доверенных" но дырявых прогах.
Нет. Опасны те программы, которые исполняют недоверяемые данные. Такие программы обычно можно достаточно неплохо изолировать.

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

CU>Имхо, контроль стека "гуардам" не противовес и не помеха, а доп. кирпич в "стенку безопасности", но и то и другое "2-й эшелон" по сравнению с качеством самих программ.
Stack guards и прочее — это дополнительная защита, но надеяться на нее ни в коем случае нельзя. Так как при желании она обходится.

CU>>>В IT области? Не слышал... И я уже писал — это должно быть "вершиной айсберга", а не его основой.
C>>ISO 9000 везде действует.
CU>Но везде ли применяется?
Нет, ибо нафиг не нужен. Возьми и прочти его, какие проблемы-то? По нему тонны литературы написаны.

Здравствуйте, cl-user, Вы писали:

CU>Угу, после того как "приняла" стандарты/правила.

И без них неплохо жила, да и сейчас умудряется не соблюдать и не только мелочь

CU>>>Для авторов — да. Для пользователей — гербалайф и биодобавки...

FR>>Нет для авторов часто как раз часто наоборот, каторжный труд

CU>"каторжный" — это когда завтра доделывать то, что не сделал сегодня. Многие пишут хоть с малейшим предположением дальнейшего сопровождения? Не смешите меня.

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

FR>>А для пользователей скорей рюшечки и бантики а не гербалайф

CU>То-же самое — хорошо если вреда нет, но пользы точно никакой.

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

Здравствуйте, cl-user, Вы писали:

FR>>Конкуренты уже все разорились

CU>далеко не все. Только любители "безответственности" и "халявы"

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

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

CU>Т.е. если бы вместо ОО было 48 маленьких программ (да ещё и каждая со своим а не унифицированным интерфейсам) никак друг с другом не взаимодействующие (разве что через потоки I/O) — было бы лучше и проще? Странные у вас понятия...

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

CU>>>Для простого пользователя? А может не надо его так сильно "упрощать". Я в своих дествиях на 80% (если не 95) могу себя отнести к "простым пользователям" — этого хватает чтобы очень часто вспоминать "незлым тихим словом" авторов программ и судорожно принимать выбор — лезть в инет за решением или "по быстрому" решить всё с copy&paste. К хорошему привыкаешь быстро — кого сейчас заставишь регулярно "перебирать движок 21-й", а когда-то водитель==автослесарь.

FR>>Так будет еще хуже, без "настройщика" ничего ни сможешь

CU>1C-ника "дороже" обучить нежели кодера? Опять непонятки...

Тема в том что тебе чтобы полноценно пользоватся OO нужен будет настройщик

Здравствуйте, Cyberax, Вы писали:

Какие-то велосипеды всё однако.

C>Эта штуковина позволяет делать почти полноценный code access security для обычных приложений. Если кратко, то оно работает так — есть шина обмена сообщениями D-BUS (это COM с человеческим лицом), на нее вешаются сервисы, выполняющие restricted-операции, они работают в контекстах безопасности, с достаточными правами.

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


C>Процессы, которым нужно сделать какие-то запрещенные операции соединяется через PolicyKit с нужным сервисом и просит выполнить авторизацию. PolicyKit проверяет права текущего пользователя, может быть спрашивает пароль, и дает (или не дает) доступ вызывающему процессу к нужной службе.

Windows (начиная с NT 4.0): старая добрая COM-security, ограничивающая доступ к объекту. А в общем случае — это уже проблема конкретного сервиса проверить пользователя, который к нему постучался, на доступ к тому или иному ресурсу. А если ресурса нет, то и проверять нечего...


C>Кроме того, тут в дело вступает еще один компонент системы — AppArmor. Это ядерный модуль, который позволяет ограничить права одного конкретно взятого процесса. Например, можно сделать так, чтобы FireFox не имел доступа ни к каким файлам кроме своего каталога плугинов. Совместно с PolicyKit он может использоваться для изоляции опасных процессов.

Windows Server 2008: Integrity Levels, для сервисов — Service Security Identifier (можно явно ограничить права доступа сервиса к тому или иному ресурсу, не заводя для этого отдельного пользователя). Есть ещё Protected Processes — спорная технология и пока толком не понятная, но теоретически вполне юзабельная.


C>Если я нажимаю на кнопку "Unlock" — то у меня появляется окно, в котором я ввожу свой пароль, после чего приложение "Network Settings" получает права на работу с настройками сети, но ни с чем иным.

Windows Server 2008: UAC


C>В общем, как оказалось, для CAS совсем не нужно переписывать все на managed-код.

А при чём здесь managed-код?

Здравствуйте, Mr. None, Вы писали:

C>>Эта штуковина позволяет делать почти полноценный code access security для обычных приложений. Если кратко, то оно работает так — есть шина обмена сообщениями D-BUS (это COM с человеческим лицом), на нее вешаются сервисы, выполняющие restricted-операции, они работают в контекстах безопасности, с достаточными правами.
MN>А нафига? Если я буду писать шпиона, то точно не буду использовать D-BUS, чтобы мои операции не ограничили в правах...
Если у тебя есть администраторский доступ к компьютеру — то ничего уже не защитит от твоих шпионов (хотя...). Смысл PolicyKit+AppArmor — защитить систему от атак или, в худшем случае, минимизировать ущерб от атаки.

C>>Процессы, которым нужно сделать какие-то запрещенные операции соединяется через PolicyKit с нужным сервисом и просит выполнить авторизацию. PolicyKit проверяет права текущего пользователя, может быть спрашивает пароль, и дает (или не дает) доступ вызывающему процессу к нужной службе.
MN>Windows (начиная с NT 4.0): старая добрая COM-security, ограничивающая доступ к объекту.
Так я же сказал, что DBUS — это COM с человеческим лицом В том смысле, что там вещи типа настроек безопасности используются легко и просто, в отличие от COM.

MN>А в общем случае — это уже проблема конкретного сервиса проверить пользователя, который к нему постучался, на доступ к тому или иному ресурсу. А если ресурса нет, то и проверять нечего...
Вот тебе задача — надо дать пользователю менять настройки TCP/IP (это административное действие). Причем только из одной программы (NetworkManager), чтобы вирус из FireFox не смог, например, поменять DNS на hackerdns.hacker.com

На PolicyKit+AppArmor решается все просто — делается служба по изменению адреса и вешается на D-BUS. У этой службы указывается, что нужен "IP Change Permission" у вызывающего процесса. Этот permission дан программе управления сетью, которая дополнительно защищена AppArmor'ом от поползновений в ее адресное пространство со стороны других программ.

Дополнительно, если в самой NetworkManager будут какие-то уязвимости, то в крайнем случае атакующий получит возможность менять настройки сети, но не получит полных прав root'а.

В Vista сделано подобное с помощью UAC, но оно сделано ужасно криво — пользователи просто всегда нажимают "OK". В Линуксе это делают так, что пользователю никогда не надо будет смотреть что там написано в диалоге, так как пользователь будет сам явно иницировать нужное действие. Ну и кроме того, UAC поднимает привиллегии всего процесса целиком до админивского уровня. Это примерно то же самое, что УЖЕ есть в Linux'ах и от чего хотят избавиться — автоматическое выполнение sudo для административных программ.

MN>Windows Server 2008: Integrity Levels, для сервисов — Service Security Identifier (можно явно ограничить права доступа сервиса к тому или иному ресурсу, не заводя для этого отдельного пользователя). Есть ещё Protected Processes — спорная технология и пока толком не понятная, но теоретически вполне юзабельная.
Нет, даже близко по удобству не стоит. В Линуксе все просто — для исполняемого файла (ЛЮБОГО, не обязательнл сервиса) просто прописывается простой профиль типа:

#include <tunables/global>
/usr/lib/firefox/firefox flags=(complain) {
  #include <abstractions/base>
  #include <abstractions/nameservice>

  capability sys_ptrace,

  / r,
  /bin/dash ixr,
  /bin/grep ixr,
  /bin/ls ixr,
  /bin/ps ixr,
  /bin/pwd ixr,
  /bin/sed ixr,
  /bin/which ixr,
  /dev/snd/controlC0 rw,
...
  /var/tmp/ rw,
}

При запуске файла AppArmor сам подхватит нужный профиль, который ставится вместе с приложением.

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

C>>Если я нажимаю на кнопку "Unlock" — то у меня появляется окно, в котором я ввожу свой пароль, после чего приложение "Network Settings" получает права на работу с настройками сети, но ни с чем иным.
MN>Windows Server 2008: UAC
Выше написал уже

C>>В общем, как оказалось, для CAS совсем не нужно переписывать все на managed-код.
MN>А при чём здесь managed-код?
Так тут флеймы такие в свое время были.

Здравствуйте, FR, Вы писали:

FR>тот же Форд добился того, что используя более низкоквалифицированную рабочую силу смог поднять производительность труда (в том числе в расчете на человека) на порядки.

Мне кажется, вы увлеклись ложными аналогиями. Какие паровые двигатели? Какие конвейеры? Фордовский конвейер имеет отношение к тиражированию продукции, а не к исследованиям, разработке и проектированию — а софтверная индустрия — это одни только разработка и проектирование, не так ли? Тиражирование ПО тривиально.

Здравствуйте, Cyberax, Вы писали:

C>Здравствуйте, Mr. None, Вы писали:

C>>>Эта штуковина позволяет делать почти полноценный code access security для обычных приложений. Если кратко, то оно работает так — есть шина обмена сообщениями D-BUS (это COM с человеческим лицом), на нее вешаются сервисы, выполняющие restricted-операции, они работают в контекстах безопасности, с достаточными правами.
MN>>А нафига? Если я буду писать шпиона, то точно не буду использовать D-BUS, чтобы мои операции не ограничили в правах...
C>Если у тебя есть администраторский доступ к компьютеру — то ничего уже не защитит от твоих шпионов (хотя...). Смысл PolicyKit+AppArmor — защитить систему от атак или, в худшем случае, минимизировать ущерб от атаки.

Мой коммент был у другом. Чтобы всё это заработало надо применять специальную технику управлению ресурсами. То есть не обычные системные вызовы, а плясать с бубном вокруг специального защищённого интерфейса. Где-нибудь да проколишься всё равно. Плюс, это не защищает от программ, которые будут использовать обычные системные интерфейсы, а не указанный безопасный... А теперь рассмотрим ситуацию — программа, использующая только указанный безопасный интерфейс, с широкими полномочиями, но где-то в ней косяк приводящий к выполнению построннего кода (хоть локальный, хоть удалённый). Мне, как автору этого зловредного кода, абсолютно по барабану, что уязвимая программа использует защищённый интерфейс — мой код будет использовать общесистемные не защищённые методы.... Последствия ясны.


C>>>Процессы, которым нужно сделать какие-то запрещенные операции соединяется через PolicyKit с нужным сервисом и просит выполнить авторизацию. PolicyKit проверяет права текущего пользователя, может быть спрашивает пароль, и дает (или не дает) доступ вызывающему процессу к нужной службе.
MN>>Windows (начиная с NT 4.0): старая добрая COM-security, ограничивающая доступ к объекту.
C>Так я же сказал, что DBUS — это COM с человеческим лицом В том смысле, что там вещи типа настроек безопасности используются легко и просто, в отличие от COM.

Я немного о другом, в данном случае речь об использовании COM`а для организации разграничения доступа к функциональности сервиса. Пишется COM-объект с контекстом запуска LOCAL_SERVER (точнее в данном случае это уже DCOM) либо с авто-запуском, либо живущий в некотором сервисе. И доступ к объекту ограничивается посредством обычного механизма COM-security. Получили сервис с разграничением доступа, интерфейсом к которому является COM. Если проводить аналоги между DBUS и PolicyKit, то это как раз DBUS с интегрированным PolicyKit и отдельно PolicyKit не нужен вообще.


MN>>А в общем случае — это уже проблема конкретного сервиса проверить пользователя, который к нему постучался, на доступ к тому или иному ресурсу. А если ресурса нет, то и проверять нечего...
C>Вот тебе задача — надо дать пользователю менять настройки TCP/IP (это административное действие). Причем только из одной программы (NetworkManager), чтобы вирус из FireFox не смог, например, поменять DNS на hackerdns.hacker.com

Вот тебе отдача:
при включенном UAC (а вы его что отключаете на сервере? нехорошо, нехорошо...) менять настройки TCP/IP вообще без подтверждения нельзя ни одному процессу. А FireFox вообще запускаем с Integrity Level`ом "Low Mandatory Level" чтобы он вообще ничего не мог менять и даже вопросов не задавал (настраивается с помощью стандартного UI). Так что вообще ничего писать не надо.


C>На PolicyKit+AppArmor решается все просто — делается служба по изменению адреса и вешается на D-BUS.

Ну уже всё не просто раз "делается служба" см. решение для Windows Server 2008...


C>Дополнительно, если в самой NetworkManager будут какие-то уязвимости, то в крайнем случае атакующий получит возможность менять настройки сети, но не получит полных прав root'а.

C>В Vista сделано подобное с помощью UAC, но оно сделано ужасно криво — пользователи просто всегда нажимают "OK". В Линуксе это делают так, что пользователю никогда не надо будет смотреть что там написано в диалоге, так как пользователь будет сам явно иницировать нужное действие. Ну и кроме того, UAC поднимает привиллегии всего процесса целиком до админивского уровня. Это примерно то же самое, что УЖЕ есть в Linux'ах и от чего хотят избавиться — автоматическое выполнение sudo для административных программ.

Во-первых, раз уж мы сравниваем серверные решения, то давайте говорить о Windows Server 2008, а не Vista... Ни один администратор на серверной системе в здравом уме и твёрдой памяти не щёлкнет на OK, не посмотрев, что же там сказано. Это было во-первых, теперь во-вторых. У вас не верные сведения о UAC. Диалог с предложением поднять привилегии, если вы залогинились под административным аккаунтом (AAM), или ввести логин/пароль, если вы обычный пользователь (OTS) выводятся только, если вы предприняли специальные действия в своей программе (добавили определённый атрибут в манифест), во всех остальных случаях в момент обращения к защищённым ресурсам появится другое окошко: "Access deny". И запустить такое приложение с поднятыми привилегиями можно только с помощью специальной кнопки в интерфейсе файл-менеджера (по сути сделать Run as). Так что и тут ничего писать не надо — кнопка уже есть... Ну и наконец, в-третьих, процессу не только поднимаются привилегии, но и меняется Integrity Level на "Hight Mandatory Level", это означает, что ни один процесс с меньшим Integrity Level`ом (а по сути просто ни один процесс, потому что по дефолту с "Hight Mandatory Level" выполняются только процессы AAM и OTS) не сможет ни прочитать, ни записать ни один объект или кусок памяти этого процесса.


MN>>Windows Server 2008: Integrity Levels, для сервисов — Service Security Identifier (можно явно ограничить права доступа сервиса к тому или иному ресурсу, не заводя для этого отдельного пользователя). Есть ещё Protected Processes — спорная технология и пока толком не понятная, но теоретически вполне юзабельная.
C>Нет, даже близко по удобству не стоит. В Линуксе все просто — для исполняемого файла (ЛЮБОГО, не обязательнл сервиса) просто прописывается простой профиль типа:
C>При запуске файла AppArmor сам подхватит нужный профиль, который ставится вместе с приложением.

Опять же совсем не просто . Обычному приложению это редко нужно, а для сервисов в Windows Server 2008 "сервисный аккаунт" создаётся автоматически при регистрации сервиса ничего писать не надо. Дальше права для этого "аккаунта" вы раздаёте как хотите, хоть руками, хоть через программу установки. Вы даже можете использовать эту возможность для сервисов, которые были написаны до выхода Windows Server 2008 и ничего не знали о "сервисных аккаунтах".


C>>>В общем, как оказалось, для CAS совсем не нужно переписывать все на managed-код.
MN>>А при чём здесь managed-код?
C>Так тут флеймы такие в свое время были.

О чём флэйм? Всё тоже самое есть в Windows Server 2008, даже больше, местами даже раньше, в большинстве случаев даже программить ничего не надо — всё есть автоматом, сиди и настраивай только... В случае огромных систем — это ой как полезно...

Здравствуйте, Курилка, Вы писали:

К>В общем — я так и не услышал, где же в написании программ типовые приёмы, отточив которые можно штамповать хорошие программы. Только не надо про паттерны и иже с ними — практика уже по-моему достаточна показала, что остаётся справедливой поговорка про "заставь дурака богу молиться".

Т.е. вроде как приёмы есть, но нет "приёмов" научить их правильно использовать любого? А я говорил — что надо? Всё что я говорю — вопрос качества перенести из области for-fun в правовую область. Всё остальное — это _вероятные_ следствия.

К>В общем — ключевым инструментом разработчика считаю его мозг (иде и язык программирования по мне лишь для грубой обработки типа рашпиля). Ты же по сути получается призываешь стандартизировать человеческое мышление, причём по ходу дела получается чуть ли не во всех областях сразу.

Не мышление, а результат его деятельности!!! Это наконец понятно?!

К>Неэффективные системы отомрут сами собой, если будут вменяемые конкуренты, а по поводу вменяемых я не вижу смысла беспокоиться.

Угу, оговорить в законодательстве "вменяемость" производителей и отменить нафиг все сертификации и лицензирование!

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

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

К>В общем каких-то внятных предложений/идей о качестве и о том, как оно должно всю индустрию перелапатить, я не вижу пока

Я не говорю _как_, я говорю — _нужна система сертификации ПО_ (и самих софтописателей — тоже).

К>Так что непонятно, о чём вообще идёт разговор.

О необходимости законодательно требовать от "производителей ПО" сертификации продукции и выдачи гарантий на его работу. Всё.

Здравствуйте, Cyberax, Вы писали:

CU>>таки это нади писать
C>?

Я имел в виду — переписывать все программы (там где это надо, пусть даже это будет делаться одним #define)

C>>>Зачем? Смысл в том, чтобы посадить в клетку программу, которая выполняет опасные действия (такие как просмотр web-страничек). Программы из "доверяемого периметра" можно в клетку не сажать.
CU>>Либо доверяемых программ будет слишком мало (и будет очень сложно регулировать уровни безопасности большинства программ) либо основная опасность так и останется в "доверенных" но дырявых прогах.
C>Нет. Опасны те программы, которые исполняют недоверяемые данные. Такие программы обычно можно достаточно неплохо изолировать.

CU>>>>В IT области? Не слышал... И я уже писал — это должно быть "вершиной айсберга", а не его основой.
C>>>ISO 9000 везде действует.
CU>>Но везде ли применяется?
C>Нет, ибо нафиг не нужен. Возьми и прочти его, какие проблемы-то? По нему тонны литературы написаны.

Т.е. вроде как стандарт есть, но он нафиг не нужен... Я понял — для кодера контроль качества его кода и требование гарантий страшнее чем ладан для чёрта

Здравствуйте, cl-user, Вы писали:

CU>Здравствуйте, Курилка, Вы писали:


К>>В общем каких-то внятных предложений/идей о качестве и о том, как оно должно всю индустрию перелапатить, я не вижу пока

CU>Я не говорю _как_, я говорю — _нужна система сертификации ПО_ (и самих софтописателей — тоже).

А потом ещё сертификации сертификаторов сертификаторов сертификаторов...
Неинтересно.

Здравствуйте, Mr. None, Вы писали:

MN>Мой коммент был у другом. Чтобы всё это заработало надо применять специальную технику управлению ресурсами. То есть не обычные системные вызовы, а плясать с бубном вокруг специального защищённого интерфейса. Где-нибудь да проколишься всё равно. Плюс, это не защищает от программ, которые будут использовать обычные системные интерфейсы, а не указанный безопасный...
С этим все нормально — все привиллегированые системные вызовы требуют root'а. У обычного пользователя его просто не будет, так что системные вызовы просто обломятся с EACCESS.

Сейчас это обходится с помощью sudo — то есть для выполнения административных действий запускается процесс с поднятыми до root'а привиллегиями. Т.е. почти в точности как и UAC в Vista — что как раз позволяет сделать твой сценарий.

PolicyKit ликвидирует потребность запускать весь процесс как root.

MN>А теперь рассмотрим ситуацию — программа, использующая только указанный безопасный интерфейс, с широкими полномочиями, но где-то в ней косяк приводящий к выполнению построннего кода (хоть локальный, хоть удалённый). Мне, как автору этого зловредного кода, абсолютно по барабану, что уязвимая программа использует защищённый интерфейс — мой код будет использовать общесистемные не защищённые методы.... Последствия ясны.
Да, твой код будет обламываться с ошибками защиты доступа.

C>>Так я же сказал, что DBUS — это COM с человеческим лицом В том смысле, что там вещи типа настроек безопасности используются легко и просто, в отличие от COM.
MN>Я немного о другом, в данном случае речь об использовании COM`а для организации разграничения доступа к функциональности сервиса. Пишется COM-объект с контекстом запуска LOCAL_SERVER (точнее в данном случае это уже DCOM) либо с авто-запуском, либо живущий в некотором сервисе. И доступ к объекту ограничивается посредством обычного механизма COM-security.
Да, это вполне возможно. Только вот никто так почти не делает — это сложно и громоздко. Я знаю, я как-то работал с системой безопасности NT. Там без бутылки не разобраться.

MN>Получили сервис с разграничением доступа, интерфейсом к которому является COM. Если проводить аналоги между DBUS и PolicyKit, то это как раз DBUS с интегрированным PolicyKit и отдельно PolicyKit не нужен вообще.
PolicyKit — это система выполнения и хранения авторизации для процесса, включая показ графических диалогов авторизации и т.п.

MN>Вот тебе отдача:
MN>при включенном UAC (а вы его что отключаете на сервере? нехорошо, нехорошо...) менять настройки TCP/IP вообще без подтверждения нельзя ни одному процессу.
Какой сервер? PolicyKit предназначен для user-friendly десктопа.

MN>А FireFox вообще запускаем с Integrity Level`ом "Low Mandatory Level" чтобы он вообще ничего не мог менять и даже вопросов не задавал (настраивается с помощью стандартного UI). Так что вообще ничего писать не надо.
А злой вирус делает buffer overflow в FF, закачивает свое тело на диск и называет его "ОченьБезобиднаяПрограмма.exe". А потом запускает его и обходит UAC.

C>>На PolicyKit+AppArmor решается все просто — делается служба по изменению адреса и вешается на D-BUS.
MN>Ну уже всё не просто раз "делается служба" см. решение для Windows Server 2008...
Почему? Служба — это просто один so-файл (dll то бишь), которая прописана в списке служю DBUS. Ничего сложного.

C>>В Vista сделано подобное с помощью UAC, но оно сделано ужасно криво — пользователи просто всегда нажимают "OK". В Линуксе это делают так, что пользователю никогда не надо будет смотреть что там написано в диалоге, так как пользователь будет сам явно иницировать нужное действие. Ну и кроме того, UAC поднимает привиллегии всего процесса целиком до админивского уровня. Это примерно то же самое, что УЖЕ есть в Linux'ах и от чего хотят избавиться — автоматическое выполнение sudo для административных программ.
MN>Во-первых, раз уж мы сравниваем серверные решения, то давайте говорить о Windows Server 2008, а не Vista...
PolicyKit — это клиентское решение. При обычном непараноидальном режиме в Vista — именно Allow/Deny появляются.

Для сервера есть адский SELinux, где вообще можно сделать так, что даже адимнистратор не сможет прочитать твои данные без мер типа перезагрузки машины или аппаратных снифферов. Там полная реализация MAC (Mandatory Access Control) с поддержкой сетевых меток (т.е. можно сделать чтобы недоверенная служба не могла общаться с доверенной даже через IPC или сеть) и прочих фич.

C>>При запуске файла AppArmor сам подхватит нужный профиль, который ставится вместе с приложением.
MN>Опять же совсем не просто . Обычному приложению это редко нужно, а для сервисов в Windows Server 2008 "сервисный аккаунт" создаётся автоматически при регистрации сервиса ничего писать не надо.
FireFox/ThunderBird? Я лично один раз вирус через эксплоит в нем словил. Еще я бы всякие медиа-плееры точно так же прикрыл бы, так как в них тоже дыры находили.

MN>Дальше права для этого "аккаунта" вы раздаёте как хотите, хоть руками, хоть через программу установки. Вы даже можете использовать эту возможность для сервисов, которые были написаны до выхода Windows Server 2008 и ничего не знали о "сервисных аккаунтах".
Неудобно, появляются проблемы, например, при замене файлов.

C>>Так тут флеймы такие в свое время были.
MN>О чём флэйм?
Было предположение, что CAS неэффективен в unmanaged-системах из-за того, что нельзя контролировать разделение на доверяемый и недоверяемый код.

MN>Всё тоже самое есть в Windows Server 2008, даже больше, местами даже раньше, в большинстве случаев даже программить ничего не надо — всё есть автоматом, сиди и настраивай только... В случае огромных систем — это ой как полезно...
Меньше Я еще про SELinux не начал писать.

Здравствуйте, cl-user, Вы писали:

CU>>>таки это нади писать
C>>?
CU>Я имел в виду — переписывать все программы (там где это надо, пусть даже это будет делаться одним #define)
Можно сделать неинтрузивные обертки. Другое дело, что в Линуксе проще сразу сделать красиво и дописать нужные части нормально.

CU>>>Но везде ли применяется?
C>>Нет, ибо нафиг не нужен. Возьми и прочти его, какие проблемы-то? По нему тонны литературы написаны.
CU> Т.е. вроде как стандарт есть, но он нафиг не нужен... Я понял — для кодера контроль качества его кода и требование гарантий страшнее чем ладан для чёрта
Нет, просто громоздкость процессов не оправдывает обычно результатов. Или положительных результатов в итоге вообще не бывает.

Здравствуйте, FR, Вы писали:

CU>>Угу, после того как "приняла" стандарты/правила.

FR>И без них неплохо жила, да и сейчас умудряется не соблюдать и не только мелочь

Исключения били и будут всегда. Это не повод не устанавливать правила.

CU>>>>Для авторов — да. Для пользователей — гербалайф и биодобавки...

FR>>>Нет для авторов часто как раз часто наоборот, каторжный труд

CU>>"каторжный" — это когда завтра доделывать то, что не сделал сегодня. Многие пишут хоть с малейшим предположением дальнейшего сопровождения? Не смешите меня.

FR>Каторжный как раз получается когда писал программку однодневку, а она "пошла" и приходится ее подерживать и развивать.

Если "однодневка" писалась "под себя", то надо было "отредезайнить" её перед "выходом в тираж". Иначе — ССЗБ.

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

Я не говорю про "иначе", я говорю про "дополнительные условия". Аллё, меня слышно?!!!

Здравствуйте, cl-user, Вы писали:

CU>Если "однодневка" писалась "под себя", то надо было "отредезайнить" её перед "выходом в тираж". Иначе — ССЗБ.

Да конечно мы все нострадамусы задним числом.

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

CU>Я не говорю про "иначе", я говорю про "дополнительные условия". Аллё, меня слышно?!!!

Очень плохо, какие-то помехи на линии
Кто-то тут только-что как раз хотел все административно запретить

Здравствуйте, FR, Вы писали:

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

Откуда такая уверенность? _Всегда_ предпочитаете самодельные (но не вами) колбасные изделия фабричным?

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

CU>>Т.е. если бы вместо ОО было 48 маленьких программ (да ещё и каждая со своим а не унифицированным интерфейсам) никак друг с другом не взаимодействующие (разве что через потоки I/O) — было бы лучше и проще? Странные у вас понятия...

FR>Вместе с ОО сейчас существуют 1048 подобных программ и притом многие из них продаются и конкурируют с бесплатным ОО.

Это ваши домыслы. Я всего лишь хочу, чтобы _продаваемый_ товар сертифицировался и имел гарантии.

FR>Так вот я за то чтобы они и дальше это делали, ты же хочешь чтобы эти 1048 функций добавили к существующим 48 из ОО.

Я не буду против, если их добавят в ОО. Если тот, кто _продавал_ подобия, не может ничего гарантировать — туда ему и дорога.

CU>>1C-ника "дороже" обучить нежели кодера? Опять непонятки...

FR>Тема в том что тебе чтобы полноценно пользоватся OO нужен будет настройщик

Сейчас не нужен (в 99% случаев). Что-то кардинально изменится?

Здравствуйте, Курилка, Вы писали:

CU>>Я не говорю _как_, я говорю — _нужна система сертификации ПО_ (и самих софтописателей — тоже).

К>А потом ещё сертификации сертификаторов сертификаторов сертификаторов...
К>Неинтересно.

Кто бы сомневался.

Здравствуйте, Klapaucius, Вы писали:

K>Мне кажется, вы увлеклись ложными аналогиями. Какие паровые двигатели? Какие конвейеры? Фордовский конвейер имеет отношение к тиражированию продукции, а не к исследованиям, разработке и проектированию — а софтверная индустрия — это одни только разработка и проектирование, не так ли? Тиражирование ПО тривиально.

Архитектура — в большей или меньшей степени "разработка и проектирование"? А любое КБ? Но все они выдают "стандартизированную продукцию". В отличие от.

Здравствуйте, Cyberax, Вы писали:

CU>> Т.е. вроде как стандарт есть, но он нафиг не нужен... Я понял — для кодера контроль качества его кода и требование гарантий страшнее чем ладан для чёрта
C>Нет, просто громоздкость процессов не оправдывает обычно результатов. Или положительных результатов в итоге вообще не бывает.

Повторюсь: отменим вообще всю сертификацию и будем полагаться на "хорошего парня" во всех сферах деятельности?

Здравствуйте, FR, Вы писали:

CU>>Если "однодневка" писалась "под себя", то надо было "отредезайнить" её перед "выходом в тираж". Иначе — ССЗБ.

FR>Да конечно мы все нострадамусы задним числом.

Нет — это сложившаяся порочная практика в софтостроении — разработчик ничего не гарантирует и ни за что не несёт ответственности.

CU>>Я не говорю про "иначе", я говорю про "дополнительные условия". Аллё, меня слышно?!!!

FR>Очень плохо, какие-то помехи на линии
FR>Кто-то тут только-что как раз хотел все административно запретить

Где именно _административно_?

Здравствуйте, cl-user, Вы писали:

CU>Откуда такая уверенность? _Всегда_ предпочитаете самодельные (но не вами) колбасные изделия фабричным?

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

CU>Это ваши домыслы. Я всего лишь хочу, чтобы _продаваемый_ товар сертифицировался и имел гарантии.

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

FR>>Так вот я за то чтобы они и дальше это делали, ты же хочешь чтобы эти 1048 функций добавили к существующим 48 из ОО.

CU>Я не буду против, если их добавят в ОО. Если тот, кто _продавал_ подобия, не может ничего гарантировать — туда ему и дорога.

А тот кто "продает" ОО может что-то гарантировать? Если сейчас обязать гарантировать то из софта останутся только системы управления атомными реакторами.

CU>>>1C-ника "дороже" обучить нежели кодера? Опять непонятки...

FR>>Тема в том что тебе чтобы полноценно пользоватся OO нужен будет настройщик

CU>Сейчас не нужен (в 99% случаев). Что-то кардинально изменится?

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

Здравствуйте, FR, Вы писали:

CU>>Откуда такая уверенность? _Всегда_ предпочитаете самодельные (но не вами) колбасные изделия фабричным?

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

Производители никак не сертифицируются? На производства не накладываются никакие ограничения?

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

Т.е. уберём всякий контроль за всей производимой продукцией и будем только "кошельком голосовать"?

CU>>Это ваши домыслы. Я всего лишь хочу, чтобы _продаваемый_ товар сертифицировался и имел гарантии.

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

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

FR>А тот кто "продает" ОО может что-то гарантировать? Если сейчас обязать гарантировать то из софта останутся только системы управления атомными реакторами.

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

CU>>Сейчас не нужен (в 99% случаев). Что-то кардинально изменится?

FR>Угу, будет монополист которому будет уже абсолютно наплевать на пользователей и их удобство.

Где монополисты среди производителей авто? Даже Intel монополистом не назовёшь. Откуда такие страхи?

Здравствуйте, cl-user, Вы писали:

FR>>Да конечно мы все нострадамусы задним числом.

CU>Нет — это сложившаяся порочная практика в софтостроении — разработчик ничего не гарантирует и ни за что не несёт ответственности.

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

CU>>>Я не говорю про "иначе", я говорю про "дополнительные условия". Аллё, меня слышно?!!!

FR>>Очень плохо, какие-то помехи на линии
FR>>Кто-то тут только-что как раз хотел все административно запретить

CU>Где именно _административно_?

Может я не так понял, но из твоих постов по моему это вытекает, особенно вот из этого http://gzip.rsdn.ru/Forum/Message.aspx?mid=2823613&amp;only=1

Автор: cl-user
Дата: 04.02.08

Если не так будет интересно какие не административные меры ты можешь предложить?

Здравствуйте, FR, Вы писали:

CU>>Нет — это сложившаяся порочная практика в софтостроении — разработчик ничего не гарантирует и ни за что не несёт ответственности.

FR>С этим вполне согласен.

ну хоть в чём-то нашли общий язык

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

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

CU>>Где именно _административно_?

FR>Может я не так понял, но из твоих постов по моему это вытекает, особенно вот из этого http://gzip.rsdn.ru/Forum/Message.aspx?mid=2823613&amp;only=1

Автор: cl-user
Дата: 04.02.08

FR>Если не так будет интересно какие не административные меры ты можешь предложить?

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

Здравствуйте, cl-user, Вы писали:

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

CU>Т.е. вы с радостью будете покупать дешёвые молочные продукты, на которых будет написано: товар не сертифицирован, соответствие производства ТУ и гигиеническим нормам не потверждено?

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

FR>>А тот кто "продает" ОО может что-то гарантировать? Если сейчас обязать гарантировать то из софта останутся только системы управления атомными реакторами.

CU>Если берётся продавать продукт — обязан.

То есть все-таки админинистративные меры?

CU>Речь не про "прямо сейчас". Но к этому надо стремиться, и чем быстрее — тем лучше. В результате появятся "средства производства", помогающие создавать "качественные продукты" (спрос "призовет их к жизни")

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

Здравствуйте, cl-user, Вы писали:

CU>>> Т.е. вроде как стандарт есть, но он нафиг не нужен... Я понял — для кодера контроль качества его кода и требование гарантий страшнее чем ладан для чёрта
C>>Нет, просто громоздкость процессов не оправдывает обычно результатов. Или положительных результатов в итоге вообще не бывает.
CU>Повторюсь: отменим вообще всю сертификацию и будем полагаться на "хорошего парня" во всех сферах деятельности?
Стоит различать сертефикацию качество, и сертефикацию по ISO 9000. Одно из другого ничуть не следует.

Прочти наконец про него что-нибудь.

Здравствуйте, cl-user, Вы писали:

CU>Это ваши домыслы. Я всего лишь хочу, чтобы _продаваемый_ товар сертифицировался и имел гарантии.

Вообще твоё желание понятно и обосновано. Но! Как ты предлагаешь проверять товар? Из личного опыта: есть ГОСТы, которые определяют сколько брака может в себе содержать партия, для этого делается выборка из партии и производится тест, ну это, допустим, болты какие, гайки пружины всякие. Потом возьмем штучное изделие переключатель токов большой мощности: его берут гоняют на установках, если не прошел на доработку или замену.

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

Целесообразность — меня как юзера, не сильно напрягают вылеты каких-то программ, если не потерялись данные. Вон убунта пару раз зависала намертво, ничё — ребутнул поехал дальше. Klicker пару раз падал, сам перезагрузился и всё ок. Т.е. для десктопа такая надёжность, нафиг не нужна. Я, например, рад послужить бесплатным тестером и отправить пару нормальных багрепортов. Для серваков, насколько я знаю, компании берут деньги за то, что они дают воркэраунд к багу за сутки, а пофиксят, положим, за неделю. И ниче живут.

Т.е. гарантии — это безусловно хорошо, но разным нишам пользователей нужен совершенно разный уровень надежности. И механизмы сертификации и контроля ПО от меня тоже ускользнули. Или ты предлагал использовать 5 библиотек на все случаи жизни, которые утвердит консорциум стандартом? Мягко говоря неэффективно, отрасль черезчур динамичная. Для примера можно на С++ посмотреть. ИМХО стандартизация многие процессы сильно тормозит.

Кстати, про обувь и аналогии: купил жене сапоги, не дешёвые, ГОСТы указаны. Пришлось подошву всю менять через 3-4 месяца периодического ношения. Не, я понимаю, что по закону на обувь гарантия 2 недели, но что-то я не вижу, чтоб производители стремились за большие деньги дать большие гарантии, несмотря на сертификацию ГОСТы и прочее.

Здравствуйте, FR, Вы писали:

CU>>Т.е. вы с радостью будете покупать дешёвые молочные продукты, на которых будет написано: товар не сертифицирован, соответствие производства ТУ и гигиеническим нормам не потверждено?

FR>Для продуктов есть необходимость сертификации да и то не по качеству, а только по соответствию санитарно-эпидемиологическим нормам.

Смотря где и для каких продуктов.

FR>Для большинства софта такой необходимости вообще нет.

Да ну? Одна гарантия отсутствия закладок чего стоит...

FR>Притом продукт может соответствовать всем нормам и быть практически несъедобным. С софтом будет тоже самое.

Об исключениях из правил не будем — с ними пусть юристы разбираются

CU>>Если берётся продавать продукт — обязан.

FR>То есть все-таки админинистративные меры?

Опять 25! В какой отрасли ещё полностью отсутствуют гарантии? И во многих ли странах все гарантии и контроль качества производитель берёт на себя добровольно в пылу конкурентной борьбы, или он просто ничего произвести не сможет пока не докажет безопасность своей продукции?

CU>>Речь не про "прямо сейчас". Но к этому надо стремиться, и чем быстрее — тем лучше. В результате появятся "средства производства", помогающие создавать "качественные продукты" (спрос "призовет их к жизни")

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

"Зуб даёшь?"
Это не такое уж и большое преимущество, к тому же очень дорогое — любая безпасность и контроль качества упрутся в ресурсы — процессорные, память и т.д. либо на стадии производства либо на стадии работы. Пока все полагаются только на "интеллект кодеров" и работают над облегчением их труда. Про упор на качество что-то особенно не слышно — так, неплохая характеристика выдаваемого кодером кода с накоплением опыта, не более того.

Здравствуйте, Cyberax, Вы писали:

CU>>Повторюсь: отменим вообще всю сертификацию и будем полагаться на "хорошего парня" во всех сферах деятельности?
C>Стоит различать сертефикацию качество, и сертефикацию по ISO 9000. Одно из другого ничуть не следует.

Я и не утверждал, что надо именно ISO 9000. И таки качество продукции "мне ближе"

Здравствуйте, dr.Chaos, Вы писали:

DC>Здравствуйте, cl-user, Вы писали:

CU>>Это ваши домыслы. Я всего лишь хочу, чтобы _продаваемый_ товар сертифицировался и имел гарантии.

DC>Вообще твоё желание понятно и обосновано.

Огромное вам спасибо за понимание, сочувствие и поддержку

DC>А теперь пришли к софту, как можно адкватно оценить его качество и надежность? Я, если честно, себе этого не представляю . Возьмем для примера ОС — функций дофига, протестировать как черный ящик почти нереально. Можно, в принципе, анализировать исходники, но, опять же, чего в них искать? Кроме того исходники — это коммерческая тайна.

1. Тайну — в одно место, для этого есть патенты и т.п.
2. Тестирование. Как можно более полное. Кода тестов должно быть не меньше кода самой программы
3. Будущее покажет...

DC>Целесообразность — меня как юзера, не сильно напрягают вылеты каких-то программ, если не потерялись данные. Вон убунта пару раз зависала намертво, ничё — ребутнул поехал дальше. Klicker пару раз падал, сам перезагрузился и всё ок.

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

DC>Т.е. для десктопа такая надёжность, нафиг не нужна.

Кому как.

DC>И механизмы сертификации и контроля ПО от меня тоже ускользнули.

Их и нет пока. Но это не повод не задумываться. На вскидку — я уже сказал — тесты. И процент покрываемого ими функционала. Довольно не плохой показатель.

DC>Или ты предлагал использовать 5 библиотек на все случаи жизни, которые утвердит консорциум стандартом?

Это ваши домыслы

DC>Кстати, про обувь и аналогии: купил жене сапоги, не дешёвые, ГОСТы указаны. Пришлось подошву всю менять через 3-4 месяца периодического ношения. Не, я понимаю, что по закону на обувь гарантия 2 недели, но что-то я не вижу, чтоб производители стремились за большие деньги дать большие гарантии, несмотря на сертификацию ГОСТы и прочее.

Может у неё эксплуатационный срок такой? (согласно те-же ГОСТов )

Здравствуйте, cl-user, Вы писали:

CU>>>Повторюсь: отменим вообще всю сертификацию и будем полагаться на "хорошего парня" во всех сферах деятельности?
C>>Стоит различать сертефикацию качество, и сертефикацию по ISO 9000. Одно из другого ничуть не следует.
CU>Я и не утверждал, что надо именно ISO 9000. И таки качество продукции "мне ближе"
Есть и другие стандарты качества. Пытались их применить и к софту — фигня получается.

Здравствуйте, cl-user, Вы писали:

DC>>И механизмы сертификации и контроля ПО от меня тоже ускользнули.

CU>Их и нет пока. Но это не повод не задумываться. На вскидку — я уже сказал — тесты. И процент покрываемого ими функционала. Довольно не плохой показатель.

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

Хотите ли вы сами проходить через такую сертификацию?

Здравствуйте, Cyberax, Вы писали:

C>Есть и другие стандарты качества. Пытались их применить и к софту — фигня получается.

Значит нужны свои собственные.

Здравствуйте, eao197, Вы писали:

E>Думаю, вам будет интересно почитать: Все, что вы хотели спросить о сертификации бортового программного обеспечения, но боялись узнать.

E>Хотите ли вы сами проходить через такую сертификацию?

"Хотите" здесь неуместно. Либо проходишь, либо "не в теме".
А вы хотели бы летать на самолётах, на которых установлено ПО не прошедшее никакой сертификации?

Здравствуйте, cl-user, Вы писали:

CU>Здравствуйте, eao197, Вы писали:

E>>Думаю, вам будет интересно почитать: Все, что вы хотели спросить о сертификации бортового программного обеспечения, но боялись узнать.

E>>Хотите ли вы сами проходить через такую сертификацию?

CU>"Хотите" здесь неуместно. Либо проходишь, либо "не в теме".
CU>А вы хотели бы летать на самолётах, на которых установлено ПО не прошедшее никакой сертификации?

Особенно если это самолёт мелкой авиации

Здравствуйте, cl-user, Вы писали:

C>>Есть и другие стандарты качества. Пытались их применить и к софту — фигня получается.
CU>Значит нужны свои собственные.
Так есть — стандарты на процессы разрботки. RUP, например.

Другое дело, что они тоже ничего не гарантируют.

Здравствуйте, cl-user, Вы писали:

E>>Хотите ли вы сами проходить через такую сертификацию?
CU>"Хотите" здесь неуместно. Либо проходишь, либо "не в теме".
CU>А вы хотели бы летать на самолётах, на которых установлено ПО не прошедшее никакой сертификации?
Софт для самолетов не сертифицируется. Сертифицируется программно-аппаратная система.

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

Они безумно дорогие, поэтому использовать их для чего-то сильно отличного от кода управления Шаттлом или Боингом — просто нет смысла. Это все равно что делать все окна во всех домах из пуленепробиваемого стекла — на случай если на улице вдруг стрельба начнется.

Здравствуйте, Cyberax, Вы писали:

C>>>Есть и другие стандарты качества. Пытались их применить и к софту — фигня получается.
CU>>Значит нужны свои собственные.
C>Так есть — стандарты на процессы разрботки. RUP, например.

C>Другое дело, что они тоже ничего не гарантируют.

Стандарты на процессы — это хорошо. Но без стандартизации продукции — никак

Здравствуйте, cl-user, Вы писали:

CU>Здравствуйте, eao197, Вы писали:

E>>Думаю, вам будет интересно почитать: Все, что вы хотели спросить о сертификации бортового программного обеспечения, но боялись узнать.

E>>Хотите ли вы сами проходить через такую сертификацию?

CU>"Хотите" здесь неуместно. Либо проходишь, либо "не в теме".
CU>А вы хотели бы летать на самолётах, на которых установлено ПО не прошедшее никакой сертификации?

Скажите, а вы завели здесь разговор об определенном классе ПО или же о разработке ПО вообще?
Если речь идет о ПО, отвечающем за жизнеобеспечение чего-либо, то мне, естественно, хотелось бы, чтобы требования к его качеству были выше, чем требования к качеству VIM-а или Visual Studio. Если такие требования способны обеспечить какие-то механизмы сертификации, то пусть это будет сертификация.

Однако, хочу заметить, что уже сейчас сертификация (не только по ISO 9000) используется в целом ряде предметных областей. Например, в вещах, связанных с шифрованием данных. Насколько я понимаю, на территории официально России безопасность данных может обеспечиваться только компонентами, сертифицированными ФАПСИ. Хотя качество этих компонентов далеко не всегда совпадает с качеством той же самой OpenSSL.

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

Здравствуйте, Cyberax, Вы писали:

E>>>Хотите ли вы сами проходить через такую сертификацию?
CU>>"Хотите" здесь неуместно. Либо проходишь, либо "не в теме".
CU>>А вы хотели бы летать на самолётах, на которых установлено ПО не прошедшее никакой сертификации?
C>Софт для самолетов не сертифицируется. Сертифицируется программно-аппаратная система.

<краткий пересказ статьи скипнут>

C>Они безумно дорогие, поэтому использовать их для чего-то сильно отличного от кода управления Шаттлом или Боингом — просто нет смысла.

А кто-то предлагает использовать именно _такие_? Безумец какой-то...

Здравствуйте, cl-user, Вы писали:

C>>Другое дело, что они тоже ничего не гарантируют.
CU>Стандарты на процессы — это хорошо. Но без стандартизации продукции — никак
Хочу тебя удивить, но продукцию никто в мире почти и не стандартизует, нет в этом смысла. Русские ГОСТы — это скорее исключение (местами приятное).

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

Здравствуйте, cl-user, Вы писали:

C>>Они безумно дорогие, поэтому использовать их для чего-то сильно отличного от кода управления Шаттлом или Боингом — просто нет смысла.
CU>А кто-то предлагает использовать именно _такие_? Безумец какой-то...
А другого ничего нет. Или адское тестирование и доказательство кода, или ситуация как сейчас.

Здравствуйте, cl-user, Вы писали:

DC>>Целесообразность — меня как юзера, не сильно напрягают вылеты каких-то программ, если не потерялись данные. Вон убунта пару раз зависала намертво, ничё — ребутнул поехал дальше. Klicker пару раз падал, сам перезагрузился и всё ок.

CU>полная безответственность за глюки _коммерческих_ программ начинает доставать...

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

DC>>Т.е. для десктопа такая надёжность, нафиг не нужна.

CU>Кому как.

ну тогда приведи пример, за того ПО за повышенную надежность которого, ты согласен заплатить больше денег. И насколько больше.

DC>>И механизмы сертификации и контроля ПО от меня тоже ускользнули.

CU>Их и нет пока. Но это не повод не задумываться. На вскидку — я уже сказал — тесты. И процент покрываемого ими функционала. Довольно не плохой показатель.

Тесты не показывают надежность или безошибочность. Кроме того возникает вопрос что именно тестировать? Да и не всё поддается адекватному тестированию.

Гарантий и ответственности от производителя ПО конечно хочется, но как это адекватно реализовать непонятно. Кстати, возникают проблемы с тем, что производитель находится в другой стране.

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

Здравствуйте, eao197, Вы писали:

E>Скажите, а вы завели здесь разговор об определенном классе ПО или же о разработке ПО вообще?

Скорее о "продаваемой продукции"

E>Однако, хочу заметить, что уже сейчас сертификация (не только по ISO 9000) используется в целом ряде предметных областей. Например, в вещах, связанных с шифрованием данных.

С шифрованием всё ясно (откуда ноги растут) и для каких целей.

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

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

Шутка

Здравствуйте, cl-user, Вы писали:

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

CU>Скажем так — для совершенно некритичного ПО сертификация _процесса производства_ не нужна, но (пусть формальное и автоматизированное) подтверждение соответствия продукта некоему "сертификату" — обязательно.

Тогда такой вопрос -- может ли играть роль такого сертификата диплом ВУЗа о соответствующей специальности у программиста?

Здравствуйте, Cyberax, Вы писали:

C>Как-то я слабо представляю себе стандарт на программы рассчета молекулярной динамики, например. Или на программы интерфейса со сканирующим туннельным микроскопом.

Эти программы пишут под заказ или для "широких массовых продаж"?

Здравствуйте, cl-user, Вы писали:

C>>Как-то я слабо представляю себе стандарт на программы рассчета молекулярной динамики, например. Или на программы интерфейса со сканирующим туннельным микроскопом.
CU>Эти программы пишут под заказ или для "широких массовых продаж"?
Считать ли программу, занимающую 30% рынка — массовой? А если рынок исчисляется десятками тысяч штук?

Здравствуйте, Cyberax, Вы писали:

C>А другого ничего нет. Или адское тестирование и доказательство кода, или ситуация как сейчас.

Да что-же это такое... Мир совершенен, и любое изменение == ухудшение ситуации? Всё, картинка зафиксирована, и ничего другого и быть не может?

Здравствуйте, dr.Chaos, Вы писали:

DC>Я с этим согласен, но как их контролировать из вне, я себе представляю слабо.

И я тоже

DC>Просто альтернатива в виде платной поддержки опен сорс продуктов тут выглядит намного вкуснее, т.к. можно проанализировать исходники, это значительно дешевле чем тестировать сложную систему как чёрный ящик.

Не, последнее — мартышкин труд.

DC> ну тогда приведи пример, за того ПО за повышенную надежность которого, ты согласен заплатить больше денег. И насколько больше.

За любое, которое сложнее `cp`, `rm` и т.д. "Больше" — понятие относительное. Для начала, думаю, достаточно прекратить OEM-поставки софта

CU>>Их и нет пока. Но это не повод не задумываться. На вскидку — я уже сказал — тесты. И процент покрываемого ими функционала. Довольно не плохой показатель.

DC>Тесты не показывают надежность или безошибочность. Кроме того возникает вопрос что именно тестировать? Да и не всё поддается адекватному тестированию.

Тесты показывают соответствие тестам Сам процесс тестирования тоже можно стандартизировать. Писать программы с максимальным выносом функциональности в "независимые" функции/классы для обеспечения более полного покрытия тестами. Да мало ли чего ещё. Был бы "пинок" в нужном направлении — наработки появятся.

DC>Гарантий и ответственности от производителя ПО конечно хочется, но как это адекватно реализовать непонятно.

Надо думать. А не отмахиваться "Не, не хочу! Невозможно! Нафиг не надо!!!"

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

Не более чем с любым другим товаром.

DC>В общем, я тут вижу, только один путь: платить деньги за уровень поддержки продукта, т.е. за то насколько быстро исправят тот баг, который мешает тебе жить.

Скорее всего — это в первую очередь, но...

DC>А сертификации и контроль качества не помогут ИМХО.

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

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

Хм, и ты 100% уверен, что виной тому, что "реально работает только фидбэк от пользователей" и т.д., _ТОЛЬКО_ внедрённый контроль качества и пройденная сертификация, и нет никакого пути улучшить ситуацию, не снизив при этом контроля за качеством?

Здравствуйте, eao197, Вы писали:

CU>>Скажем так — для совершенно некритичного ПО сертификация _процесса производства_ не нужна, но (пусть формальное и автоматизированное) подтверждение соответствия продукта некоему "сертификату" — обязательно.

E>Тогда такой вопрос -- может ли играть роль такого сертификата диплом ВУЗа о соответствующей специальности у программиста?

Как сертификат процесса для одиночки — может (если сам ВУЗ пройдёт соответствующую сертификацию )
Как сертификат на продукцию — нет.

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

Здравствуйте, Cyberax, Вы писали:

CU>>Эти программы пишут под заказ или для "широких массовых продаж"?
C>Считать ли программу, занимающую 30% рынка — массовой? А если рынок исчисляется десятками тысяч штук?

Значит должны быть и конкуренты, и тесты. Но 10'000 — это узкая сфера, в которой "потребители" сами могут скооперироваться и выставлять требования "производителям" (я так думаю — цена позволяет).

Здравствуйте, cl-user, Вы писали:

CU>Здравствуйте, eao197, Вы писали:

CU>>>Скажем так — для совершенно некритичного ПО сертификация _процесса производства_ не нужна, но (пусть формальное и автоматизированное) подтверждение соответствия продукта некоему "сертификату" — обязательно.

E>>Тогда такой вопрос -- может ли играть роль такого сертификата диплом ВУЗа о соответствующей специальности у программиста?

CU>Как сертификат процесса для одиночки — может (если сам ВУЗ пройдёт соответствующую сертификацию )
CU>Как сертификат на продукцию — нет.

CU>Да, к стати, где языки, тестировать код на которых и доказывать его "вероятную безошибочность" наиболее просто? Принесены в жертву идолу "мэйнстрим-кодер"

Посмотри в форуме декларативного программирования про TFP, правда, видимо, не всё можно написать при помощи TFP, но там безошибочность 100% при корректной работе железа.

Здравствуйте, Курилка, Вы писали:

CU>>Да, к стати, где языки, тестировать код на которых и доказывать его "вероятную безошибочность" наиболее просто? Принесены в жертву идолу "мэйнстрим-кодер"

К>Посмотри в форуме декларативного программирования про TFP, правда, видимо, не всё можно написать при помощи TFP, но там безошибочность 100% при корректной работе железа.

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

Здравствуйте, cl-user, Вы писали:

C>>А другого ничего нет. Или адское тестирование и доказательство кода, или ситуация как сейчас.
CU>Да что-же это такое... Мир совершенен, и любое изменение == ухудшение ситуации? Всё, картинка зафиксирована, и ничего другого и быть не может?
Мир совершенен? Это что-то новенькое.

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

Здравствуйте, cl-user, Вы писали:

CU>>>Эти программы пишут под заказ или для "широких массовых продаж"?
C>>Считать ли программу, занимающую 30% рынка — массовой? А если рынок исчисляется десятками тысяч штук?
CU>Значит должны быть и конкуренты, и тесты. Но 10'000 — это узкая сфера, в которой "потребители" сами могут скооперироваться и выставлять требования "производителям" (я так думаю — цена позволяет).
Конкуренты есть, это без проблем. Скооперироваться потребители не могут, как в анекдоте — куда они денутся с подводной-то лодки?

Тестировать на 100% с полным доказательством кода — нельзя, конкуренты обгонят софт по фичам. Потребителям вполне достаточно разумного балланса между качеством и фичами.

Здравствуйте, Курилка, Вы писали:

К>Посмотри в форуме декларативного программирования про TFP, правда, видимо, не всё можно написать при помощи TFP, но там безошибочность 100% при корректной работе железа.

А теперь оцените вероятность перехода TFP в разряд "мэйнстрима" без необходимости подтверждения качества кода?

Здравствуйте, Cyberax, Вы писали:

C>>>А другого ничего нет. Или адское тестирование и доказательство кода, или ситуация как сейчас.
CU>>Да что-же это такое... Мир совершенен, и любое изменение == ухудшение ситуации? Всё, картинка зафиксирована, и ничего другого и быть не может?
C>Мир совершенен? Это что-то новенькое.

C>Технологии создания ПО эволюционируют, тут все нормально. Но кардинально вряд ли что-то в ближайшем будущем изменится.

О, уже "вряд ли", а не "ничего нет". А если ещё усилия приложить?