> 1. в нормально написанных программах разрешать ничего не надо - все с
> собой, а в идеале в одном package.ну да, статически слинкованный с набором сторонних библиотек (или у вас в ваших нормально написанных программах и реализация libc своя, не говоря об остальном? [только хотя бы здесь не надо про .net - мы сейчас про материи несколько иного толка и уровня; надеюсь, вы это понимаете]), от чего после некоторого времени использования таких "package" система превращается в одно сплошное bloatware.
> dll-hell подобные проблемы пусть
> остаются в линуксах
> dll-hell
> в линуксах
э, если вдруг кто не в курсе, существованием dll-hell'а мы обязаны криво мертворожденной архитектуре Windows NT ( другой пример такого просчёта - http://habrahabr.ru/blogs/development/53048/ ); казалось бы, при чём здесь [качественные] зрелые пакетные системы Linux/UNIX-дистрибутивов, в которых dll-hell'а нет, не было и быть не может (например, не составляет труда и особых проблем установить разные версии одной и той же библиотеки). Кстати, по поводу других UNIX'ов - даже OSX-девелы уже давно осилили реализовать некое подобие пакетных систем в виде macports/fink.
Также, нельзя не обратить внимание на весьма известный приём демагогической полемики, когда из списка аргументов находится один-единственный, и грозно "разоблачается", при этом остальные остаются без внимания. Если уж представляете интересы Microsoft в данной дискуссии, то будьте добры прояснить все моменты (а не только тот, который "удобен"), связанные с тем, что, по мнению инновационной компании Microsoft, пакетные менеджеры не нужны, а то, для чего они нужны, уже умеет MSI.
Итак, ещё раз (на всякий случай повторю; на первые три вопроса было бы очень приятно получить ссылки на соответствующую официальную документацию, серьёзно):
- Предоставляет ли Microsoft *официальное* API (то, что сам разработчик может выдумать какие угодно ни с чем не совместимые костыли - можно не рассказывать) для механизма MSI, чтобы при установке приложения оно само, если оно того требует, выкачивало и устанавливало другие MSI-файлы из других мест (и так далее по рекурсии)?
- Предоставляет ли Microsoft *официальное* API для сборки MSI в почти автоматическом режиме со всем необходимым за несколько минут, и тестирования его в изолированном окружении на локальной машине?
- Предоставляет ли Microsoft *официальное* API для механизма MSI, позволяющее пользователю отследить, какие файлы при установке приложения копируются, и где какие изменения на уровне системы осуществляются?
- Почему Microsoft, идущий "на публике" рука об руку с принципом "dogfooding", и вкладывающий в CodePlex развитие, пиар и продвижение, размещает свой официальный проект на "никому не нужном созданном красноглазыми школьниками-пионерами" хостинге проектов, "предназначенном для 3,5 разработчиков-пользователей линупса"?
- Как по-вашему, является ли предыдущий пункт следствием того, что CodePlex не имеет качественной взаимной интеграции между:
1. качественным баг-трекером;
2. качественной децентрализованной системой контроля версий исходного кода;
3. автоматической системой сборки программ/пакетов и единым безопасным методом централизованного их распространения для потенциальных пользователей;
4. автоматической системой сборки и доставки отчётов об ошибках (в интересах сторонних разработчиков, а не такой системы отчётов об ошибке, при которой отчёты можно просмотреть, только являясь сотрудником Microsoft, и которые отправляются неизвестно куда, неизвестно кому, с неизвестно какой информацией)
- Считаете ли вы, что Microsoft, опубликовав проект на стороннем сервисе, расписалась в убогости и ущербности собственного CodePlex'а? Если нет, то почему проект в таком случае всё же не выложили на CodePlex?
