Эта штуковина позволяет делать почти полноценный code access security для обычных приложений. Если кратко, то оно работает так — есть шина обмена сообщениями D-BUS (это COM с человеческим лицом), на нее вешаются сервисы, выполняющие restricted-операции, они работают в контекстах безопасности, с достаточными правами.
Процессы, которым нужно сделать какие-то запрещенные операции соединяется через PolicyKit с нужным сервисом и просит выполнить авторизацию. PolicyKit проверяет права текущего пользователя, может быть спрашивает пароль, и дает (или не дает) доступ вызывающему процессу к нужной службе.
Кроме того, тут в дело вступает еще один компонент системы — AppArmor. Это ядерный модуль, который позволяет ограничить права одного конкретно взятого процесса. Например, можно сделать так, чтобы FireFox не имел доступа ни к каким файлам кроме своего каталога плугинов. Совместно с PolicyKit он может использоваться для изоляции опасных процессов.
В пользовательском интерфейсе это все выглядит так:
Если я нажимаю на кнопку "Unlock" — то у меня появляется окно, в котором я ввожу свой пароль, после чего приложение "Network Settings" получает права на работу с настройками сети, но ни с чем иным.
Уже делается интеграция с FireFox — чтобы можно было безопасно сохранять файлы через диалог "Save as", но при этом, чтобы FireFox не мог заниматься, например, шпионством за файлами пользователя.
В общем, как оказалось, для CAS совсем не нужно переписывать все на managed-код.
Здравствуйте, FR, Вы писали:
FR>тот же Форд добился того, что используя более низкоквалифицированную рабочую силу смог поднять производительность труда (в том числе в расчете на человека) на порядки.
Мне кажется, вы увлеклись ложными аналогиями. Какие паровые двигатели? Какие конвейеры? Фордовский конвейер имеет отношение к тиражированию продукции, а не к исследованиям, разработке и проектированию — а софтверная индустрия — это одни только разработка и проектирование, не так ли? Тиражирование ПО тривиально.
... << RSDN@Home 1.2.0 alpha rev. 774>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Здравствуйте, cl-user, Вы писали:
CU>Имхо, на данном этапе _большая_ часть пишущегося софта (даже без учёта "хоумпагов" и "хелловордов" и упомянутых "велосипедов") вполне могла бы быть заменена [до]настройкой существующих "монстров". Возможно с некоторыми потерями, но с огромной экономией ресурсов.
При этом появится профессия "настройщик" и их потребуется не меньше чем сейчас программистов
Кстати это уже сейчас работает в некторых нишах, например тот же 1С, но это не значит что такой процесс эффективен или вообще возможен для остальных ниш.
CU>Осла и слона достаточно, чтобы оба "не спали", но большая разноплановость ведёт к распылению ресурсов, что на уровне всего общества/отрасли слишком затратно.
И двух писателей тоже достаточно? давай оставим только Достоевского и Толстого
К>>Так что тут я склонен работу разработчика скорее с изобретательством сравнивать. А промышленное производтство тут — клепание болванок или хттп-сервер, где лежат бинарники или исходники
CU>Только "разработчиков" должно остаться как "сенаторов", а не как "юристов" (как сейчас)
Здравствуйте, cl-user, Вы писали:
CU>Здравствуйте, Курилка, Вы писали:
FR>>>Для пользователей сложней так как будут поощрятся продукты-монстры "делающие все", так как по твоему предложению все "ненужные" программы не выпускаются, вот и впитают несколько монстров их функции.
К>>И выходит несколько странное (мертворождённое?) явление — "эволюция без мутаций"
CU>Да нет — с мутациями. Только "выход годных" догнать бы хоть до совковой микроэлектроники, а то подозреваю он ещё на порядок меньше...
Не знал, что в союзе микроэлектроннику методом генной инженерии развивали
В общем — я так и не услышал, где же в написании программ типовые приёмы, отточив которые можно штамповать хорошие программы. Только не надо про паттерны и иже с ними — практика уже по-моему достаточна показала, что остаётся справедливой поговорка про "заставь дурака богу молиться". В общем — ключевым инструментом разработчика считаю его мозг (иде и язык программирования по мне лишь для грубой обработки типа рашпиля). Ты же по сути получается призываешь стандартизировать человеческое мышление, причём по ходу дела получается чуть ли не во всех областях сразу. Для рутинных операций типа бухучёта, наверное, это отчасти справедливо, хотя и там фантазия законотворцов не даёт расслабиться Да и просто есть привычки/приёмы разных главбухов и т.п. (я в бух-ии почти 0, так что сильно серьёзно этот аргумент прошу не воспринимать). А есть и посложней отрасли...
Неэффективные системы отомрут сами собой, если будут вменяемые конкуренты, а по поводу вменяемых я не вижу смысла беспокоиться.
Ты же, получается, считаешь, что есть какая-то утопия, где всё решается идеальным образом. На это дело есть не один роман-антиутопия
В общем каких-то внятных предложений/идей о качестве и о том, как оно должно всю индустрию перелапатить, я не вижу пока
Так что непонятно, о чём вообще идёт разговор.
Здравствуйте, cl-user, Вы писали:
E>>Хотите ли вы сами проходить через такую сертификацию?
CU>"Хотите" здесь неуместно. Либо проходишь, либо "не в теме". CU>А вы хотели бы летать на самолётах, на которых установлено ПО не прошедшее никакой сертификации?
Я бы спросил иначе — хотел бы ты, как пользователь платить за программу типа ICQ или Winamp или пусть даже Office столько, сколько стоит ПО для Боинга?
Ты тут все время радеешь за пользователей — ну вот я как пользователь скажу тебе — иди-ка ты лесом с такими предложениями. Мне не нужны гарантии, что такая-то программа будет стабильно работать и не падать, если это выльется в большие дополнительные расходы. А сертифицирование это те еще расходы.
Мне не так уж и страшно, что текстовый редактор внезапно умер. Если он умирает слишком часто — я найду другой (при том что сперва я тоже тщательно повыбираю что мне использовать). У другой компании. Которых много. Мелких. Которых ты предлагаешь уничтожить. Ради какой-то абстрактной "гарантии".
Вот у нас мелкая компания — разработчик ПО. Мы даем гарантию на наш софт. Безо всяких законодательных требований. Потому это это нужно для нормальных отношений с заказчиком.
Это же есть суть изначальная причина возникновения гарантии на товары. Причина их не в сертификатах и не в законах. А в том, что пользователь скорее купит вещь, на которую есть гарантия.
При этом наша гарантия — это исправление ошибок в программе в течение некоторого срока. Но и на всю технику "гарантия" именно такова. Это гарантия что телефон не сломается за год из-за брака на производстве. Если он сломается через год и 1 день — это нормально.
Еще есть нормы на товары, способные повредить здоровью — продукты питания, те же телефоны, хим. товары. Но софт не может причинить вред здоровью человека, потому сравнение с колбасой тут просто неуместно. Может повредить здоровью программно-аппаратный комплекс (атомный реактор, медицинский аппарат).. Ну так они и сейчас сертифицируются!
Вкратце: проснись, оглядись вокруг и кончай воевать с ветряными мельницами.
Здравствуйте, cl-user, Вы писали:
CU>И вот ещё приходят "стандарты" на restricted-операции. И на очереди ещё много чего — та-же мультизадачность (erlang всё равно всех потребностей мульти-[процессов/тредов/ядер/процессоров/хостов/кластеров/сетей] "не покрывает") и т.д.
There is no silver bullet.
CU>Я к тому, что место для подобия искусства остаётся только на этапе составления ТЗ (т.е. "конструирования"). А далее должно быть "как по рельсам": с одной стороны — список необходимой функциональности, с другой — стандарты. Хотя "искусство" лавирования между этими "сторонами одной монеты" тоже "имеет место быть", но это уже совсем другая история.
Дак по сути всё софтостроение есть перевод из желаемого в работающее на компе, правда вводят кучу стадий для простоты: польз. требования, разработческие, HLD, программа, под которой VM какой-нибудь, под которой ОС какая-нибудь
А вообще стандартные задачи софтом решаются на ура, но они решаются софтом. Тогда как написание софта есть решение, как правило (если откинуть излишнее велосипедописание), новых задач.
Так что тут я склонен работу разработчика скорее с изобретательством сравнивать. А промышленное производтство тут — клепание болванок или хттп-сервер, где лежат бинарники или исходники
Здравствуйте, cl-user, Вы писали:
FR>>Где конвеер, где паровой двигатель хотя бы?
CU>Конвееры есть уже сейчас.
Можно примеры, притом чтобы конвеер как и в промышленности поднимал, а не уменьшал производительность труда на порядок
А паровые двигатели (aka кодогенерация) пока сложны, опасны и, возможно, не достаточно удобны/гибки, (особенно в руках большинства старых "кузнецов"). Хотя "зачатки" добрались уже практически до всех — в частности в виде шаблонов (как программных, так и IDE-шных).
Это не паровые двигатели, те которые для массового пользователя (волшебники из IDE) слишком убоги и негибки. Те же которые для крутых "кузнецов", предполагают слишком сложное обучение и высокую квалификацию, получается уже не "кузнец" а скорее "маг" (часто и "шаман")
Здравствуйте, cl-user, Вы писали:
CU>Здравствуйте, Курилка, Вы писали:
К>>В общем каких-то внятных предложений/идей о качестве и о том, как оно должно всю индустрию перелапатить, я не вижу пока
CU>Я не говорю _как_, я говорю — _нужна система сертификации ПО_ (и самих софтописателей — тоже).
А потом ещё сертификации сертификаторов сертификаторов сертификаторов...
Неинтересно.
Здравствуйте, cl-user, Вы писали:
CU>В какую же? Но только с качеством, гарантиями и прочим...
Раскрой вс еже тему "качества" и "гарантии"
Сколько единиц качества минимально должна иметь программа?
Какие гарантии должны предоставляться?
Как при этом поможет конвейер (хотя я так и не понял как его внедрить)? Я уже сразу могу подсказать как организовать конвейер, чтобы он выдавал некачественный товар. Думаю ты и сам сможешь найти примеры, когда без конвейера делают качественный товар и дают гарантию от поломок...
З.Ы.
И почему так много людей мечтает внедрить конвейер в написание софта, я не понимаю??? Может они никогда конвейер не видели? Так надо на завод сходить. Суть конвейера — не в разделении работ, а в том, что налажена четкая последовательность действий при изготовлении одинаковых изделий. Как часто при разработке софта возникают совершенно одинаковые программы? Похожие — да. Но одинаковые? А для похожих задач рулят опыт и разделение труда. Разделение труда придумали задолго до конвейера.
Здравствуйте, cl-user, Вы писали:
CU>Здравствуйте, FR, Вы писали:
FR>>По моему гораздо выгоднее для нас ( программистов ) идти в другую сторону
CU>В какую же? Но только с качеством, гарантиями и прочим...
В такую чтобы производительность и качество труда росли с ростом квалификации.
Кстати в другой стороне гарантий тоже никаких.
FR>>Тем более сам вид дейтельности к этому располагает.
CU>Чем?
Тем что
Если вы разрабатываете ПО, вашим основным строительным материалом является интеллект,
а главным инструментом — вы сами.
Здравствуйте, cl-user, Вы писали:
CU>Заканчивается эпоха "искусства и романтики", в полный "промышленный" рост встаёт эпоха ремеслиничества. Осталось дождаться ISO на контроль качества
Здравствуйте, cl-user, Вы писали:
FR>>При этом появится профессия "настройщик" и их потребуется не меньше чем сейчас программистов
CU>Добавить их к админам (совместить с ...) — делов то...
Это разные профессии, притом платят "настройщикам" сейчас побольше чем админам
FR>>Кстати это уже сейчас работает в некторых нишах, например тот же 1С, но это не значит что такой процесс эффективен или вообще возможен для остальных ниш.
CU>О всех речь и не шла. Но о большинстве (не ниш, а случаев написания программ).
Только реально это будет гораздо менее эффективно чем сейчас. Просто появится еще один слой, притом в большинстве своем паразитирующий.
FR>>Скорее писателей.
CU>Писатель, сертифицтрованный ISO 9000, выдающий "произведения" в жёстко ограниченные сроки, "пишущий" их по строгим установленным стандартам, дающий гарантии на результат их использования?... Нет-уж нет-уж, сами такое читайте...
Здравствуйте, Курилка, Вы писали:
CU>>Не должен кто попало не то что "конструировать", а даже и собирать (хотел написать "автомобили", а потом подумал, что хоть "тостеры" напиши — результат будет лучше чем с ПО).
К>Как-то от строчек выше очень шовинизмом веет
Не понял — отменим сертификацию всех видов производства/прочей деятельности?
К>>>От обычного изобретательство софтописание, по мне, отличается тем, что системы выходят заметно сложнее каких-нибудь "газонокосилок" (если в последней нет чипов )
CU>>"Изобретательство" — это "хоумпаги". А "софтописание" — это "конструирование", т.е. занятие для обладающего "инженерными знаниями". Прочее — это "настройка" — "за 3 часа для чайников/идиотов". К>Странная у вас терминология, ну да бог с ним
Да я просто стараюсь двести мысль, что "программирование" в массе своей _должно_ (не спрашивайте "кому?" ) выйти из сферы "кто хочет — тот и пишет" (оговорюсь — если это не хобби) в разряд "индустриального производства" — с контролем качества, гарантиями и прочим. А "для всех" но "по работе" пусть будет "безопасное скриптование" для какой-нибудь VM в safe mode
FR>>Критерий простой сколько денег будет потреблять IT отрасль при той же отдаче, по моему с новым слоем гораздо больше чем сейчас.
CU>При "индустриализации" IT отрасль сможет выдавать "на гора" намного больше, при этом без "подавляющего велосипедостроительства". Возможно сначала это будет и "дороже", но в перспективе — нет. Хотя как средство "дополнительной занятости населения"...
Один вопрос за счет чего оно будет выдавать больше?
В перспективе это может привести отрасль к тупику, так как практически все новое и перспективное вначале "велосипед".
CU>>>Только не говорите про скорость работы на втором пне — купите соответствующий хард — это может оказаться эффективнее.
FR>>Телега на которой разогнался хард начинает поскрипывать, так что в ближаешем будущем это может стать проблемой
CU>Я имел в виду не HDD, а "железо" вообще
Я тоже
CU>>>По 3 кодера на задачку, которую можно допинать "автоматизацией офиса"? Это эффективно? Да плюс отладка...
FR>>Ну будет три "настройщика", какая разница?
CU>три не будет, а если и будет, то "быстрее"
Угу настройщиков будет 5
FR>>Так и предприятие по уши сертифицированное нередко выпускает совершенно некачественные товары. А с софтом будет еще хуже, проверить качество сложнее.
CU>Его _надо_ проверять! Уже и сейчас. Но все до сих пор шарахаются от этого. В харчевнях тоже никакого "сан/эпида" не было — ничего, привыкли
Надо, с этим не спорю, вот только не надо под предлогом проверки загонять всех в бараки и заставлять работать в большой манафактуре.
Без проблем может проверять и мелких ремеслеников и крупных типа microsoft
Здравствуйте, FR, Вы писали:
FR>>>По моему гораздо выгоднее для нас ( программистов ) идти в другую сторону
CU>>В какую же? Но только с качеством, гарантиями и прочим...
FR>В такую чтобы производительность и качество труда росли с ростом квалификации.
Ах да, я как-то совсем упустил из виду "выгоднее для нас ( программистов )"... Извините, но похоже что пользователям всё больше и больше "с вами не по пути"
FR>Кстати в другой стороне гарантий тоже никаких.
Пока — да, никаких (или мне о них не известно). Но за это и боремся...
FR>>>Тем более сам вид дейтельности к этому располагает.
CU>>Чем?
FR>Тем что FR>
FR>Если вы разрабатываете ПО, вашим основным строительным материалом является интеллект,
FR>а главным инструментом — вы сами.
<joke-mode>
И эти люди, так кичащиеся своим интеллектом, будут меня обвинять в шовинизме?
<joke-mode/>
Если вы такие умные — пишите "программы группы А/I", если не такие — пишите "байткод" для "группы А/II". А всем остальным оставьте "безопасный скриптинг в группе Б"
Здравствуйте, Cyberax, Вы писали:
CU>>таки это нади писать C>?
Я имел в виду — переписывать все программы (там где это надо, пусть даже это будет делаться одним #define)
C>>>Зачем? Смысл в том, чтобы посадить в клетку программу, которая выполняет опасные действия (такие как просмотр web-страничек). Программы из "доверяемого периметра" можно в клетку не сажать. CU>>Либо доверяемых программ будет слишком мало (и будет очень сложно регулировать уровни безопасности большинства программ) либо основная опасность так и останется в "доверенных" но дырявых прогах. C>Нет. Опасны те программы, которые исполняют недоверяемые данные. Такие программы обычно можно достаточно неплохо изолировать.
CU>>>>В IT области? Не слышал... И я уже писал — это должно быть "вершиной айсберга", а не его основой. C>>>ISO 9000 везде действует. CU>>Но везде ли применяется? C>Нет, ибо нафиг не нужен. Возьми и прочти его, какие проблемы-то? По нему тонны литературы написаны.
Т.е. вроде как стандарт есть, но он нафиг не нужен... Я понял — для кодера контроль качества его кода и требование гарантий страшнее чем ладан для чёрта
Здравствуйте, cl-user, Вы писали:
CU>>>таки это нади писать C>>? CU>Я имел в виду — переписывать все программы (там где это надо, пусть даже это будет делаться одним #define)
Можно сделать неинтрузивные обертки. Другое дело, что в Линуксе проще сразу сделать красиво и дописать нужные части нормально.
CU>>>Но везде ли применяется? C>>Нет, ибо нафиг не нужен. Возьми и прочти его, какие проблемы-то? По нему тонны литературы написаны. CU> Т.е. вроде как стандарт есть, но он нафиг не нужен... Я понял — для кодера контроль качества его кода и требование гарантий страшнее чем ладан для чёрта
Нет, просто громоздкость процессов не оправдывает обычно результатов. Или положительных результатов в итоге вообще не бывает.
Здравствуйте, cl-user, Вы писали:
DC>>И механизмы сертификации и контроля ПО от меня тоже ускользнули.
CU>Их и нет пока. Но это не повод не задумываться. На вскидку — я уже сказал — тесты. И процент покрываемого ими функционала. Довольно не плохой показатель.
Здравствуйте, Курилка, Вы писали:
CU>>Да, к стати, где языки, тестировать код на которых и доказывать его "вероятную безошибочность" наиболее просто? Принесены в жертву идолу "мэйнстрим-кодер"
К>Посмотри в форуме декларативного программирования про TFP, правда, видимо, не всё можно написать при помощи TFP, но там безошибочность 100% при корректной работе железа.
Я так понимаю, что там безошибочность самой программы. То, что программа будет делать не то, что хотел заказчик, там вряд ли можно гарантировать. Между тем, ошибки в определении требований к программе могут оказаться не менее страшными, чем ошибки в самой программе (вспоминается катастрофа Ариан-а и сбои в аппарате лучевой терапии, из-за которых несколько человек скончались из-за высоких доз радиации).
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, cl-user, Вы писали:
C>>А другого ничего нет. Или адское тестирование и доказательство кода, или ситуация как сейчас. CU>Да что-же это такое... Мир совершенен, и любое изменение == ухудшение ситуации? Всё, картинка зафиксирована, и ничего другого и быть не может?
Мир совершенен? Это что-то новенькое.
Технологии создания ПО эволюционируют, тут все нормально. Но кардинально вряд ли что-то в ближайшем будущем изменится.
Здравствуйте, cl-user, Вы писали:
CU>И это есть перекос...
Нет. Человек, насраивающий, например, SAP (или тот же 1С) для конечного пользователя должен обладать досаточно широким набором знаний.
1) Он должен знать настраиваемый продукт, чтобы понимать, что он может, а что нет. Что в нем лучше не делать, а что делать можно но осторожно. Тут в помощь идет перечеь багов в продукте в разреза по версиям, знание узких мест в производительности и т.д. Достаточно сказать, что официальная документация по Oracle eBS или SAP занимает несколько dvd в формате pdf. Усвоить все это не реально, поэтому и появляется специализация среди 'настройщиков'.
2) Знать предметную область и особенности бизнеса конкретного клиента, под которого он настраивает софт, чтобы понимать, что он настраивает (например, на как и на какие счета разносить возвраты экспедиторов, или как амортизировать то или иной ОС. Простейший пример — клиент кричит о проблеме — "купил основное средство на склад 1, переместил на склад 2; хочу ввести его в эксплуатацию, с система не может найти его на складе 1, а на 2 даже не пытается". Фигня вопрос — можно это настроить, но это не правильно, ибо согласно бух учету купленое ОС должно сразу вводиться в эксплуатацию и операция ввода в эксплуатацию должна следовать сразу за преобритением ОС. Можно сказать, что клиент сам должен знать такие тонкости, но практика показывает обратное — рынок готов платить (и платит) за специалистов, которые могут проконсультировать и по этим вопросам.
3) Понимать общую архитектуру системы, чтобы если не дописать какую-то фишку(мелкую), которой нехватает клиенту, то хотя бы правильно сформировать ТЗ и предварительно прикинуть, а возможна ли реализация хотелки в рамках существующей архитектуры и в какие трудозатраы она примерно выльется.
В общем, если мы говорим, про область ERP — то, так называемые настройщики стоят гораздо больше разработчиков и называются консультантами. Это по опыту.
Здравствуйте, fmiracle, Вы писали:
F>Архитектура — прямой вред здоровью в случае проблем. Имеет смысл позаботиться о безопасности. Надо ли заботиться о безопасности текстового редактора?
Запросто, если по кнопке "Bold" будет делать курсив — может стать "последней каплей" в момент "осеннего обострения" — будете оплачивать содержание половины Кащенко.
F>И обратно в "реальный мир": F>Какие сертификаты должна иметь дизайн студия? Рекламное агентство? Фотостудия?
Художники — "реальный мир"? Особенно Пикассо и иже с ними! (ничего не имею против их искусства).
F>А ты знаешь что есть сертификаты (и советские еще ГОСТ и заграничные ISO) на софт и документацию к нему? А знаешь что большинство заказчиков кладут на соответствие им с глубоким пробором, поскольку их наличие/отсутствие их меньше волнует чем реальная функциональность и надежность полученного софта?
Некоторых производителей колбасы ГОСТы тоже волнуют меньше, нежели объёмы реализации их продукции. Будем на них ориентироваться и отменим любые законы?
Здравствуйте, fmiracle, Вы писали:
F>Раскрой вс еже тему "качества" и "гарантии"
F>Сколько единиц качества минимально должна иметь программа?
А колбаса? Нефиг паясничать.
F>Какие гарантии должны предоставляться?
Здесь уже сказали: как минимум соответствие тестированию, покрывающему X% всего функционала, и гарантии исправления ошибок в ограниченный срок.
F>Как при этом поможет конвейер (хотя я так и не понял как его внедрить)? Я уже сразу могу подсказать как организовать конвейер, чтобы он выдавал некачественный товар. Думаю ты и сам сможешь найти примеры, когда без конвейера делают качественный товар и дают гарантию от поломок...
Это ваши домыслы.
F>И почему так много людей мечтает внедрить конвейер в написание софта, я не понимаю???
И это ваши домыслы. Не стойте проблемы для того чтобы потом доблестно их решать...
F>Как часто при разработке софта возникают совершенно одинаковые программы? Похожие — да. Но одинаковые?
Двух совершенно одинаковых болтов тоже нет. И что? А-а-а, соответствующих одним и тем-же условиям? Тогда 90% софта!
Здравствуйте, DemAS, Вы писали:
CU>>И это есть перекос...
DAS> В общем, если мы говорим, про область ERP — то, так называемые настройщики стоят гораздо больше разработчиков и называются консультантами. Это по опыту.
Если мы действительно говрим "про область ERP" — то на постсоветском пространстве их единицы, в отличие от "настройщиков 1С".
Здравствуйте, cl-user, Вы писали:
CU>Здравствуйте, Cyberax, Вы писали:
C>>В общем, как оказалось, для CAS совсем не нужно переписывать все на managed-код.
CU>Угу, надо только _все_ restricted-операции переписать через сообщения D-BUS. И не забывать собирать _все_ программы с контролем стека и проч. и проч.
CU>Заканчивается эпоха "искусства и романтики", в полный "промышленный" рост встаёт эпоха ремеслиничества. Осталось дождаться ISO на контроль качества
А чем 9000 не подходит? В купе с CMM?
Имхо про искусство/ремеслинечество это зря, просто по-моему люди начинают понимать, что "лажовое" ПО им боком выходит (мы не настолько богаты чтоб покупать плохие вещи (ц))
Здравствуйте, Курилка, Вы писали:
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 области? Не слышал... И я уже писал — это должно быть "вершиной айсберга", а не его основой.
Здравствуйте, 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
Здравствуйте, 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>Осла и слона достаточно, чтобы оба "не спали", но большая разноплановость ведёт к распылению ресурсов, что на уровне всего общества/отрасли слишком затратно.
Ресурсов стало много, поэтому общество в итоге и расходует их неэкономно
Изменить что-то тут сможет лишь какой-то глобальный катаклизм
К>>Так что тут я склонен работу разработчика скорее с изобретательством сравнивать. А промышленное производтство тут — клепание болванок или хттп-сервер, где лежат бинарники или исходники
CU>Только "разработчиков" должно остаться как "сенаторов", а не как "юристов" (как сейчас)
С чего это? Не вижу логичесной связи
От обычного изобретательство софтописание, по мне, отличается тем, что системы выходят заметно сложнее каких-нибудь "газонокосилок" (если в последней нет чипов )
Здравствуйте, FR, Вы писали:
CU>>Это не станет помехой прогулке _"художника"_ (или "мастера" по Булгакову). Но это превратит большинство "кузниц" в чугуно/сталелитейных "монстров". А "кузнечество" останется либо как хобби, либо как "тяжёлый" вариант "ювелирки".
FR>Где конвеер, где паровой двигатель хотя бы?
Конвееры есть уже сейчас. А паровые двигатели (aka кодогенерация) пока сложны, опасны и, возможно, не достаточно удобны/гибки, (особенно в руках большинства старых "кузнецов"). Хотя "зачатки" добрались уже практически до всех — в частности в виде шаблонов (как программных, так и IDE-шных).
Здравствуйте, Курилка, Вы писали:
К>С чего это? Не вижу логичесной связи К>От обычного изобретательство софтописание, по мне, отличается тем, что системы выходят заметно сложнее каких-нибудь "газонокосилок" (если в последней нет чипов )
Ну в техническом изобретательстве уже есть работающий аналог "серебрянной пули" ТРИЗ
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, Курилка, Вы писали:
К>>С чего это? Не вижу логичесной связи К>>От обычного изобретательство софтописание, по мне, отличается тем, что системы выходят заметно сложнее каких-нибудь "газонокосилок" (если в последней нет чипов )
FR>Ну в техническом изобретательстве уже есть работающий аналог "серебрянной пули" ТРИЗ
Только АРИЗ всё усложнялся и усложнялся и для него надо уже, наверное, вводить ТРИЗ второй степени
Кстати, один из принципов ТРИЗ — устранение "промежуточных" звеньев в системе. Интересно — когда программеры будут напрямую для ПЛИС писать?
Здравствуйте, FR, Вы писали:
CU>>Имхо, на данном этапе _большая_ часть пишущегося софта (даже без учёта "хоумпагов" и "хелловордов" и упомянутых "велосипедов") вполне могла бы быть заменена [до]настройкой существующих "монстров". Возможно с некоторыми потерями, но с огромной экономией ресурсов.
FR>При этом появится профессия "настройщик" и их потребуется не меньше чем сейчас программистов
Добавить их к админам (совместить с ...) — делов то...
FR>Кстати это уже сейчас работает в некторых нишах, например тот же 1С, но это не значит что такой процесс эффективен или вообще возможен для остальных ниш.
О всех речь и не шла. Но о большинстве (не ниш, а случаев написания программ).
CU>>Осла и слона достаточно, чтобы оба "не спали", но большая разноплановость ведёт к распылению ресурсов, что на уровне всего общества/отрасли слишком затратно.
FR>И двух писателей тоже достаточно? давай оставим только Достоевского и Толстого
Как "кузнеца и жнеца"? Это будет ещё хуже натурального хозяйства.
К>>>Так что тут я склонен работу разработчика скорее с изобретательством сравнивать. А промышленное производтство тут — клепание болванок или хттп-сервер, где лежат бинарники или исходники
CU>>Только "разработчиков" должно остаться как "сенаторов", а не как "юристов" (как сейчас)
FR>Скорее писателей.
Писатель, сертифицтрованный 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>Ты про литературных негров не слышал
Слышал, но не читал (если не считать Дюма-старшего). И это не распространяется на качество и гарантии
Здравствуйте, 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, Вы писали:
CU>"Конвеер" даёт возможность вообще создать что-то "большое" — невозможно написать что-то типа ОС или мощного сервера БД или "офиса" без труда многих, где каждый делает отдельные кусочки — параллельности любой промышленный конвеер позавидует.
Нет конвеер дает возможность используя малоквалифицированную рабочую силу давать более массовый и качественный продукт.
А что-то большое позволяет создавать мануфактура ( http://wapedia.mobi/ru/Мануфактура ) в которой уже вполне развито разделение труда.
Кстати самые "большие", например космическая отрасль, производство самолетов и судов обходятся без конвеера
FR>>Это не паровые двигатели, те которые для массового пользователя (волшебники из IDE) слишком убоги и негибки. Те же которые для крутых "кузнецов", предполагают слишком сложное обучение и высокую квалификацию, получается уже не "кузнец" а скорее "маг" (часто и "шаман")
CU>Я ж и говорю — ещё не "развились" до "промышленного использования", но уже есть. Надо работать дальше...
По моему гораздо выгоднее для нас ( программистов ) идти в другую сторону
Тем более сам вид дейтельности к этому располагает.
Здравствуйте, FR, Вы писали:
CU>>Да я просто стараюсь двести мысль, что "программирование" в массе своей _должно_ (не спрашивайте "кому?" ) выйти из сферы "кто хочет — тот и пишет" (оговорюсь — если это не хобби) в разряд "индустриального производства" — с контролем качества, гарантиями и прочим. А "для всех" но "по работе" пусть будет "безопасное скриптование" для какой-нибудь VM в safe mode
FR>В производстве же софта только научились кое как использовать низкоквалифицированную рабочую силу при этом производительность в расчете на человека наооборот падает, то есть уровень мануфактур.
Здравствуйте, FR, Вы писали:
FR>Один вопрос за счет чего оно будет выдавать больше?
Унификация? Стандарты? Уменьшение "велосипедостроительства"?
CU>>Его _надо_ проверять! Уже и сейчас. Но все до сих пор шарахаются от этого. В харчевнях тоже никакого "сан/эпида" не было — ничего, привыкли
FR>Надо, с этим не спорю, вот только не надо под предлогом проверки загонять всех в бараки и заставлять работать в большой манафактуре. FR>Без проблем может проверять и мелких ремеслеников и крупных типа microsoft
А я предлагал "загонять"? Сорри, если мои слова могли сойти за такое... Нет, я имел в виду, что _большинство_ "мелких ремесленников" (и не только) "отвалится" при необходимости внедрять системы контроля качества, проходить сертификацию, давать гарантии и прочее. Не более того.
Здравствуйте, FR, Вы писали:
FR>В производстве же софта только научились кое как использовать низкоквалифицированную рабочую силу при этом производительность в расчете на человека наооборот падает, то есть уровень мануфактур.
Так с мануфактур и начиналась промышленная революция. Сначала разделение труда, что позволило резко снизить требования к квалифиции. По мере все большей специализации выделялись простые операции, которые можно было механизировать, а затем и автоматизировать.
Здравствуйте, cl-user, Вы писали:
FR>>Один вопрос за счет чего оно будет выдавать больше?
CU>Унификация? Стандарты? Уменьшение "велосипедостроительства"?
Это, проценты а не порядки.
CU>А я предлагал "загонять"? Сорри, если мои слова могли сойти за такое... Нет, я имел в виду, что _большинство_ "мелких ремесленников" (и не только) "отвалится" при необходимости внедрять системы контроля качества, проходить сертификацию, давать гарантии и прочее. Не более того.
В результате лишимся мелочи и не улучшим качества.
Здравствуйте, FR, Вы писали:
CU>>Унификация? Стандарты? Уменьшение "велосипедостроительства"?
FR>Это, проценты а не порядки.
+качество, которое так просто не "опроцентуешь"
CU>>А я предлагал "загонять"? Сорри, если мои слова могли сойти за такое... Нет, я имел в виду, что _большинство_ "мелких ремесленников" (и не только) "отвалится" при необходимости внедрять системы контроля качества, проходить сертификацию, давать гарантии и прочее. Не более того.
FR>В результате лишимся мелочи и не улучшим качества.
Не улучшим? Т.е. средневековые кузнецы могли бы дать фору "по качеству стали" любой "литейке"? Или будем на собственной шкуре испытывать качество продукции каждого отдельного портного? Или может перестанем таки "страдать" натуральным хозяйством (которое незаменимо как хобби или в качестве производителя "эксклюзива", но не более).
Здравствуйте, Трурль, Вы писали:
Т>Так с мануфактур и начиналась промышленная революция. Сначала разделение труда, что позволило резко снизить требования к квалифиции. По мере все большей специализации выделялись простые операции, которые можно было механизировать, а затем и автоматизировать.
Угу, только разделение труда приводило не только к снижению, но и повышению требований к квалификации. Конвеер же приводит только к снижению.
Здравствуйте, 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, Вы писали:
FR>>Так пока не заставляют, но если ваши мечты сбудутся то уже никуда ни дется будет.
CU>Как контроль качества и требование гарантий помогут MS одолеть конкурентов?
Тык вроде разговор начинался с того что разгоним всю мелочь а монстров заставим ходить строем, тьфу соблюдать качество
Здравствуйте, FR, Вы писали:
CU>>Да их нигде не будет, пока их не начнут требовать.
FR>Не требовать бесполезно, вот если будут готовы за это платить, тогда да.
Во-первых, _уже_ платят за гарантии в виде поддержки или за готовые sw+hw комплексы "под ключ". Понятно, что это только увеличит цену. Но и требовать таки надо (возможно не сразу и на всё, а постепенно). Но как в итого срок годности должен быть на любом продукте, так и на софт должны распространятся гарантии. Это не гарантии того, что софт совсем глючить не будет (как нет и гарантии не отравиться годным продуктом) — это гарантии того, что производитель кровно заинтересован свести риски к минимуму.
Здравствуйте, 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-й", а когда-то водитель==автослесарь.
Так будет еще хуже, без "настройщика" ничего ни сможешь
Угу мелочь живет в этой отрасли очень неплохо
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, Вы писали:
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 нужен будет настройщик
Какие-то велосипеды всё однако.
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 — спорная технология и пока толком не понятная, но теоретически вполне юзабельная.
Нет, даже близко по удобству не стоит. В Линуксе все просто — для исполняемого файла (ЛЮБОГО, не обязательнл сервиса) просто прописывается простой профиль типа:
При запуске файла AppArmor сам подхватит нужный профиль, который ставится вместе с приложением.
В теории, на Windows такое возможно, но на практике вряд ли будет, кроме разве что нескольких избраных программ.
C>>Если я нажимаю на кнопку "Unlock" — то у меня появляется окно, в котором я ввожу свой пароль, после чего приложение "Network Settings" получает права на работу с настройками сети, но ни с чем иным. MN>Windows Server 2008: UAC
Выше написал уже
C>>В общем, как оказалось, для CAS совсем не нужно переписывать все на managed-код. MN>А при чём здесь managed-код?
Так тут флеймы такие в свое время были.
Здравствуйте, 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 в правовую область. Всё остальное — это _вероятные_ следствия.
К>В общем — ключевым инструментом разработчика считаю его мозг (иде и язык программирования по мне лишь для грубой обработки типа рашпиля). Ты же по сути получается призываешь стандартизировать человеческое мышление, причём по ходу дела получается чуть ли не во всех областях сразу.
Не мышление, а результат его деятельности!!! Это наконец понятно?!
К>Неэффективные системы отомрут сами собой, если будут вменяемые конкуренты, а по поводу вменяемых я не вижу смысла беспокоиться.
Угу, оговорить в законодательстве "вменяемость" производителей и отменить нафиг все сертификации и лицензирование!
К>Ты же, получается, считаешь, что есть какая-то утопия, где всё решается идеальным образом. На это дело есть не один роман-антиутопия
Я считаю, что пора программистам начать "отвечать" за свои поделия и давать гарантии на их работу.
К>В общем каких-то внятных предложений/идей о качестве и о том, как оно должно всю индустрию перелапатить, я не вижу пока
Я не говорю _как_, я говорю — _нужна система сертификации ПО_ (и самих софтописателей — тоже).
К>Так что непонятно, о чём вообще идёт разговор.
О необходимости законодательно требовать от "производителей ПО" сертификации продукции и выдачи гарантий на его работу. Всё.
Здравствуйте, 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 не начал писать.
Здравствуйте, 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>Где именно _административно_?
Здравствуйте, FR, Вы писали:
CU>>Нет — это сложившаяся порочная практика в софтостроении — разработчик ничего не гарантирует и ни за что не несёт ответственности.
FR>С этим вполне согласен.
ну хоть в чём-то нашли общий язык
FR>Но причины, по моему, большей частью не из разгильдяйства (хотя это тоже есть), а от самой природы дейтельности, приходится работать со слишком гибким материалом и со слишком сложными и хрупкими структурами. И по моему никакие сертификации это существенно не исправят.
Но и нет даже ни малейших подвижек в этом направлении! Потому что это "никому не нужно". Вот и надо сделать это не то что "нужным", а просто таки необходимым
CU>>Где именно _административно_?
FR>Может я не так понял, но из твоих постов по моему это вытекает, особенно вот из этого http://gzip.rsdn.ru/Forum/Message.aspx?mid=2823613&only=1
Здравствуйте, 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, Вы писали:
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.
Так вот, возвращаясь к вопросу "ПО вообще". Представте, что вы делаете какой-то некритичный, в общем-то, софт. Ну, специализированный почтовый сервер, к примеру. Уверены ли вы, что сертификация вашей деятельности способна вам лично, как производителю, помочь повысить качество своего продукта? И согласны ли вы нести издержки на сертификацию?
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, 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>Скажем так — для совершенно некритичного ПО сертификация _процесса производства_ не нужна, но (пусть формальное и автоматизированное) подтверждение соответствия продукта некоему "сертификату" — обязательно.
Тогда такой вопрос -- может ли играть роль такого сертификата диплом ВУЗа о соответствующей специальности у программиста?
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Cyberax, Вы писали:
C>Как-то я слабо представляю себе стандарт на программы рассчета молекулярной динамики, например. Или на программы интерфейса со сканирующим туннельным микроскопом.
Эти программы пишут под заказ или для "широких массовых продаж"?
Здравствуйте, cl-user, Вы писали:
C>>Как-то я слабо представляю себе стандарт на программы рассчета молекулярной динамики, например. Или на программы интерфейса со сканирующим туннельным микроскопом. CU>Эти программы пишут под заказ или для "широких массовых продаж"?
Считать ли программу, занимающую 30% рынка — массовой? А если рынок исчисляется десятками тысяч штук?
Здравствуйте, 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% при корректной работе железа.
Здравствуйте, cl-user, Вы писали:
CU>>>Эти программы пишут под заказ или для "широких массовых продаж"? C>>Считать ли программу, занимающую 30% рынка — массовой? А если рынок исчисляется десятками тысяч штук? CU>Значит должны быть и конкуренты, и тесты. Но 10'000 — это узкая сфера, в которой "потребители" сами могут скооперироваться и выставлять требования "производителям" (я так думаю — цена позволяет).
Конкуренты есть, это без проблем. Скооперироваться потребители не могут, как в анекдоте — куда они денутся с подводной-то лодки?
Тестировать на 100% с полным доказательством кода — нельзя, конкуренты обгонят софт по фичам. Потребителям вполне достаточно разумного балланса между качеством и фичами.
Здравствуйте, Курилка, Вы писали:
К>Посмотри в форуме декларативного программирования про TFP, правда, видимо, не всё можно написать при помощи TFP, но там безошибочность 100% при корректной работе железа.
А теперь оцените вероятность перехода TFP в разряд "мэйнстрима" без необходимости подтверждения качества кода?
Здравствуйте, Cyberax, Вы писали:
C>>>А другого ничего нет. Или адское тестирование и доказательство кода, или ситуация как сейчас. CU>>Да что-же это такое... Мир совершенен, и любое изменение == ухудшение ситуации? Всё, картинка зафиксирована, и ничего другого и быть не может? C>Мир совершенен? Это что-то новенькое.
C>Технологии создания ПО эволюционируют, тут все нормально. Но кардинально вряд ли что-то в ближайшем будущем изменится.
О, уже "вряд ли", а не "ничего нет". А если ещё усилия приложить?
Здравствуйте, Cyberax, Вы писали:
C>Конкуренты есть, это без проблем. Скооперироваться потребители не могут, как в анекдоте — куда они денутся с подводной-то лодки?
Почему не могут? Обговорить необходимые требования — и вперёд: кто первый, "того и тапки"
Здравствуйте, cl-user, Вы писали:
C>>Конкуренты есть, это без проблем. Скооперироваться потребители не могут, как в анекдоте — куда они денутся с подводной-то лодки? CU>Почему не могут? Обговорить необходимые требования — и вперёд: кто первый, "того и тапки"
Как ты себе представляешь сотрудничество кучи разных компаний со всего мира?
Ну ладно, сговорились. Что дальше? Не покупать микроскопы назло врагам?
Здравствуйте, cl-user, Вы писали:
CU>Здравствуйте, Курилка, Вы писали:
К>>Посмотри в форуме декларативного программирования про TFP, правда, видимо, не всё можно написать при помощи TFP, но там безошибочность 100% при корректной работе железа.
CU>А теперь оцените вероятность перехода TFP в разряд "мэйнстрима" без необходимости подтверждения качества кода?
А чего тут оценивать? У кого будут доказанно корректные программы, и это доказательство не выйдет за рамки бюджета, тот выиграет в конкурентной борьбе. Клиенту нужен в первую очередь продукт, "гербовый знак" на бумажке которая есть у софтописателя задачу клиента не решит. А про "липовые" сертификаты уже упоминали.
Здравствуйте, Cyberax, Вы писали:
C>Как ты себе представляешь сотрудничество кучи разных компаний со всего мира?
Не надо "кучи", надо "критической массы", которая (при числе конкурентов > 2) может быть меньше 50%.
И вы таки не слышали скандалов по поводу "межкорпорационных сговоров", иногда между откровенными конкурентами?
Здравствуйте, Курилка, Вы писали:
CU>>А теперь оцените вероятность перехода TFP в разряд "мэйнстрима" без необходимости подтверждения качества кода?
К>А чего тут оценивать? У кого будут доказанно корректные программы, и это доказательство не выйдет за рамки бюджета, тот выиграет в конкурентной борьбе.
Да ну? Пока софтописатели ничем не ограничены, они продают рекламу — гербалайф и биодобавки.
К>Клиенту нужен в первую очередь продукт, "гербовый знак" на бумажке которая есть у софтописателя задачу клиента не решит.
"Знак" скажет, что продукт соответствует хоть каким-то нормам и хоть что-то гарантирует. А при прочих равных условиях может оказаться решающим плюсом для принятия решения в пользу...
К>А про "липовые" сертификаты уже упоминали.
"Гав-гав-гав!!!" (это вместо 3-х этажного мата) ЗАКОНЫ ТОЖЕ ДАЮТ СБОИ, И НЕ РЕДКО — ОТМЕНИМ ВСЕ ЗАКОНЫ И БУДЕМ ЖИТЬ "ПО ПОНЯТИЯМ"?!!!
Здравствуйте, cl-user, Вы писали:
К>>А чего тут оценивать? У кого будут доказанно корректные программы, и это доказательство не выйдет за рамки бюджета, тот выиграет в конкурентной борьбе.
CU>Да ну? Пока софтописатели ничем не ограничены, они продают рекламу — гербалайф и биодобавки.
В области заказного ПО это не так.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, cl-user, Вы писали:
CU>Здравствуйте, Курилка, Вы писали:
К>>Клиенту нужен в первую очередь продукт, "гербовый знак" на бумажке которая есть у софтописателя задачу клиента не решит.
CU>"Знак" скажет, что продукт соответствует хоть каким-то нормам и хоть что-то гарантирует. А при прочих равных условиях может оказаться решающим плюсом для принятия решения в пользу...
Вот когда ты нормы приведёшь и что-то конкретное, тогда можно обсуждать.
К>>А про "липовые" сертификаты уже упоминали.
CU>"Гав-гав-гав!!!" (это вместо 3-х этажного мата) ЗАКОНЫ ТОЖЕ ДАЮТ СБОИ, И НЕ РЕДКО — ОТМЕНИМ ВСЕ ЗАКОНЫ И БУДЕМ ЖИТЬ "ПО ПОНЯТИЯМ"?!!!
Для тебя весь мир бинарен и существует только белое и чёрное?
Жизнь по-моему намного интереснее на самом деле
Здравствуйте, Курилка, Вы писали:
К>>>Клиенту нужен в первую очередь продукт, "гербовый знак" на бумажке которая есть у софтописателя задачу клиента не решит.
CU>>"Знак" скажет, что продукт соответствует хоть каким-то нормам и хоть что-то гарантирует. А при прочих равных условиях может оказаться решающим плюсом для принятия решения в пользу...
К>Вот когда ты нормы приведёшь и что-то конкретное, тогда можно обсуждать.
С нормами проще. Самые простые — отсутствие переполнения стека, деления на ноль и т.п., отсутствие закладок... Что, сами трудно придумать? Есть программы — анализаторы сишного (и не только) кода — вот пусть хоть этим требованиям удовлетворяют Потом объединить большинство общеупотребительных требований в один (пусть) ISO — можно начинать сертифицировать
Блин, я должен кодеров учить писать программы?
К>>>А про "липовые" сертификаты уже упоминали.
CU>>"Гав-гав-гав!!!" (это вместо 3-х этажного мата) ЗАКОНЫ ТОЖЕ ДАЮТ СБОИ, И НЕ РЕДКО — ОТМЕНИМ ВСЕ ЗАКОНЫ И БУДЕМ ЖИТЬ "ПО ПОНЯТИЯМ"?!!!
К>Для тебя весь мир бинарен и существует только белое и чёрное?
Нет. Просто не надо рассматривать "крайние значения" (если не стоит задача рассматривать именно крайние значения) — при анализе они очень часто "отбрасываются".
Здравствуйте, eao197, Вы писали:
CU>>Да ну? Пока софтописатели ничем не ограничены, они продают рекламу — гербалайф и биодобавки.
E>В области заказного ПО это не так.
С заказным — согласен. Но как только появятся "общеупотребительные" сертификаты на ПО — очень быстро попросят им соответствовать и в заказном ПО.
Здравствуйте, cl-user, Вы писали:
C>>Технологии создания ПО эволюционируют, тут все нормально. Но кардинально вряд ли что-то в ближайшем будущем изменится. CU>О, уже "вряд ли", а не "ничего нет". А если ещё усилия приложить?
А зачем? Тут ведь непонятно куда их прикладывать.
Здравствуйте, cl-user, Вы писали:
C>>Как ты себе представляешь сотрудничество кучи разных компаний со всего мира? CU>Не надо "кучи", надо "критической массы", которая (при числе конкурентов > 2) может быть меньше 50%. CU>И вы таки не слышали скандалов по поводу "межкорпорационных сговоров", иногда между откровенными конкурентами?
Так что клиентам-то делать? Им микроскопы, однако, нужны. И качество программ, в целом, их вполне удовлетворяет.
Так как платить в 100 раз больше за абсолютно надежную программу, разработка которой займет 10 лет — им просто нет смысла.
Здравствуйте, Cyberax, Вы писали:
C>>>Технологии создания ПО эволюционируют, тут все нормально. Но кардинально вряд ли что-то в ближайшем будущем изменится. CU>>О, уже "вряд ли", а не "ничего нет". А если ещё усилия приложить? C>А зачем? Тут ведь непонятно куда их прикладывать.
К разработке правил а-ля "расширенный стиль программирования"+доп. действий, соблюдение которых гарантирует отсутствие определённых ошибок в коде, и средств автоматической верификации на соответствие.
Здравствуйте, Cyberax, Вы писали:
CU>>Не надо "кучи", надо "критической массы", которая (при числе конкурентов > 2) может быть меньше 50%. CU>>И вы таки не слышали скандалов по поводу "межкорпорационных сговоров", иногда между откровенными конкурентами? C>Так что клиентам-то делать? Им микроскопы, однако, нужны. И качество программ, в целом, их вполне удовлетворяет.
Если их всё удовлетворяет, то делать здесь действительно нечего. А неудовлетворённым — искать пути выхода из неудовлетворительной ситуации.
Здравствуйте, cl-user, Вы писали:
C>>А зачем? Тут ведь непонятно куда их прикладывать. CU>К разработке правил а-ля "расширенный стиль программирования"+доп. действий, соблюдение которых гарантирует отсутствие определённых ошибок в коде, и средств автоматической верификации на соответствие.
Так ноль проблем! Верификаторы кода доступны уже лет 30.
Только вот они требуют огромных затрат по их использованию. Причем доказано, что сильно лучше их не сделать — все время упираемся в неразрешимую проблему останова. Кроме того, даже если и есть 100%-верный проверятель, то встанет следующая проблема — а как проверить спецификацию?
Практичные частичные проверятели тоже есть, начиная от инспекций в IDEA (IDE для Java) и кончая PreFast'ом от MS и анализатором от Coverity.
Здравствуйте, cl-user, Вы писали:
DC>> ну тогда приведи пример, за того ПО за повышенную надежность которого, ты согласен заплатить больше денег. И насколько больше.
CU>За любое, которое сложнее `cp`, `rm` и т.д. "Больше" — понятие относительное. Для начала, думаю, достаточно прекратить OEM-поставки софта
Ну допустим убунта стоит 0, сколько ты готов за неё выложить, вместе со всем софтом? За гарантии качества. Кстати какие гарантии ты захочешь?
DC>>Гарантий и ответственности от производителя ПО конечно хочется, но как это адекватно реализовать непонятно.
CU>Надо думать. А не отмахиваться "Не, не хочу! Невозможно! Нафиг не надо!!!"
Ну вот твои предложения, кроме тестирования.
DC>>Кстати, возникают проблемы с тем, что производитель находится в другой стране.
CU>Не более чем с любым другим товаром.
Другие товары через таможню везут, а в инете таможни ещё нет, и, надеюсь, не будет.
DC>>Мне это мой опыт подсказывает . Т.к. работаю я в такой компании, которая, в силу специфики софта, обязана вести жёсткий контроль качества и сертификацию тоже проходила, и тестирование на каждый чих. В итоге, реально работает только фидбэк от пользователей, которые, к тому же, жалуются на скорость внедрения новых фич.
CU>Хм, и ты 100% уверен, что виной тому, что "реально работает только фидбэк от пользователей" и т.д., _ТОЛЬКО_ внедрённый контроль качества и пройденная сертификация, и нет никакого пути улучшить ситуацию, не снизив при этом контроля за качеством?
Виновата не сертификация или контроль, а потребности пользователей: они хотят и надежность с гарантиями и новые фичи. Я же вижу очень много бюрократических процедур, которые отнимают моё время от основной задачи, их можно было б как то модифицировать, но, видимо, не хотят тратить ресурсы.
Короче виновато, то самое соотношение цена/качество. Мало того надо еще дорабатывать законодательство, чтоб я мог подать в суд на производителя ПО которое причинило мне урон, нужны средства для достоверного определения что именно эта программа причинила ущерб и т.п. Будет что-то подобное когда-нибудь или нет — не знаю, для некоторых областей вполне возможно. Но для массового ПО врядли.
Побеждающий других — силен,
Побеждающий себя — Могущественен.
Лао Цзы
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, Mr. None, Вы писали:
C>PolicyKit ликвидирует потребность запускать весь процесс как root.
Ага, то есть как раз наоборот прогрызает дырку в стандартных системных средствах защиты и ограничения доступа, то бишь сама крутится под рутом и от своего имени предоставляет интерфейсы для доступа к привелигированным операциям? Ещё лучше! Ф топку такое решение.
1) Где гарантия, что в самой этой службе нет ошибок и зловредный код не внедриться в саму эту службу, раз она работает от рута, то очень удобно;
2) Как насчёт фиксации, того кто именно совершил операцию? Она имперсонирует своего пользователя? Если да, то как она выполняет привелигированную операцию требующую рута? Если нет, то как система зафиксирует что дейтсвие выполнил вася пупкин, а не root? На лицо потенциальная проблема "Непризнания участия"...
C>>>Так я же сказал, что DBUS — это COM с человеческим лицом В том смысле, что там вещи типа настроек безопасности используются легко и просто, в отличие от COM. MN>>Я немного о другом, в данном случае речь об использовании COM`а для организации разграничения доступа к функциональности сервиса. Пишется COM-объект с контекстом запуска LOCAL_SERVER (точнее в данном случае это уже DCOM) либо с авто-запуском, либо живущий в некотором сервисе. И доступ к объекту ограничивается посредством обычного механизма COM-security. C>Да, это вполне возможно. Только вот никто так почти не делает — это сложно и громоздко. Я знаю, я как-то работал с системой безопасности NT. Там без бутылки не разобраться.
1) Не "вполне возможно", а просто можно и нужно.
2) Именно так делается в любом нормальном, профессионально разработанном серверном приложении.
3) Ничего сложного и громоздкого нет, всё очень просто, особенно, когда речь идёт о COM-security.
4) Система безопасность в NT была местами проще чем в Windows 2000 (про Windows Server 2008 я вообще молчу), проблемы были только с API по управлению ACL, но она легко решалась один раз написаниебиблиотеки (благо всё прозрачно и документировано).
5) Прежде чем говорить "я знаю" — подумайте, так ли это.
MN>>Вот тебе отдача: MN>>при включенном UAC (а вы его что отключаете на сервере? нехорошо, нехорошо...) менять настройки TCP/IP вообще без подтверждения нельзя ни одному процессу. C>Какой сервер? PolicyKit предназначен для user-friendly десктопа.
Что значит user-friendly десктоп? Консоль администратора к серверу — это user-friendly десктоп? Если да, то какая разница? Если вы имеете в виду обычную пользовательскую систему, то на ней я лучше включу антивирус, брэндмауэр, вырублю для администратора нафик все UAC`и и прочую фигню (чтобы система не умничала передо мной, когда мне это не нужно), а сам буду работать обычным пользователем.
MN>>А FireFox вообще запускаем с Integrity Level`ом "Low Mandatory Level" чтобы он вообще ничего не мог менять и даже вопросов не задавал (настраивается с помощью стандартного UI). Так что вообще ничего писать не надо. C>А злой вирус делает buffer overflow в FF, закачивает свое тело на диск и называет его "ОченьБезобиднаяПрограмма.exe". А потом запускает его и обходит UAC.
1) Программа с Integrity Level`ом "Low Mandatory Level" может сохранять данные только в определённый подкаталог домашнего каталога пользователя.
2) Integrity Level передаётся по наследством, всё что будет сохранено программой с Integrity Level`ом "Low Mandatory Level", будет иметь такой же Integrity Level и "ОченьБезобиднаяПрограмма.exe" не сможет ничего сделать.
C>>>На PolicyKit+AppArmor решается все просто — делается служба по изменению адреса и вешается на D-BUS. MN>>Ну уже всё не просто раз "делается служба" см. решение для Windows Server 2008... C>Почему? Служба — это просто один so-файл (dll то бишь), которая прописана в списке служю DBUS. Ничего сложного.
Какая разница, один или несколько. Лишний код — лишняя энтропия. Лишняя энтропия — лишняя поддержка, отладка, тестирование, ошибки и потенциальные проблемы с безопасностью. Если можно решить проблему с помощью минимального кодирования, нужно именно так и решать. Если можно решить проблему вообще без единой строчки кода — это вообще блестяще (вы ничего не написали, значит и проблем новых не добавили — всё). Поэтому решения, где надо хоть что-то написать, заведомо хуже решений, где ничего писать не надо.
C>Для сервера есть адский SELinux, где вообще можно сделать так, что даже адимнистратор не сможет прочитать твои данные без мер типа перезагрузки машины или аппаратных снифферов. Там полная реализация MAC (Mandatory Access Control) с поддержкой сетевых меток (т.е. можно сделать чтобы недоверенная служба не могла общаться с доверенной даже через IPC или сеть) и прочих фич.
Лишняя паранойя — это тоже чревато. С таким же успехом в Windows системах вы можете отобрать у всех администраторов привилегию "Take ownership of files or other objects", подредактировать дефолтные права на ветках реестра и файлах, где привилегии сохраняются (дабы запретить восстановление этой привилегии кому попало) и раздавать какие хотите права на принадлежащие вам объекты вплоть до полного запрета доступа администратора. Вот только если вы забудете пароль самого главного администратора, который может восстановить всё обратно, в этом случае даже перезагрузка не поможет...
C>>>При запуске файла AppArmor сам подхватит нужный профиль, который ставится вместе с приложением. MN>>Опять же совсем не просто . Обычному приложению это редко нужно, а для сервисов в Windows Server 2008 "сервисный аккаунт" создаётся автоматически при регистрации сервиса ничего писать не надо. C>FireFox/ThunderBird? Я лично один раз вирус через эксплоит в нем словил.
Vista, Server 2008 — Integrity Levels.
XP, Server 2003 — Safer.
И никаких проблем.
MN>>Дальше права для этого "аккаунта" вы раздаёте как хотите, хоть руками, хоть через программу установки. Вы даже можете использовать эту возможность для сервисов, которые были написаны до выхода Windows Server 2008 и ничего не знали о "сервисных аккаунтах". C>Неудобно, появляются проблемы, например, при замене файлов.
Какие проблемы? Где? Причём тут замена файлов?
C>>>Так тут флеймы такие в свое время были. MN>>О чём флэйм? C>Было предположение, что CAS неэффективен в unmanaged-системах из-за того, что нельзя контролировать разделение на доверяемый и недоверяемый код.
Ах этот... Помню — согласен, полная фигня . В конце концов никто так и не ответил на мой вопрос: а где гарантии, что самый ранний нативный загрузчик не атакован и не подменён. И совсем не смешно, как кажется, если вспомнить Blue Pill от госпожи Рудковской: новый тип атаки на систему с применением возможностей аппаратной поддержки виртуализации на процессорах; когда малварь — это по сути маленький такой гипервизор, использующий эти самые аппаратные возможности поддержки виртуализации для того, чтобы запустиьтся на системе и потом загрузить из под себя ОС; тут уже никакие антивирусы не спасают — они его просто не видят...
Компьютер сделает всё, что вы ему скажете, но это может сильно отличаться от того, что вы имели в виду.
Здравствуйте, Mr. None, Вы писали:
MN>Ага, то есть как раз наоборот прогрызает дырку в стандартных системных средствах защиты и ограничения доступа, то бишь сама крутится под рутом и от своего имени предоставляет интерфейсы для доступа к привелигированным операциям? Ещё лучше! Ф топку такое решение. MN>1) Где гарантия, что в самой этой службе нет ошибок и зловредный код не внедриться в саму эту службу, раз она работает от рута, то очень удобно;
Авторизацией занимается сам DBUS, коду которого мы доверяем. Адресное пространство службы защищено стандартными средстваим ОС.
Если зловредный код смог подсоединиться к службе, то значит он уже прошел авторизацию. Соответственно, нет никаких различий со случаем с использованием sudo/UAC. Кроме одного — код службы можно достаточно просто проаудитировать на проблемы безопасности, а в случае с sudo/UAC привиллегии получило бы всё приложение. Ну и можно еще службу ограничить дополнительно AppArmor'ом/SELinux'ом.
MN>2) Как насчёт фиксации, того кто именно совершил операцию? Она имперсонирует своего пользователя? Если да, то как она выполняет привелигированную операцию требующую рута? Если нет, то как система зафиксирует что дейтсвие выполнил вася пупкин, а не root? На лицо потенциальная проблема "Непризнания участия"...
DBUS предоставляет службе имя пользователя, запросившего действия. Impersonation тут не поможет — так как изначальный пользователь не имеет достаточно прав.
C>>Да, это вполне возможно. Только вот никто так почти не делает — это сложно и громоздко. Я знаю, я как-то работал с системой безопасности NT. Там без бутылки не разобраться. MN>1) Не "вполне возможно", а просто можно и нужно.
Тогда где у нас красивые и удобные аналоги? Я видел всего несколько приложений, которые использовали возможности DCOM для чего-то кроме простых вызовов. Одно из этих приложений (1С) в итоге переписали без DCOMа. Из моего опыта — с DCOMом постоянно были какие-то проблемы.
C>>Какой сервер? PolicyKit предназначен для user-friendly десктопа. MN>Что значит user-friendly десктоп?
Интерфейс, который будет изпользоваться тупыми юзерами.
MN>Консоль администратора к серверу — это user-friendly десктоп? Если да, то какая разница? Если вы имеете в виду обычную пользовательскую систему, то на ней я лучше включу антивирус, брэндмауэр, вырублю для администратора нафик все UAC`и и прочую фигню (чтобы система не умничала передо мной, когда мне это не нужно), а сам буду работать обычным пользователем.
Работать тупому юзеру простым пользователем в Винде? Ха. Хахаха.
А UAC как раз чаще всего и отключают — чтоб не мешал.
C>>А злой вирус делает buffer overflow в FF, закачивает свое тело на диск и называет его "ОченьБезобиднаяПрограмма.exe". А потом запускает его и обходит UAC. MN>1) Программа с Integrity Level`ом "Low Mandatory Level" может сохранять данные только в определённый подкаталог домашнего каталога пользователя.
А если я захочу сделать "Save as..." для картинки или документа? Упс... Ну или хотя бы поставить плугин (требуется запись в каталог FF)? И "Low Mandatory Level" идет лесом.
PolicyKit как раз и позволяет сделать, чтобы такие действия выполнялись без проблем.
MN>2) Integrity Level передаётся по наследством, всё что будет сохранено программой с Integrity Level`ом "Low Mandatory Level", будет иметь такой же Integrity Level и "ОченьБезобиднаяПрограмма.exe" не сможет ничего сделать.
Да, точно. Хотя может быть достаточно просто положить файлик на десктоп. Пользователь сам его запустит.
MN>Какая разница, один или несколько. Лишний код — лишняя энтропия. Лишняя энтропия — лишняя поддержка, отладка, тестирование, ошибки и потенциальные проблемы с безопасностью. Если можно решить проблему с помощью минимального кодирования, нужно именно так и решать. Если можно решить проблему вообще без единой строчки кода — это вообще блестяще (вы ничего не написали, значит и проблем новых не добавили — всё). Поэтому решения, где надо хоть что-то написать, заведомо хуже решений, где ничего писать не надо.
Ну да, поэтому PolicyKit удобнее — там все просто и прозрачно.
MN>Лишняя паранойя — это тоже чревато. С таким же успехом в Windows системах вы можете отобрать у всех администраторов привилегию "Take ownership of files or other objects", подредактировать дефолтные права на ветках реестра и файлах, где привилегии сохраняются (дабы запретить восстановление этой привилегии кому попало) и раздавать какие хотите права на принадлежащие вам объекты вплоть до полного запрета доступа администратора.
А еще надо не забыть убрать привиллегию отладки, возможность устанавливать сервисы, не забыть закрыть множество мелких дырок и т.п. В общем, нереально. Особенно учитывая, что нет вещей типа сетевых меток безопасности. SELinux дает полностью систему контроля доступа на все стороны деятельности системы, фактически, получается capability-based security.
И да, из-за параноидальности SELinux для сервера вполне нормально использовать (я использую ), для десктопа — слишком неудобно. Очень часто встречаются случаи, когда безопасность мешает работе.
MN>Вот только если вы забудете пароль самого главного администратора, который может восстановить всё обратно, в этом случае даже перезагрузка не поможет...
С чего бы? Грузимся с live-cd, спокойно меняем из Линукса нужные ACLи, и телемаркет. Даже если раздел зашифрован, то надо просто знать пароль пользователя, умеющего его расшифровывать.
C>>FireFox/ThunderBird? Я лично один раз вирус через эксплоит в нем словил. MN>Vista, Server 2008 — Integrity Levels. MN>XP, Server 2003 — Safer. MN>И никаких проблем.
Есть проблемы
C>>Неудобно, появляются проблемы, например, при замене файлов. MN>Какие проблемы? Где? Причём тут замена файлов?
С сервисами проблема в том, что или нужно чтобы они имели доступ только к своему поддереву (чтобы можно было сделать наследуемые разрешения). Ставить разрешения на файлы вне своего поддерева — неудобно и непрактично. Т.е. если я хочу, чтобы сервис имел доступ к файлам system32/user32.dll, system32/gdi32.dll, system32/myprintdriver.dll но ни к каким другим — то мне придется добавлять ACLи на всю system32. Причем если autoupdate решит поменять myprintdriver.dll — то у нас все резко сломается.
Проблему можно частично решить, если ввести роли — "графический сервис", "сервис, имеющий доступ к принтерам" и т.п. Но как показывает практика, все равно получается слишком много исключений.
В AppArmor мы отделяем политику безопасности от метаданных самого файла.
C>>Было предположение, что CAS неэффективен в unmanaged-системах из-за того, что нельзя контролировать разделение на доверяемый и недоверяемый код. MN>Ах этот... Помню — согласен, полная фигня . В конце концов никто так и не ответил на мой вопрос: а где гарантии, что самый ранний нативный загрузчик не атакован и не подменён. И совсем не смешно, как кажется, если вспомнить Blue Pill от госпожи Рудковской: новый тип атаки на систему с применением возможностей аппаратной поддержки виртуализации на процессорах; когда малварь — это по сути маленький такой гипервизор, использующий эти самые аппаратные возможности поддержки виртуализации для того, чтобы запустиьтся на системе и потом загрузить из под себя ОС; тут уже никакие антивирусы не спасают — они его просто не видят...
Ну Blue Pill обнаруживается кучей способов пока что, тут никаких особых проблем.
А защита от замены начального загрузчика тоже есть. Правда, нужно заменить BIOS на EFI (Extensible Firmware Interface) — там есть возможность записать проверить, что загружаемое ядро имеет правильную цифровую подпись. Ну а ядро уже дальше само может проверить целостность системы. Это сейчас во всяких приставках как раз используется для защиты от mod-чипов. Да, и Линукс это тоже поддерживает
Здравствуйте, cl-user, Вы писали:
CU>Архитектура — в большей или меньшей степени "разработка и проектирование"? А любое КБ? Но все они выдают "стандартизированную продукцию". В отличие от.
Архитектура — прямой вред здоровью в случае проблем. Имеет смысл позаботиться о безопасности. Надо ли заботиться о безопасности текстового редактора?
И обратно в "реальный мир":
Какие сертификаты должна иметь дизайн студия? Рекламное агентство? Фотостудия?
А ты знаешь что есть сертификаты (и советские еще ГОСТ и заграничные ISO) на софт и документацию к нему? А знаешь что большинство заказчиков кладут на соответствие им с глубоким пробором, поскольку их наличие/отсутствие их меньше волнует чем реальная функциональность и надежность полученного софта?
Здравствуйте, FR, Вы писали: FR>В гугле прочитал что в 2001 году Боинг первый из авиапроизводителей испольльзовал конвеер для сборки самолетов.
Ага. А в передаче "русский экстрим" впервые аквалангист нырнул на 25 метров в 2005 году.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, FR, Вы писали: FR>Его к конвейру привязали, или он с борта боинга нырял?
Не, это привязали к большому пеару. Реальные аквалангисты силько смеялись над этим "рекордом". У авторов передачи как-то брали интервью, и спросили "вам не стыдно вот такую фигню заявлять?". Они сказали, что это, дескать, не про рекорды, а про смелость человека, и ежели не нагнетать, то никто не поймет, как это круто. Вкратце: не стыдно.
Так что и Боинг может заявлять, что применил конвеер впервые в 2001, а до этого обходился обычным постадийным сборочным процессом. И что гайки они вообще стали использовать в 2008, а раньше, как и все, использовали шестигранные резьбовые соединители.
З.Ы. Это сарказм.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, fmiracle, Вы писали:
F>Я бы спросил иначе — хотел бы ты, как пользователь платить за программу типа ICQ или Winamp или пусть даже Office столько, сколько стоит ПО для Боинга?
Не предёргивайте.
F>Ты тут все время радеешь за пользователей — ну вот я как пользователь скажу тебе — иди-ка ты лесом с такими предложениями.
Ты как пользователь или как "пейсатель" глаголешь?
F>Мне не нужны гарантии,
Ок, в Африку, в Афган, в Индию в конце концов — никаких гарантий. В Китай "низзя" — есть гарантия "к стенке" в случае "непослушания".
F>А сертифицирование это те еще расходы.
Не спорю. Но только "какие" — ты уже всё посчитал?
F>Мне не так уж и страшно, что текстовый редактор внезапно умер.
Тебе не старшно — свободен. Надеюсь ты не собираешься "за всех" говорить?
F>Если он умирает слишком часто — я найду другой (при том что сперва я тоже тщательно повыбираю что мне использовать). У другой компании.
Угу. И так в масштабе 1-й конторы на 1000 компов / 100 000 компов / ТНК / некотрого министерства некоторой страны? И нах. любые гарантии?
F>Которых много. Мелких. Которых ты предлагаешь уничтожить. Ради какой-то абстрактной "гарантии".
Не предлагаю. Сами закроются как только их попросят хотя-бы "гарантировать исправление ошибки в определённый период с момента получения сообщения об ошибке". Или всех убогих будем кормить?
F>Вот у нас мелкая компания — разработчик ПО. Мы даем гарантию на наш софт.
Молодцы — ничего не скажешь. Почему ты других от этого "ограждаешь"? Конечно, свобода самому брать на себя произвольные обязательства дороже любых правил!
F>Безо всяких законодательных требований. Потому это это нужно для нормальных отношений с заказчиком.
Ну а зачем правила дорожного движения для "нормальных отношений" с пешеходами?
F>Это же есть суть изначальная причина возникновения гарантии на товары. Причина их не в сертификатах и не в законах. А в том, что пользователь скорее купит вещь, на которую есть гарантия.
Т.е. сначала _все_ производители продуктов питания стали давать гарантии и следовать ТУ, а только потом их ввели на гос. уровне? "Не смешите мои тапочки!"
F>Еще есть нормы на товары, способные повредить здоровью — продукты питания, те же телефоны, хим. товары. Но софт не может причинить вред здоровью человека, потому сравнение с колбасой тут просто неуместно.
Т.е. _все_ товары могут повредить здоровью, кроме программ? Вы заблуждаетесь.
F>Вкратце: проснись, оглядись вокруг и кончай воевать с ветряными мельницами.
ну тогда приведи пример, за того ПО за повышенную надежность которого, ты согласен заплатить больше денег. И насколько больше.
