Разработчики Microsoft представили (http://blogs.msdn.com/garretts/archive/2010/04/07/what-s-thi...) приложение CoApp (https://launchpad.net/coapp) - универсальную Windows-среду для распространения, компиляции и создания пакетов из Open Source приложений, напоминающую по своей сути пакетный менеджеры APT и YUM. В качестве формата пакетов будет использоваться стандартный для Windows формат MSI. Компания Microsoft позволила (http://blogs.msdn.com/garretts/archive/2010/03/31/the-common...) одному из сотрудников работать над новым проектом в режиме полного рабочего дня.

Причины, подтолкнувшие к созданию  CoApp:

-  Различная идеология Unix и Windows - расположение файлов и библиотек программ, API, методы доступа к файловой системе и т.д.;
-  Сложность в установке и настройке пакетов зависимостей для конкретного OpenSource приложения (так, например, для сборки вам могут понадобиться библиотека zlib или OpenSSL...

URL: http://arstechnica.com/open-source/news/2010/04/microsoft-of...
Новость: http://www.opennet.me/opennews/art.shtml?num=26153

• Microsoft разрабатывает открытый APT-подобный пакетный менед...,croster, 12:44 , 09-Апр-10
  • Microsoft разрабатывает открытый APT-подобный пакетный менед...,Трухин Юрий Владимирович, 13:20 , 09-Апр-10
    • Microsoft разрабатывает открытый APT-подобный пакетный менед...,_Vitaly_, 13:39 , 09-Апр-10
    • Microsoft разрабатывает открытый APT-подобный пакетный менед...,Gular, 14:29 , 09-Апр-10
      • Microsoft разрабатывает открытый APT-подобный пакетный менед...,Трухин_Юрий_Владимирович, 15:58 , 09-Апр-10
        • Microsoft разрабатывает открытый APT-подобный пакетный менед...,минона, 16:14 , 09-Апр-10
          • Microsoft разрабатывает открытый APT-подобный пакетный менед...,Warhead Wardick, 16:39 , 09-Апр-10
          • Microsoft разрабатывает открытый APT-подобный пакетный менед...,iav, 20:55 , 09-Апр-10
        • Microsoft разрабатывает открытый APT-подобный пакетный менед...,_Vitaly_, 16:41 , 09-Апр-10
          • Microsoft разрабатывает открытый APT-подобный пакетный менед...,Bliznezz, 16:52 , 09-Апр-10
          • Microsoft разрабатывает открытый APT-подобный пакетный менед...,User294, 02:32 , 11-Апр-10
    • Microsoft разрабатывает открытый APT-подобный пакетный менед...,User294, 16:39 , 09-Апр-10
      • Microsoft разрабатывает открытый APT-подобный пакетный менед...,Warhead Wardick, 16:40 , 09-Апр-10
        • Microsoft разрабатывает открытый APT-подобный пакетный менед...,Warhead Wardick, 16:45 , 09-Апр-10
          • Microsoft разрабатывает открытый APT-подобный пакетный менед...,User294, 20:46 , 09-Апр-10
        • Microsoft разрабатывает открытый APT-подобный пакетный менед...,User294, 21:17 , 10-Апр-10
  • Microsoft разрабатывает открытый APT-подобный пакетный менед...,anonymous vulgaris, 20:56 , 09-Апр-10
    • Microsoft разрабатывает открытый APT-подобный пакетный менед...,Michael Shigorin, 00:15 , 10-Апр-10
      • Microsoft разрабатывает открытый APT-подобный пакетный менед...,thirteensmay, 01:04 , 10-Апр-10
        • о версиях библиотек,Michael Shigorin, 01:43 , 10-Апр-10
          • о версиях библиотек,thirteensmay, 02:06 , 10-Апр-10
            • о версиях библиотек,User294, 21:21 , 10-Апр-10
    • Microsoft разрабатывает открытый APT-подобный пакетный менед...,Petr Vokhmintsev, 11:50 , 12-Апр-10
• Microsoft разрабатывает открытый APT-подобный пакетный менед...,Zenitur, 12:46 , 09-Апр-10
  • Microsoft разрабатывает открытый APT-подобный пакетный менед...,ZigmunD, 15:47 , 09-Апр-10
    • Microsoft разрабатывает открытый APT-подобный пакетный менед...,gutaper, 17:51 , 09-Апр-10
• Microsoft разрабатывает открытый APT-подобный пакетный менед...,ffsdmad, 12:47 , 09-Апр-10
  • Microsoft разрабатывает открытый APT-подобный пакетный менед...,zerot, 15:23 , 09-Апр-10
  • Microsoft разрабатывает открытый APT-подобный пакетный менед...,User294, 16:41 , 09-Апр-10
    • Microsoft разрабатывает открытый APT-подобный пакетный менед...,xxx, 19:12 , 09-Апр-10
      • Microsoft разрабатывает открытый APT-подобный пакетный менед...,User294, 21:00 , 09-Апр-10
• Microsoft разрабатывает открытый APT-подобный пакетный менед...,Zenitur, 12:48 , 09-Апр-10
  • Microsoft разрабатывает открытый APT-подобный пакетный менед...,Трухин Юрий Владимирович, 14:18 , 09-Апр-10
    • Microsoft разрабатывает открытый APT-подобный пакетный менед...,имя_для_форума, 17:09 , 09-Апр-10
  • Microsoft разрабатывает открытый APT-подобный пакетный менед...,User294, 16:42 , 09-Апр-10
    • Microsoft разрабатывает открытый APT-подобный пакетный менед...,Zenitur, 20:55 , 09-Апр-10
      • Microsoft разрабатывает открытый APT-подобный пакетный менед...,User294, 21:08 , 09-Апр-10
        • Microsoft разрабатывает открытый APT-подобный пакетный менед...,iZEN, 09:18 , 10-Апр-10
          • Microsoft разрабатывает открытый APT-подобный пакетный менед...,andy, 10:05 , 10-Апр-10
            • Microsoft разрабатывает открытый APT-подобный пакетный менед...,Michael Shigorin, 10:59 , 10-Апр-10
              • Microsoft разрабатывает открытый APT-подобный пакетный менед...,andy, 13:01 , 10-Апр-10
                • Microsoft разрабатывает открытый APT-подобный пакетный менед...,Michael Shigorin, 00:49 , 11-Апр-10
          • Microsoft разрабатывает открытый APT-подобный пакетный менед...,User294, 02:49 , 11-Апр-10
• Microsoft разрабатывает открытый APT-подобный пакетный менед...,SubGun, 12:49 , 09-Апр-10
• Microsoft разрабатывает открытый APT-подобный пакетный менед...,atxn, 12:50 , 09-Апр-10
  • Microsoft разрабатывает открытый APT-подобный пакетный менед...,ffsdmad, 12:53 , 09-Апр-10
    • Microsoft разрабатывает открытый APT-подобный пакетный менед...,fi, 19:19 , 09-Апр-10
• Microsoft разрабатывает открытый APT-подобный пакетный менед...,atxn, 12:57 , 09-Апр-10
  • Microsoft разрабатывает открытый APT-подобный пакетный менед...,Zenitur, 21:02 , 09-Апр-10
• Microsoft разрабатывает открытый APT-подобный пакетный менед...,Аноним, 12:57 , 09-Апр-10
  • Microsoft разрабатывает открытый APT-подобный пакетный менед...,Аноним, 13:11 , 09-Апр-10
    • Microsoft разрабатывает открытый APT-подобный пакетный менед...,Анон, 15:15 , 09-Апр-10
      • Microsoft разрабатывает открытый APT-подобный пакетный менед...,Zenitur, 20:43 , 09-Апр-10
      • Microsoft разрабатывает открытый APT-подобный пакетный менед...,anonymous, 08:35 , 12-Апр-10
        • Microsoft разрабатывает открытый APT-подобный пакетный менед...,Michael Shigorin, 11:38 , 12-Апр-10
    • Microsoft разрабатывает открытый APT-подобный пакетный менед...,eve, 16:01 , 09-Апр-10
    • Microsoft разрабатывает открытый APT-подобный пакетный менед...,Michael Shigorin, 00:32 , 10-Апр-10
• Microsoft разрабатывает открытый APT-подобный пакетный менед...,LeNiN, 13:02 , 09-Апр-10
  • Microsoft разрабатывает открытый APT-подобный пакетный менед...,pavlinux, 13:09 , 09-Апр-10
• Microsoft разрабатывает открытый APT-подобный пакетный менед...,pavlinux, 13:08 , 09-Апр-10
  • Microsoft разрабатывает открытый APT-подобный пакетный менед...,User294, 21:14 , 09-Апр-10
• Microsoft разрабатывает открытый APT-подобный пакетный менед...,Аноним, 13:09 , 09-Апр-10
  • Microsoft разрабатывает открытый APT-подобный пакетный менед...,Трухин Юрий Владимирович, 14:23 , 09-Апр-10
    • Microsoft разрабатывает открытый APT-подобный пакетный менед...,Аноним, 14:40 , 09-Апр-10
      • Главное не забудьте обновить,none, 15:54 , 09-Апр-10
        • Главное не забудьте обновить,Трухин_Юрий_Владимирович, 16:01 , 09-Апр-10
          • Главное не забудьте обновить,минона, 16:30 , 09-Апр-10
            • Главное не забудьте обновить,Трухин_Юрий_Владимирович, 18:20 , 09-Апр-10
              • Главное не забудьте обновить,минона, 19:29 , 09-Апр-10
                • Главное не забудьте обновить,User294, 21:18 , 09-Апр-10
                  • Главное не забудьте обновить,iZEN, 09:36 , 10-Апр-10
                    • Главное не забудьте обновить,минона, 14:38 , 10-Апр-10
                    • Главное не забудьте обновить,User294, 20:46 , 10-Апр-10
                      • Главное не забудьте обновить,iZEN, 19:55 , 12-Апр-10
                        • Главное не забудьте обновить,Michael Shigorin, 00:19 , 13-Апр-10
                    • Главное не забудьте обновить,Michael Shigorin, 00:18 , 11-Апр-10
                      • Главное не забудьте обновить,iZEN, 20:09 , 12-Апр-10
                        • *sigh*,Michael Shigorin, 00:35 , 13-Апр-10
                          • *sigh*,iZEN, 01:49 , 13-Апр-10
                          • *sigh*,iZEN, 01:56 , 13-Апр-10
                            • *sigh*,Michael Shigorin, 11:12 , 13-Апр-10
                              • *sigh*,iZEN, 17:14 , 13-Апр-10
                                • *sigh*,Andrey Mitrofanov, 17:28 , 13-Апр-10
                                • *sigh*,Michael Shigorin, 23:27 , 13-Апр-10
        • Microsoft разрабатывает открытый APT-подобный пакетный менед...,минона, 16:28 , 09-Апр-10
        • Microsoft разрабатывает открытый APT-подобный пакетный менед...,минона, 16:23 , 09-Апр-10
        • Microsoft разрабатывает открытый APT-подобный пакетный менед...,имя_для_форума, 19:10 , 09-Апр-10
        • Microsoft разрабатывает открытый APT-подобный пакетный менед...,User294, 21:21 , 09-Апр-10
        • Microsoft разрабатывает открытый APT-подобный пакетный менед...,Wolfis, 00:27 , 10-Апр-10
          • Microsoft разрабатывает открытый APT-подобный пакетный менед...,Michael Shigorin, 10:50 , 10-Апр-10
      • Microsoft разрабатывает открытый APT-подобный пакетный менед...,anonymous vulgaris, 21:05 , 09-Апр-10
        • Microsoft разрабатывает открытый APT-подобный пакетный менед...,User294, 21:23 , 09-Апр-10
          • Microsoft разрабатывает открытый APT-подобный пакетный менед...,anonymous vulgaris, 22:25 , 09-Апр-10
            • Microsoft разрабатывает открытый APT-подобный пакетный менед...,User294, 21:08 , 10-Апр-10
        • Microsoft разрабатывает открытый APT-подобный пакетный менед...,Wolfis, 00:36 , 10-Апр-10
        • Microsoft разрабатывает открытый APT-подобный пакетный менед...,sergey, 16:54 , 10-Апр-10
    • Microsoft разрабатывает открытый APT-подобный пакетный менед...,Аноним, 15:09 , 09-Апр-10
    • Microsoft разрабатывает открытый APT-подобный пакетный менед...,Аноним, 15:15 , 09-Апр-10
    • Microsoft разрабатывает открытый APT-подобный пакетный менед...,Анон, 15:20 , 09-Апр-10
    • Microsoft разрабатывает открытый APT-подобный пакетный менед...,имя_для_форума, 15:35 , 09-Апр-10
      • Microsoft разрабатывает открытый APT-подобный пакетный менед...,Sugar, 16:41 , 09-Апр-10
    • Microsoft разрабатывает открытый APT-подобный пакетный менед...,аноним, 17:25 , 09-Апр-10
      • Microsoft разрабатывает открытый APT-подобный пакетный менед...,Трухин_Юрий_Владимирович, 18:24 , 09-Апр-10
        • Microsoft разрабатывает открытый APT-подобный пакетный менед...,Andrey Mitrofanov, 18:33 , 09-Апр-10
        • Microsoft разрабатывает открытый APT-подобный пакетный менед...,имя_для_форума, 19:04 , 09-Апр-10
        • Microsoft разрабатывает открытый APT-подобный пакетный менед...,Michael Shigorin, 00:29 , 11-Апр-10
    • Microsoft разрабатывает открытый APT-подобный пакетный менед...,andy, 17:28 , 09-Апр-10
    • Microsoft разрабатывает открытый APT-подобный пакетный менед...,Michael Shigorin, 00:40 , 10-Апр-10
      • Microsoft разрабатывает открытый APT-подобный пакетный менед...,аноним, 01:22 , 10-Апр-10
        • Microsoft разрабатывает открытый APT-подобный пакетный менед...,Michael Shigorin, 01:48 , 10-Апр-10
    • Microsoft разрабатывает открытый APT-подобный пакетный менед...,iZEN, 09:23 , 10-Апр-10
      • windows, pcbsd и прочие,Michael Shigorin, 11:10 , 10-Апр-10
      • Microsoft разрабатывает открытый APT-подобный пакетный менед...,User294, 02:04 , 11-Апр-10
• Microsoft разрабатывает открытый APT-подобный пакетный менед...,Cobold, 13:57 , 09-Апр-10
  • Microsoft разрабатывает открытый APT-подобный пакетный менед...,Michael Shigorin, 00:41 , 10-Апр-10
    • Microsoft разрабатывает открытый APT-подобный пакетный менед...,Andrey Mitrofanov, 12:40 , 10-Апр-10
• Microsoft разрабатывает открытый APT-подобный пакетный менед...,Шурек Табуреткин, 14:03 , 09-Апр-10
• Microsoft разрабатывает открытый APT-подобный пакетный менед...,Аноним, 14:20 , 09-Апр-10
• apt-cyg (cygwin),Аноним, 14:20 , 09-Апр-10
• Microsoft разрабатывает открытый APT-подобный пакетный менед...,polymorphm1, 14:40 , 09-Апр-10
  • Microsoft разрабатывает открытый APT-подобный пакетный менед...,fi, 19:56 , 09-Апр-10
• Microsoft разрабатывает открытый APT-подобный пакетный менед...,Анон, 14:58 , 09-Апр-10
• Microsoft разрабатывает открытый APT-подобный пакетный менед...,mvalery, 15:18 , 09-Апр-10
  • Microsoft разрабатывает открытый APT-подобный пакетный менед...,имя_для_форума, 15:44 , 09-Апр-10
    • Microsoft разрабатывает открытый APT-подобный пакетный менед...,Ы, 17:24 , 09-Апр-10
      • Microsoft разрабатывает открытый APT-подобный пакетный менед...,Cobold, 19:11 , 09-Апр-10
      • Microsoft разрабатывает открытый APT-подобный пакетный менед...,mvalery, 19:29 , 09-Апр-10
  • Microsoft разрабатывает открытый APT-подобный пакетный менед...,XoRe, 00:53 , 10-Апр-10
    • Microsoft разрабатывает открытый APT-подобный пакетный менед...,mvalery, 14:57 , 10-Апр-10
      • Microsoft разрабатывает открытый APT-подобный пакетный менед...,Трухин_Юрий_Владимирович, 19:32 , 10-Апр-10
        • Microsoft разрабатывает открытый APT-подобный пакетный менед...,Michael Shigorin, 00:32 , 11-Апр-10
        • Microsoft разрабатывает открытый APT-подобный пакетный менед...,User294, 02:20 , 11-Апр-10
  • Microsoft разрабатывает открытый APT-подобный пакетный менед...,User294, 02:14 , 11-Апр-10
    • Microsoft разрабатывает открытый APT-подобный пакетный менед...,mvalery, 22:41 , 11-Апр-10
• Microsoft разрабатывает открытый APT-подобный пакетный менед...,o2inhal, 15:19 , 09-Апр-10
• Microsoft разрабатывает открытый APT-подобный пакетный менед...,Илья, 16:15 , 09-Апр-10
• Microsoft разрабатывает открытый APT-подобный пакетный менед...,GameForLinux, 16:20 , 09-Апр-10
  • Microsoft разрабатывает открытый APT-подобный пакетный менед...,имя_для_форума, 17:29 , 09-Апр-10
  • Microsoft разрабатывает открытый APT-подобный пакетный менед...,Cobold, 17:49 , 09-Апр-10
• Microsoft разрабатывает открытый APT-подобный пакетный менед...,Iv946n, 18:07 , 09-Апр-10
  • Microsoft разрабатывает открытый APT-подобный пакетный менед...,XoRe, 00:55 , 10-Апр-10
  • Microsoft разрабатывает открытый APT-подобный пакетный менед...,User294, 03:18 , 11-Апр-10
• Microsoft разрабатывает открытый APT-подобный пакетный менед...,имя_для_форума, 19:46 , 09-Апр-10
  • Microsoft разрабатывает открытый APT-подобный пакетный менед...,koblin, 21:14 , 09-Апр-10
• Microsoft разрабатывает открытый APT-подобный пакетный менед...,crls lesser, 20:18 , 09-Апр-10
• Microsoft разрабатывает открытый APT-подобный пакетный менед...,Zenitur, 20:52 , 09-Апр-10
  • Microsoft разрабатывает открытый APT-подобный пакетный менед...,паразит, 11:35 , 10-Апр-10
• Microsoft разрабатывает открытый APT-подобный пакетный менед...,Аноним, 22:07 , 09-Апр-10
  • Microsoft разрабатывает открытый APT-подобный пакетный менед...,XoRe, 01:09 , 10-Апр-10
  • Microsoft разрабатывает открытый APT-подобный пакетный менед...,thirteensmay, 01:23 , 10-Апр-10
    • Microsoft разрабатывает открытый APT-подобный пакетный менед...,Michael Shigorin, 01:50 , 10-Апр-10
      • Microsoft разрабатывает открытый APT-подобный пакетный менед...,thirteensmay, 02:55 , 10-Апр-10
        • Microsoft разрабатывает открытый APT-подобный пакетный менед...,Michael Shigorin, 00:41 , 11-Апр-10
  • Microsoft разрабатывает открытый APT-подобный пакетный менед...,iZEN, 10:06 , 10-Апр-10
    • Microsoft разрабатывает открытый APT-подобный пакетный менед...,light, 13:48 , 10-Апр-10
      • Microsoft разрабатывает открытый APT-подобный пакетный менед...,Трухин_Юрий_Владимирович, 14:39 , 10-Апр-10
        • Microsoft разрабатывает открытый APT-подобный пакетный менед...,Michael Shigorin, 00:45 , 11-Апр-10
        • Microsoft разрабатывает открытый APT-подобный пакетный менед...,User294, 03:23 , 11-Апр-10
• Microsoft разрабатывает открытый APT-подобный пакетный менед...,Myc, 22:02 , 11-Апр-10
• Microsoft разрабатывает открытый APT-подобный пакетный менед...,аноним, 15:05 , 12-Апр-10
• Microsoft разрабатывает открытый APT-подобный пакетный менед...,maotm, 08:51 , 14-Апр-10

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

это правда. Разрабатывается одним из сотрудников Microsoft на открытой основе. Хостится на ланчпаде

Кодеплекс от лидера отрасли не подошел?

почему не их Codeplex? оно уже не актуально?

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

этот проект придумал сотрудник Microsoft и пишет его. Хочется ему. вот и все...

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

"Потому что ты на войне а он на работе!"(С)Антикиллер :)

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

Очередной приступ ритуального кретинизма. "Майкрософт человеку оплачивает фуллтайм. Хочется ему. вот и все"

http://bash.org.ru/quote/325507

<MaSyA> Чем заробатываеш на жизнь.
<bubajazz> Пишу программы под виндовз.
<MaSyA> Ухты, сложно наверное.
<bubajazz> Да напрягает немного :(
<MaSyA> Как после работы расслабляешся?
<bubajazz> Пишу программы под Линух :)))

>Очередной приступ ритуального кретинизма.

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

>это правда. Разрабатывается одним из сотрудников Microsoft на открытой основе.

Планирует ли компания Майкрософт закрытие этого кода? Зачем им лицензия BSD допускающая закрытие? Майкрософт хочет нахаляву попользоваться результатами труда комьюнити и потом закрыть все нафиг, когда над этим будет пахать не 1 сотрудник?

Альтернативно одарённым - BSDL продукт закрыть нельзя. Можно сделать закрытый форк.

Это я не к тому что M$ белая и пушистая, это я для BSDL advocate ...

В чем подвох. Видимо обнаружился нехилый деманд на OSS :) И оне хотят стать ведущей платформой для него, чтоб по форумам не говорили "и напуркуа такие припарки? Ставь Линукс - там всё просто работает!"

Что за разговоры сами с собой? oO

> И оне хотят стать ведущей платформой для него,

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

>Альтернативно одарённым - BSDL продукт закрыть нельзя. Можно сделать закрытый форк.

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

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

А как вам удается под форточками иметь проблемы с зависимостями?

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

Вот в линуксе бывает. Причем забавно/печально сравнить установку кроссплатформенной программы на обе системы, очень поучительно бывает.

Например довольно типичные вещи
http://rpdn.ru/forum/14/42/923/
http://www.freepascal.ru/article//lazarus/20080316091540/

С форточным же лазарем проблем установки просто нет. Никаких. Вообще. Нажал установить = поставил.

>А как вам удается под форточками иметь проблемы с зависимостями?

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

>С форточным же лазарем проблем установки просто нет. Никаких. Вообще.

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

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

>так а у вас проблемы зависимостей разве никого не имеют ?

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

>я разработчик оттестировал свое ПО под одну версию либы, другой - под
>другую, тащим 2 версии, может не оптимально но четко

Библиотек, у которых при неизменном ABI заметно меняется поведение -- сторонним разработчикам следует стараться избегать.  Соответственно разумный вендор старается избежать ситуации, когда разработчикам на его платформе приходится именно что таскать всё с собой, потому как полшага в сторону -- и сегфолт/gpf в лоб (камень в огород java).

>хотим оптимально - юзаем общие либы, но это не надежно.

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

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

>Как у вас решается проблема разных версий одной библиотеки?

http://www.altlinux.org/SharedLibsPolicy
http://www.debian.org/doc/debian-policy/ch-sharedlibs.html

$ rpm -qf /usr/lib/libltdl.so.3 /usr/lib/libltdl.so.7
libltdl3-1.5.26-alt8
libltdl7-2.2.6b-alt1

>за счет какого магического способа вы не тащите двух версий?

Пересборка использующих библиотеку программ с новым ABI.  Если API не изменился, то обычно полуавтоматическая (в альте по крайней мере).

>не уж то надеетесь на то что новая версия будет вести себя также как и старая ?

Представьте себе, в приличных местах приличные программы именно что ведут себя прилично.

Разве что libdb4 (Berkeley DB) вспоминается из распространённых неприличных библиотек (у которых между _минорами_ могут меняться нюансы поведения -- в достаточной для того же openldap мере).  Вот такое да, порой таскают с собой в пузе статиком.

> разработчикам следует стараться избегать...
> не уж то надеетесь ? - Представьте себе

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

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

>А как вам удается под форточками иметь проблемы с зависимостями?

А очень просто.
Ставлю софтинку для ТВ тюнера. Инсталляшка запустилась, отработала, отрапортовала, что всё в поряддке. Запукается первичная настройка солфтинки, я эти первичные настройки делаю, сохраняю. Всё в порядке.
А потом запускаю саму софтинку, а мне хлоп, ошибка! И не с текстовым описанием, а просто номер.

Оказалось, что я гад такой не поставил .нет версии 3, а стоит у меня всего на всего версия 1.5

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

В вы спрашивете как нам удаётся иметь в винде проблемы с зависимостями.

Странно, что не Yast-подобный :-) Но и одновременно радует. ИМХО Yast лучше.

Какбэ Яст - это фронтэнд к зипперу.

Чудик, который не видел никогда яста?

В zypper ты настроишь пользователей? настроишь фаервол (пусть и примитивненько), nfs samba серверы?

Управление пакетами - только часть яста. И да - zypper лучше.

а не проще заменить ос и использовать уже готовый менеджер пакетов вместе огромной базой приложений в нём?
опять они изобретают велосипед не с того конца

проще, но не все готовы. И бывает (уже не часто) прикладной софт и (часто) игры только под форточки

>а не проще заменить ос и использовать уже готовый менеджер пакетов вместе
>огромной базой приложений в нём?

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

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

Попробуйте ради разнообразия поставить какойнить эксченж 2007 или что-то такое в этом духе. После того как вас приложат вего то хренадцать раз обломами что не хватает того и этого и вообще, у вас тут "хозяйка - с№%ка, пирог - г#@но" - невольно понимаешь что кто-то из *никсоидов сказавший что иногда проще ввести 2 команды в консоли вместо того чтобы сутки возякать мышкой был чертовски прав на этот счет.

Позволила одному из сотрудников работать в режиме полного рабочего дня... Остальным по-прежнему запрещено не только писать, но и читать GPL-код?

никто никому ничего не запрещает... во внеурочное время.

>никто никому ничего не запрещает... во внеурочное время.

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

>запрещено не только писать, но и читать GPL-код?

А в новости написано что оно под BSDL. Что как бы логично - иначе как же MS сможет зажопить себе результаты чужих потуг?!

Ай, точно... Запутался! Слушай, выше написали, что сменить лицензию нельзя, только сделать закрытый форк. Что, и праводержатель кода не может это сделать? Который один?

В рамках BSDL кто угодно может делать закрытый вариант. До тех пор пока соблюдает пункты лицензии (как то указать аффтаров, etc). Видимо имелось в виду что обратного хода лицензия не имеет  уже выложенный под BSDL код никто не заберет. Так то оно так, но вываленные сорсы это даже не полдела, строго говоря. Побеждает тот у кого РАЗВИТИЕ идет лучше. А проект заткнувшийся в развитии - дохнет, пардон. Тот же Warhead Wardick на самом деле немного лукавит на этот счет. Уж не он ли советовал заменить qmail на что-то еще какому-то чуваку недавно? Это так, пример того как проект с открытой лицензией может "почти умереть". Живой проект - это тот который развивается. И если MS сделает на базе открытого свое, закрытое и в 5 раз лучше - это будет по сути этакий takeover пользовательской базы. Наглый и беспощадный. С подсадкой на проприетарь. И BSDL увы, не исключает таких фортелей.

А ничего что открытый проект CentOS (GPL) плетётся за проприетарным RHEL по сути в хвосте и глубоко вторичен ("ешь что дают с барского стола")?

Ситуация с OpenSolaris (CDDL, в принципе, повторяет GPL на уровне файлов) всё больше скатывается в пользу проприетарного Solaris.

>А ничего что открытый проект CentOS (GPL) плетётся за проприетарным RHEL по
>сути в хвосте и глубоко вторичен ("ешь что дают с барского
>стола")?

Так сама цель проекта - дать тот же RHEL, только без ограничений получения апдейтов. Что же касается вторичности - для кого как. Если тебе официальная поддержка от RHEL не требуется, но нужна платформа с гарантрованной стабильной работой баз данных от Oracle - бери CentOS.
"Ешь что дают с барского стола" - это когда твоей любимой FreeBSD, кидает подачку Juniper в виде порта под MIPS, естественно забыв предоставить rt-patch'и.

>Ситуация с OpenSolaris (CDDL, в принципе, повторяет GPL на уровне файлов) всё
>больше скатывается в пользу проприетарного Solaris.

CDDL тебя имеет?

>>А ничего что открытый проект CentOS (GPL) плетётся за проприетарным RHEL

Ой, объясните уже кто-нить iZEN, что "проприетарный RHEL" -- это трейдмарки, а не лицензия.  Иначе не было бы никакого "открытого CentOS" с вдруг откуда-то взявшейся GPL.

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

Не-а.  "Тот же RHEL" -- это см. историю с unfakeable linux (и ораклом, у которого -- сюрприз! -- тоже нет редхатовской внутренней сборочницы и системы тестирования).  Короче, не-а, не тот же RHEL, а что-то навроде.  И именно из-за _возможности_ бинарной дивергенции и вследствие того отличия в поведении сертификация под RHEL непереносима на пересобранные клоны.

>Ой, объясните уже кто-нить iZEN, что "проприетарный RHEL" -- это трейдмарки, а
>не лицензия.  Иначе не было бы никакого "открытого CentOS" с
>вдруг откуда-то взявшейся GPL.

Бесполезно. У него жесткое неприятие GNU как такового.

>Не-а.  "Тот же RHEL" -- это см. историю с unfakeable linux
>(и ораклом, у которого -- сюрприз! -- тоже нет редхатовской внутренней
>сборочницы и системы тестирования).  Короче, не-а, не тот же RHEL,
>а что-то навроде.

Если не ошибаюсь, ругань возникла из-за выпуска Ораклом своего дистра, основанного на пакетной базе RH. Плюс поддержка дешевле, поэтому, в ответ RH выпустили unfakeable.
По факту-то, тоже самое выходит. Разве что в CentOS так называемые channel'ы
отсутствуют и утилиты вроде rhn_register, ну и shadowman.

> И именно из-за _возможности_ бинарной дивергенции и
>вследствие того отличия в поведении сертификация под RHEL непереносима на пересобранные
>клоны.

Это если умышленно класть на совместимость пакетов, то есть делать свою сборку а-ля Scientific или почившего в бозе Clark Connect.
P.S: Ты мне на вопрос про gear не ответил еще :)

>>Ой, объясните уже кто-нить iZEN
>Бесполезно. У него жесткое неприятие GNU как такового.

Тут дело не в GNU, а в том, что он совершенно мимо кассы со своей классически глупой предъявой.  Подозреваю, что где-то должен быть FAQ для дошкольников, на пальцах, про RH и TM.  Но где -- не знаю.

>P.S: Ты мне на вопрос про gear не ответил еще :)

ratelimit. :)

>А ничего что открытый проект CentOS (GPL) плетётся за проприетарным RHEL по
>сути в хвосте и глубоко вторичен

Он не "плетется в хвосте" а являет собой копию редхата для народа. С выпиленными трейдмарками.

> ("ешь что дают с барского стола")?

Не слишком правдивая и корректная фраза.
1) Некоторые баги из центосины АФАЙК признаются редхатом и чинятся в рамках рхела. То есть, юзеры центоса оказывают какое-то влияние на развитие рхела, хоть и косвенно.
2) Линукс это не сами знаете что. Поэтому если мне не нравится то что дают у редхата - я просто иду и пробую что дают у других. Выбор - есть. От опенврты ориентированной на мелочевку, до дистров ориентированных на огроменные кластера. В отличие от некоторых других.

>Ситуация с OpenSolaris (CDDL, в принципе, повторяет GPL на уровне файлов) всё
>больше скатывается в пользу проприетарного Solaris.

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

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

Один человек на такой проект?! о_О

Такими темпами, через 2-3 года появится новость: "Microsoft решила заменить ядро в ОС Windows с NT 6.x на Linux 2.8.x" =)))))

сначала они откажутся от msi в пользу deb или tar.bz2

Я думаю это будет rpm :)))

И будут  писать уже не "POSIX совместима", a  "POSIX & LSB совместима"!!!

Нам конечно трудно судить с своей колокольни... однако было бы лучше, если Microsoft  вложила денег в "допилку" Wine. Тогда, кто знает - может бы Windows 2020 тогда была на самом деле Linux + Wine + интерфейс аля Vista/Seven""

>Нам конечно трудно судить с своей колокольни... однако было бы лучше, если
>Microsoft  вложила денег в "допилку" Wine.

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

не прошло и 20 лет как до мс дошло что их технологии установки софта - на уровне каменного века :)

>не прошло и 20 лет как до мс дошло что их технологии
>установки софта - на уровне каменного века :)

Пакетный менеджер в винде есть уже довольно давно (я имею ввиду msi), причем он чрезвычайно функциональный и расширяемый, что в сочетании с AD делает его отличным корпоративным инструментом. Чего многие не могут понять, так это разницу между пакетным менеджером и репозитарием. Первое в винде есть давно и вполне себе функционально, а вот второе в исполнении от ms врядли когда-либо появится. А вот 3rd party репозитарии - вполне.

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

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

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

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

>То, что Вы тут описали называется "репозитарий"
>(при помощи пакетного менеджера).

Не совсем.  Это называется "высокоуровневый менеджер ПО, работающий с репозиториями".  Под которым остаётся low-level что-нибудь вроде rpm/librpm или dpkg, которое понимает пакеты и зависимости, но не умеет автоматически разрешать последние.

Ну и замшелые сведения отдельных деятелей насчёт "dll hell в линуксе", которое некоторые иные деятели называли ещё "rpm hell" -- относятся ровно к тому, когда в Red Hat Linux зависимостями занимался только инсталятор, а в рантайме был только rpm.  Хотя IMHO и это было лучше, чем на винде -- потому как зависимости всё-таки формализованные и разрешимые в рамках полного пакетного набора дистрибутива для всего, что в нём либо совместимо с ним.

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

>>не прошло и 20 лет как до мс дошло что их технологии
>>установки софта - на уровне каменного века :)
>Пакетный менеджер в винде есть уже довольно давно (я имею ввиду msi),
>причем он чрезвычайно функциональный и расширяемый, что в сочетании с AD
>делает его отличным корпоративным инструментом.

Когда там у нас rpm и deb появились -- в 1992 или 1993?  Вот примерно этому каменному веку (ну чуть позже пусть, RPMv3) и соответствует.

Вы совершенно верно сказали насчёт разницы между отдельно взятым пакетом и репозиторием с согласованным набором предоставляемых и требуемых интерфейсов.  И такое в _проприетарном_ мире тупо не светит.  А если светит, то в ограниченном варианте а-ля apple store.  Что MS не светит уже по другим историческим причинам -- они привыкли ограничивать других, но не себя.

Ну и подобного тоже не жди:
http://lists.altlinux.org/pipermail/sisyphus-cybertalk/2010-...

Интересно, а нет ли патента на такой способ установки?

Будет! (с) MS

Я вот единственного не пойму, почему маздайцы до сих пор свой дистриб не выпустил.

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

Мда, инновационный Microsoft такой инновационный;
неужели ~10 лет спустя инженеры компании поняли, что пакетная система с автоматическим разрешением зависимостей и автоматизацией сборки рулит и педалит (даже если бинарник делается из проприетарного кода)? И что лучше сделать
> [apt|yum] install $package

чем Next -> Next -> Next -> Finish (см. для пущей иллюстрации установки софта в самой "дружественной" проприетарной операционной системе для домохозяек - http://www.psychocats.net/ubuntucat/software-installation-in.../ )?
"На третий день Орлиный Глаз..."
Глядишь, пройдёт ещё пару лет, так они это ещё и запатентуют, и будут громче всех кричать, что это они придумали, ибо инновации же! (прецеденты были - вспомнить хотя бы недавний случай с патентованием sudo-подобного метода).
Ну а то, что проект на ланчпаде хостится - это вообще финиш.
А как же их любимый инновационный CodePlex, и никем так активно не пропагандируемый принцип, кроме как среди проприетарщиков, про "есть еду своей собаки"?
А, ну да, в этом их CodePlex'е же ни поддержки нормальной системы контроля версий, ни адекватного баг-трекера с привязкой к проекту и интеграцией в дистрибутив через отдельный механизм [apport] для автоматического генерирования отчётов об ошибках, ни сборочной системы пакетов с репозиториями для автоматической доставки собранных пакетов пользователям.

>Мда, инновационный Microsoft такой инновационный;
>неужели ~10 лет спустя инженеры компании поняли, что пакетная система с автоматическим
>разрешением зависимостей и автоматизацией сборки рулит и педалит

1. в нормально написанных программах разрешать ничего не надо - все с собой, а в идеале в одном package. dll-hell подобные проблемы пусть остаются в линуксах

Ну-ну, и потому мелкая программка с 100кб ехешником имеет инсталляху в 50 мегабайт, ибо тянет с собой .dll-ки, которых и без того в системе вагон.

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

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

не забудем

и не забдь остановить приложение её использующее.
ах да! винда и сама любезно об этом сообщит. :D

>и не забдь остановить приложение её использующее.
>ах да! винда и сама любезно об этом сообщит. :D

зачем? моя софтина например при обновлении не останавливает свою работу а перегружает dll на лету, причем обновиться может все!

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

>не одним клиентом, а парой десятков. угу.

У них это не практикуется - каждый козел волочит в систему 100500 мегов СВОИХ СОБСТВЕННЫХ длл, блин. Даже если в системе уже есть 23 копии нужной проге либы, она об этом никак не узнает и вкорячит свою, 24-ю. Потом 24 копии дружно выжрут RAM 24 раза и займут в 24 раза больше места на диске, но разве ж MS колебет что-то кроме набития своего кармана? Такое бывает только для системных длл. И именно потому патчи только раз в месяц. Иначе юзеры задолбутся ребутиться!

>Потом 24 копии дружно выжрут RAM 24 раза и займут в 24 раза больше места на диске

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

В принципе, можно по требованию запускаемых приложений dll необходимых версий оперативно подгружать в %SystemRoot%\System32 в dllcache из сетевых репозиториев, чтобы имена библиотек разных версий не совпадали, но обеспечивали готовность запуска пользовательских приложений. При этом сами приложения будут оставаться небольшими по размеру.

Например, локальный репозиторий Apache Maven разворачивается во вменяемую каталожную структуру с человечными правилами задания версий, чем отличается от "анонимных" библиотек в dllcache, но работает по сути так же.

>Открой для себя технику файлового отображения в память.

открыл.
понял что это до тех пор пока дллка не начнёт заполнять свои структуры своими же данными.
закрыл.

зы:
и да. это всё-равно не позволит обновить дллку, если она используется.

>Открой для себя технику файлового отображения в память.

А о нем давно в курсе, так что продолжите вашу мысль. Что будет если его поюзать? В данный момент проги таскают РАЗНЫЕ версии и подвиды либ. Кого и куда планируется отобразить? И что это даст? В теории что-то типа Kernel Same Page Merging мог бы частично ответить на эту проблему, но пока MS аналог оного реализует - рак на горе свистнет. Да и дыры собссно оно не починит нифига ;). В общем инноваторы из MS - такие инноваторы...

>В принципе, можно по требованию запускаемых приложений dll необходимых версий оперативно
>подгружать в %SystemRoot%\System32 в dllcache из сетевых репозиториев,
>чтобы имена библиотек разных версий не совпадали, но обеспечивали готовность запуска
>пользовательских приложений.

А это... если я попробую запустить прогу при упавшем интернете - я сосану, да? А если интернет медленный, я буду полдня ждать старта программы которая вроде как была установлена? Замечательная система! Специально для лузеров? :).Какое счастье что iZENы не дизайнят операционки.

>При этом сами приложения будут оставаться небольшими по размеру.

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

>чем отличается от "анонимных" библиотек в dllcache, но
>работает по сути так же.

Вообще у MS еще с времен Win3.x есть пара вызовов апи (VerCheckFile и VerInstallFile или как их там правильно). Но сделано было через жо, результатом стал срач в системную диру и ломка одними прогами других программ и в целом затея shared юзежа shared либ в реализации MS эпично зафэйлилась и програмеры остались 1 на 1 с тем что называется DLL hell, а MS попросту устранился от решения проблемы предоставив ALL выгребать как умеют самим. И даже если опенсорцный софт сможет запрашивать либы, остальной то все-равно будет таскать либы хрен знает откуда. А значит в системе 1 фиг будет срач из кучи копий либ похожих по смыслу и незапатченных вовремя.

>А это... если я попробую запустить прогу при упавшем интернете - я
>сосану, да?

Если программа не подгрузила все свои модули и библиотеки — да, останешься с носом.
Java-приложения ещё в 1995 году умели работать ДО подгрузки всех своих .class файлов, а C/C++ приложения до сих пор обходятся явным или динамическим связыванием библиотек при старте приложения, то есть зачатки есть, но до конца работать на автомате не научились, поэтому требуются всякие там менеджеры пакетов, разруливающие зависимости и т.д..

>А если интернет медленный, я буду полдня ждать старта
>программы которая вроде как была установлена? Замечательная система! Специально для лузеров?

Да, для таких как ты.

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

>:).Какое счастье что iZENы не дизайнят операционки.

Если б я сейчас дизайнил операционки, я бы делал всё правильно с самого начала, а не опирался бы на костыли ЯП тридцатилетней давности.

>а C/C++ приложения до сих пор обходятся явным или динамическим
>связыванием библиотек при старте приложения, то есть зачатки есть, но до
>конца работать на автомате не научились, поэтому требуются всякие там менеджеры
>пакетов, разруливающие зависимости и т.д..

Почитайте про dlopen(3), что ли.  Подумайте про загрузку модулей ядра.

>>:).Какое счастье что iZENы не дизайнят операционки.
>Если б я сейчас дизайнил операционки, я бы делал всё правильно

Сначала букварь, пожалуйста.  R, не W.

>>Потом 24 копии дружно выжрут RAM 24 раза и займут в 24 раза больше места на диске
>Открой для себя технику файлового отображения в память.

Вы, может, хотели в другую сторону кивнуть -- на специально обученный искать дупы код?
Чтоб экономить на ммапе, надо ммапить _заведомо_ одно и то же.
А теперь ещё раз перечитайте слово _копии_.

PS: а код такой есть для линукса, и что-то не слышу для винды, макоси, не говоря о *bsd.

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

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

>А теперь ещё раз перечитайте слово _копии_.

Вы тоже перечитайте.

>PS: а код такой есть для линукса, и что-то не слышу для
>винды, макоси, не говоря о *bsd.

Специально для вас: http://www.freebsd.org/cgi/man.cgi?query=mmap&apropos=0&sekt...

mmap(2) входит в состав libc.

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

А теперь хором задумываемся: какой-такой волшебный дисковый кэш знает про то, что КОПИИ ФАЙЛОВ вообще-то идентичны? (второй день пытаюсь объяснить, дойдёт или всё операционки дизайните?)

Речь ведь шла о нескольких копиях файлов с библиотеками.  Не хард|симлинках, а копиях.

>>PS: а код такой есть для линукса, и что-то не слышу для
>>винды, макоси, не говоря о *bsd.
>Специально для вас: [...] mmap(2) входит в состав libc.

Да куда ж unix-like без mmap, который SVR4.  Я про KSM говорил насчёт искалки дупов, если так и не дошло.

Скажите честно -- просто проморгали суть слова "копия файла" и дальше по тексту, или действительно совсем-совсем не понимаете ничего в VM, даже на уровне ядерного профана вроде меня?

>Речь ведь шла о нескольких копиях файлов с библиотеками.  Не хард|симлинках,
>а копиях.

"Копии" — это те, которые отличаются друг от друга? Или те, которые всё-таки одинаковы? :))

(Я просто думал и думаю, что копии всегда идентичны.)

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

Не надо додумывать что-то за меня и приписывать это мне же.

>>>Чтоб экономить на ммапе, надо ммапить _заведомо_ одно и то же.
>>Нет. При мапинге просто не производится лишняя пребуферизация, а данные и код
>>приложение сразу берёт из дискового кэша.
>
>А теперь хором задумываемся: какой-такой волшебный дисковый кэш знает про то, что
>КОПИИ ФАЙЛОВ вообще-то идентичны? (второй день пытаюсь объяснить, дойдёт или всё
>операционки дизайните?)

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

>>Речь ведь шла о нескольких копиях файлов с библиотеками.
>"Копии" — это те, которые отличаются друг от друга? Или те, которые
>всё-таки одинаковы? :))

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

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

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

Если интересно, то http://lwn.net/Articles/306704/ и http://lwn.net/Articles/330589/

>>>>Чтоб экономить на ммапе, надо ммапить _заведомо_ одно и то же.
>>>Нет. При мапинге просто не производится лишняя пребуферизация, а данные и код
>>>приложение сразу берёт из дискового кэша.
>>А теперь хором задумываемся: какой-такой волшебный дисковый кэш знает про то, что
>>КОПИИ ФАЙЛОВ вообще-то идентичны? (второй день пытаюсь объяснить, дойдёт или всё
>>операционки дизайните?)
>Не надо хором задумываться.

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

>Нужно просто прочитать как работает отображение файлов в
>память и всё сразу станет ясно.

Уф.

cp /lib/libz.so.1.2.3 /usr/local/lib/

Если $? == 0, то получены две копии файла, имеющие идентичное содержимое.

Теперь ммапим /lib/libz.so.1.2.3 в адресное пространство одного слинкованного с zlib процесса, а /usr/local/lib/libz.so.1.2.3 -- к другому (про LD_LIBRARY_PATH рассказывать не требуется, надеюсь).

Вы действительно утверждаете, что обычный mmap() неким образом догадается о том, что странички из одинаковых по содержанию файлов на самом деле одинаковы -- и что каждой такой странички получится по одной штуке с увеличенным ещё на единичку refcount'ом, а не "одна из /lib, одна из /usr/local/lib"?

>[оверквотинг удален]
>Которые имеют идентичное содержание, являясь логически отдельными объектами.
>
>>>>>>Открой для себя технику файлового отображения в память.
>>>>>Вы, может, хотели в другую сторону кивнуть -- на специально обученный искать
>>>>>дупы код?
>>Не надо додумывать что-то за меня и приписывать это мне же.
>
>Да я пытаюсь хоть какой-то здравый смысл найти в том, что несёте...
>не надо так не надо.
>

% ls /dev/ksm
ls: /dev/ksm: No such file or directory
% uname -rsm
FreeBSD 8.0-STABLE amd64

>Если интересно, то http://lwn.net/Articles/306704/ и http://lwn.net/Articles/330589/

Да-да. Это такой костыль в Linux, от которого в FreeBSD отказались. В FreeBSD кэш файловой системы был объединён с кэшем виртуальной памяти, и вся доступная системная память МОЖЕТ быть выделена для кэширования данных файловой системы.

>Вы действительно утверждаете, что обычный mmap() неким образом догадается о том, что
>странички из одинаковых по содержанию файлов на самом деле одинаковы --
>и что каждой такой странички получится по одной штуке с увеличенным
>ещё на единичку refcount'ом, а не "одна из /lib, одна из
>/usr/local/lib"?

Я этого не утверждал. Не надо за меня что-то додумывать. mmap() не "объединяет" в одну структуру данные разных файлов (даже если они бинарно идентичны). vnode у файлов разные.
Другое дело, что поскольку кэш унифицирован (для ФС и виртуальной памяти), а оперативная память сейчас очень дёшева, не надо заморачиваться на отслеживании полностью идентичных файлов, подгруженных разными приложениями (их просто нет), зато на уровне ФС (такой, как ZFS) можно идентифицировать одинаковые блоки данных и предоставлять их операционной системе для мапинга в адресные пространства приложений.

>% ls /dev/ksm
>ls: /dev/ksm: No such file or directory

И эти люди сейчас расскажут нам за ZFS-ы!? :-P

>% uname -rsm
>FreeBSD 8.0-STABLE amd64

>>не надо так не надо.
>% ls /dev/ksm
>ls: /dev/ksm: No such file or directory

На этот случай там выше было:
>>>>>>PS: а код такой есть для линукса, и что-то не слышу для
>>>>>>винды, макоси, не говоря о *bsd.
>>Если интересно, то http://lwn.net/Articles/306704/ и http://lwn.net/Articles/330589/
>Да-да. Это такой костыль в Linux, от которого в FreeBSD отказались.

Так и записываем -- "в FreeBSD слили".  Ровно как и раньше с журналированием.  Раз уж старались проиллюстрировать -- ну ладно, спасибо.

>В FreeBSD кэш файловой системы был объединён с кэшем виртуальной памяти, и
>вся доступная системная память МОЖЕТ быть выделена для кэширования данных файловой
>системы.

А это к чему было?

>Я этого не утверждал.

(откладывая клещи в сторону) Уже хорошо.

>Не надо за меня что-то додумывать.

Тогда будьте добры, выражайтесь внятно, раз уж берёте на себя труд говорить с другими.

>mmap() не "объединяет" в одну структуру данные разных файлов (даже если они бинарно
>идентичны). vnode у файлов разные.

Вот.

>Другое дело, что поскольку кэш унифицирован (для ФС и виртуальной памяти), а
>оперативная память сейчас очень дёшева

Вот!

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

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

>зато на уровне ФС (такой, как ZFS) можно идентифицировать одинаковые блоки данных
>и предоставлять их операционной системе для мапинга в адресные пространства приложений.

Это подход к той же проблеме с другой стороны и менее универсальный (хотя и по-своему оправданный).

Для начала он ограничен тем, что _ммапнуто_ из _известного_ ядру как "одного" файла, а не оказалось одинаковым в памяти разных виртуальных окружений, происходя из N зашифрованных ФС на разных блокдевайсах через iSCSI (или там у сотни пользователей на терминальном сервере картинка корпоративного лого на корпоративном интранете).  Когда засунуть в одну файловую систему ну никакой возможности нет.  Тот же KSM ориентируется в первую очередь на такие варианты использования.

Ну и можете предложить VMware, Inc самораспуститься, потому как они схожее сделали и работает, а "в FreeBSD отказались". :)  Или всё-таки успокоиться, взять себя в руки и признать, что погорячились.

мс на дворе.
поэтому г.. барахла должно быть МНОГО! :D

апи чего?

зы:
задрали уже чудики про драйвер апи орать.
вы лично сколько драйверов под линух написали?

> какие 50 мегабайт

такие, что 640 килобайт должно хватить всем.

>какие 50 мегабайт... опомнитесь, 2010 год на дворе

Действительно. "Серьезная программа" под винду весит не менее сидюка. Чтобы юзер по двум часам инсталляции и засранному в хлам винту понимал что купил не какую-то левую студенческую поделку а правильную программу от реальных пацанов :)

Да что вы говорите, у меня вот в 2010 году инет 200к.бит/сек, мне что проще скачать программу в 15 мегабайт или в 400? Ах да, за ту которая 400 весит нужно платить(ну или как у нас в стране делается, искать способ обхода защиты) Дебиан это примерно 5 двд, это 5*4.7 = 23 гига примерно софта на все случаи жизни. А теперь возьмём размер папки с дистрибутивами среднего пользователя винды? 40? 80? 150гб? И это ещё не предел.

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

Много в винде прог с графическим интерфейсом, несколькими диалоговыми окнами, чтобы она ещё и с БД умела работать и из сетки чего-то тянуть и чтоб при этом дистриб был 100-200 кб? И в памяти чтобы не больше занимала....

2010 год - не повод не экономить память, мне не охота покупать новое железо, только потому, что кто-то до сих пор вин-апт не придумал-)

>Красивый апт можно сделать в винде.

Да. (с ударением на первом слове)

>Когда разработчик будет точно знать, что вот эту либу
>ему пихать в прогу не надо, достаточно указать её
>в зависимостях и она будет у конечного пользователя.

Нет, насколько могу судить.

>2010 год - не повод не экономить память, мне не охота покупать
>новое железо, только потому, что кто-то до сих пор вин-апт не
>придумал-)

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

>Ну-ну, и потому мелкая программка с 100кб ехешником имеет инсталляху в 50
>мегабайт, ибо тянет с собой .dll-ки, которых и без того в
>системе вагон.

Шутить изволите

Это одна и та же прога

http://sourceforge.net/projects/lazarus/files/

windows
lazarus-0.9.28.2-fpc-2.2.4-win32.exe
(64.6 MB)

linux (а еще понадобятся всякие gtk-develи т.п.)
Lazarus 0.9.28.2
(147.7 MB)

Мозг врубите: в винде каждая прога волочит свои копии либ. В линухе 1 копия либ ставится для всех и все проги ее могут юзать. В итоге в винде творится эпичный бардак из shared либ которые совсем не shared и к тому же вопросы обновления оных никого не долбут, так что ессно секурити идет на хутор бабочек ловит а юзер выгребает малварь из системы влезшую через дыры в всем этом необновленном дерьмище.

>Мозг врубите: в винде каждая прога волочит свои копии либ.

А кто вам такую чушь сказал? Не мне просто интересно. Кто? Не волочит, а может волочить. И это + а не -. Т.к. если проблемы то нужную либу скопировал и все. Нет больше проблем.

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

>>Мозг врубите: в винде каждая прога волочит свои копии либ.
>А кто вам такую чушь сказал? Не мне просто интересно. Кто?

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

>Не волочит, а может волочить.

Как минимум половине программ явно нужен как минимум какойнить там zlib, а еще четверти - какойнить libpng. Просто поищите по типичному виндозному харду типичного юзеря сколько раз там найдется копирайт стандартных функций inflate/deflate из zlib которые вполне просто найти (там где про Mark Adler). Тут вам и 100500 копий статически влинкованных в бинари, и куча разных инкарнаций zlib-овской длли припертой всеми кому не лень, и прочая.

>И это + а не -.

Это большой засер. Нереалистичный для администрежа и поддержки секурити системы но зато очень удобный для хаксоров. Огреть приложение сплойтом просто впарив ему в потоке протокольных данных сплойт для его древнючей либы компрессии или просто подсунув specially crafted file (zip, tgz, png, ... - в общем все которые юзают deflate) вместо ожидаемых данных - да, хаксоры это любят. А потом начинается искреннее удивление: как это так, ничего не делал, а у меня троянец в системе?!

>Т.к. если проблемы то нужную либу скопировал и все. Нет больше проблем.

Проблемы начинаются когда в либе нашли дыру. В линухах обновляется 1 мелкий пакетик с либой и готово - все проги неуязвимы для сплойтов. В виндозе - надо заменить over 9000 копий либы, включая статически влинкованные (интнресно каким хреном?). Далее - все сугубо на совести юзера что он допрет обновить все over 9000 программ юзавших zlib и на совести авторов этих программ что они допрут обновить злибу в их программе. Ну вот например, есть у меня диск с HMM-IV. Злиба архаичной версии там статически вхреначена. И как мне ее там обновлять, интересно? Никак? Ну вот то-то же. В итоге винда является свалкой дырявых программ и библиотек за которыми никто не следит. Понятно откуда в итоге валится спам и почему это именно так.

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

А что такое "инсталляшка для линя"? Я выбираю в манагере пакетов "скачать мне вон то" и пакетный манагер качает мне только то чего у меня еще нет. Посему скажем есть кутевая прога на полмега. При установке в лине я качаю полмега проги а кутя юзается та которая уже установлена. В винде... в винде мы качаем и прогу на 500 кило и кутю к ней на еще 10 мегов. Поскольку штатного метода запросить у системы кутю или узнать что кутя уже притащена другой прогой попросту нету. Упомянутая тулза частично решит сии грабли но опять же - это полумеры и костыли. До конца проблема не решится а у юзера будет засер из нескольких систем управления барахлом и управлением компонентами.

> Или у линуксоидов вообще полный разрыв с реальностью?

FYI, я юзал винды начиная с '95, если что. И даже MSDOS. А линухи всего года 4 всерьез и по полной. Просто все познается в сравнении...

>именно с инсталляцией там хуже всего. А линуксоиды счастливы. Ну что
>тут скажешь?

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

>http://sourceforge.net/projects/lazarus/files/
>
>windows
>lazarus-0.9.28.2-fpc-2.2.4-win32.exe
>(64.6 MB)
>
>linux (а еще понадобятся всякие gtk-develи т.п.)
>Lazarus 0.9.28.2
>(147.7 MB)

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

42 340,6 Кб версия 0.9.28.2-8 в моём дистрибутиве, а Вы попробуйте собрать из исходников в винде, вот веселуха будет=)))

Ну ну, не будем на основании одного не полного примера делать выводы. Но давайте посмотрим как это будет выглядеть в случае упаковки всего этого хозяйства в deb и при раскладке по нормальному репозиторию (в случае rpm тоже будет что то подобное):
Пакет;      Архитектура;      Размер пакета;      В установленном виде
lazarus;      all;          15,5 Кб;    68 Кб
lazarus-doc;     all;          1 771,7 Кб;    67260 Кб
lazarus-ide;     i386;          42 340,6 Кб;    195212 Кб
lazarus-ide-qt4;i386;          15,7 Кб;     76 Кб
lazarus-src;     all;          9 584,8 Кб;    68588 Кб

И что мы тут видим, а видим мы тут несколько пакетов, у которых есть зависимости, и Вы скорее всего не поверите в то что все эти зависимости будут подтянуты автоматически в момент установки целевого пакета.
И это, в сумме то посчитайте, сколько набор пакетов то будет весить, без исходников он будет весить 44143,5 Kb, ну и ещё исходники для самостоятельной сборки на месте можно забрать отдельным пакетом, который кстати при сборке сам расскажет чего ему для полного счастья не хватает, для этого надо всего то сказать (в случае с deb) dpkg-checkbuilddeps, и приложить его ответ своему пакетному менеджеру (apt например), что ба он подсуетился.

> в нормально написанных программах разрешать ничего не надо - все с собой, а в идеале в одном package

50 версий Qt и 15 GTK это типа круто? Запустишь 50 разных программ использующих Qt и у тебя будет 50 версий Qt в памяти, это тоже так и задумывалось Microsoft? Оригинальное понимание понятия «разделяемые/общие библиотеки», настоящий Microsoft way :)

> в нормально написанных программах разрешать ничего не надо - все с собой, а в идеале в одном package.

Главное что бы лицензия того что Вы пихаете в свой package со своей программой это позволяла, а то представляете что получится, под Linux программу можно установить, а под windows — никак, потому что используемая утилита1 запрещает своё распространение внутри чужого пакета :)

>>Мда, инновационный Microsoft такой инновационный;
>>неужели ~10 лет спустя инженеры компании поняли, что пакетная система с автоматическим
>>разрешением зависимостей и автоматизацией сборки рулит и педалит
>
>1. в нормально написанных программах разрешать ничего не надо - все с
>собой, а в идеале в одном package. dll-hell подобные проблемы пусть
>остаются в линуксах

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

> 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?

Трухин, ты просто жалок.

> dll-hell подобные проблемы пусть остаются в линуксах

Ох, лол. Ты вообще в курсе, почему оно называется dll hell, а не so hell? В линуксе таких проблем нет и быть не может.

>> dll-hell подобные проблемы пусть остаются в линуксах
>
>Ох, лол. Ты вообще в курсе, почему оно называется dll hell, а
>не so hell? В линуксе таких проблем нет и быть не
>может.

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

То, что Майкрософт Windows является аналогом _unstable _developer репозитария дистрибутива GNU/Linux -- это официальная точка зрения Корпорации, или Вы сболтнули, не подумавши?

Когда _стабильный релиз? %)

> *альтлинукс* обновляешь из *сизифа*, *моно* например ставишь,

казалось бы, причём здесь установка (криво собранных, как оказывается) пакетов, реализующих сторонние технологии Microsoft, стороннюю реализацию кототорых (mono) сама Microsoft официально не признаёт, из официально признанного разработчиком (AltLinux) нестабильного и рекомендуемого исключительно для тестирования репозитория (сизиф), *и* архитектурный исторический былинной эпичности просчёт, который, например, не позволял без лишних телодвижений разработчика-пользователя установить в одной операционной системе семейства Windows (tm) корпорации Microsoft (R) две разные версии одной и той же динамической библиотеки?

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

Если будет конкретика -- милости просим в https://lists.altlinux.org/mailman/listinfo/sisyphus

А если нет -- то на всякий поясняю: ALT Linux Sisyphus, Debian unstable, Rawhide и куча других _нестабильных_ разработческих репозиториев НЕ ПРЕДНАЗНАЧЕНЫ для неопытных пользователей и имеют полное право взрываться как угодно (хоть и обычно им не злоупотребляют).

Эт примерно как я возьму какую-нить пререлизную сборку винды и буду по ней судить.

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

> dll-hell подобные проблемы пусть остаются в линуксах

Молодец, на ноль поделил.

http://ru.wikipedia.org/wiki/Dll_hell
DLL hell (DLL-кошмар, буквально: DLL-ад) — тупиковая ситуация, связанная с управлением динамическими библиотеками DLL в операционной системе Microsoft Windows.

>1. в нормально написанных программах разрешать ничего не надо - все с
>собой, а в идеале в одном package. dll-hell подобные проблемы пусть
>остаются в линуксах

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

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

PS: и будьте добры, зарубите на носу -- со своим DLL hell в чужой RPM based не ходят.

А СЕЙЧАС НАМ МИША РАССКАЖЕТ, КАКИЕ ПОПУЛЯРНЫЕ ЛИНУКС ДИСТРИБУТИВЫ ИСПОЛЬЗУЮТ XDELTA

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

>А СЕЙЧАС НАМ МИША РАССКАЖЕТ, КАКИЕ ПОПУЛЯРНЫЕ ЛИНУКС ДИСТРИБУТИВЫ ИСПОЛЬЗУЮТ XDELTA

Например, openSUSE (откуда patch rpms и пошли, ЕМНИП) или более-менее свежая федора.  В альте нет и пока не предвидится, если Вы именно это хотели услышать.

>Пишу капсом, чтобы у мишы был формальный повод удалить неудобный вопрос.

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

>1. в нормально написанных программах разрешать ничего не надо - все с собой, а в идеале в одном package. dll-hell подобные проблемы пусть остаются в линуксах

Это точно. По такому пути пошли разработчики пакетной системы PC-BSD (pbiDIR.com).

>>1. в нормально написанных программах разрешать ничего не надо - все с собой,
>>а в идеале в одном package. dll-hell подобные проблемы пусть остаются в линуксах
>Это точно. По такому пути пошли разработчики пакетной системы PC-BSD (pbiDIR.com).

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

Просто до кучи -- малолетние слакваристы тоже выбирают этот путь ("проект родлинукс" вон всё статиком предлагал линковать).  И ещё досовые программульки таскали с собой или в себе библиотечки-драйверки.

Смех сквозь слёзы... пошли -- ну туда и дорога им всем.  В смысле когда "это правильный _основной_ путь" вместо предоставления вменяемого API операционной среды.  В качестве исключения для сильно запущенных случаев этот подход может быть приемлем, см. тж. http://lwn.net/Articles/378865/ с разбором полётов на примере xulrunner.  Только вот софт, который так делает, сам в итоге не годится в качестве хорошего реюзабельного компонента -- и это там тоже разобрано.

PS: на макось кивать не стоит: очень интересно, как они собираются выкручиваться из своей традиционной ниши небольшого разнообразия железа и софта.  Многие подходы, применяемые там (и в том числе бандлы dmg) -- завязаны на концепцию, IMHO непригодную для универсальной ОС -- проблемы которой они избегают искусственным сужением области применимости.

>Это точно. По такому пути пошли разработчики пакетной системы PC-BSD (pbiDIR.com).

Верной дорогой идут - таким методом можно получить то же самое что есть в винде. В плане вирусов, малвари, уязвимостей и прочая, разумеется. Микрософтовские супердупер технологии инсталла катили где-то в начале девяностых, но ближе к 2010-ым начали безжалостно буксовать. Даже сам MS похоже уже начинает понимать что их инсталлер - просто напросто обычное окаменелое Д**МО! Тормозное, капризное, ломкое, ничерта не умеющее и дико геморройное для тех кто создает сетапы, поскольку все и вся свалено на них по принципу "выруливайте как умеете". Ну вот и выруливают как умеют - да, поскольку нет централизованных репов, каждые софтварщики тянут с собой свой сидюк барахла а львиная доля либ - ни разу не shared в итоге. Shared в каком-то понимании являются только либы оформленные как редистрибутаблы от микрософт. А если кому нужна какая-то еще либа - все, сливай вода, туши фонарь.

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

>Как всегда M$ - не они будут если не распиарят себя по малейшему поводу.

Одного не пойму -- что эта новость забыла на главной.

>>Как всегда M$ - не они будут если не распиарят себя по малейшему поводу.
>Одного не пойму -- что эта новость забыла на главной.

Как в том детском мультике про ?слона -- МС теперь [уже вот-вот!!] самый БОЛЬШОООЙ другх опенсорса. Только на главную!.

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

А время, сестра! Время!
Или "часы" и "клики" это уже нечто равноценное? :)

acute NIH case

товарищ походу /usr/ports изобретает

Shallow-Fork
Source Repository
    A source code repository using appropriate version control software, that is used to maintain 'shallow-forks' --forked versions of open source projects, which are used to optimize Windows development.  If the original project chooses to support CoApp-style tools and development, these changes can be pushed back up to the project. In practice however, we know that some projects will not bother (they don't care about Windows support)

такой проект уже сущестует и работает

http://code.google.com/p/apt-cyg/

сначало прочитал заголовок, и ПОРАДОВАЛСЯ (за нащих братьев меньших) :-) :-)..

...потом начал читать подробности и просто АФИГЕЛ (от их тупо-каменно-головости):

> Имеет дружелюбный к Windows-разработчику интерфейс - вместо Unix-команды сборки make можно продолжать использовать свою любимую среду разработки (IDE);

- какой ещё мой любимый IDE ?
- мой любимый IDE -- ПРЕДПОЛОГАЕТ что нада использовать -- {консоль+unix_команды} (make, ...) . и это ОЧЕНЬ даже дружелюбно, в отличии от "next,next,next,...,oops!sorry..."
- что они имею ввиду вообще?

> Отсутствие привычной среды сборки и разработки (autotools, bash и т.п.);

- тоесть теперь в CoApp -- они появяться? (autotools, bash и т.п.)
- но об этом в новости намекается -- что вроде как НЕТ %) %)..

...но ведь:
> Разработчики Microsoft представили проект CoApp, в рамках которого начата разработка универсальной Windows-среды для доставки, компиляции и создания пакетов из Open Source приложений...
>>>компиляции<<<

хм... так чтожеони имели ввиду? %) %)

> Позволяет собирать приложения для Windows пользователям, не имеющих навыков разработчика;

- КТОООО? ВОТ ЭТИ ВОТ пользователи Windows буду собирать приложения? :-D :-D
- да не каждый разработчик (разработчик СПО) может собрать приложение под Windows (и поэтому скачивает для windows готовые *.exe (вместо *.tar.gz) , если вдруг понадобилось поработать на Windows) , а они уже наметили на обычных пользотелей!
- дык КАКЖЕ без {bash,make,gcc,...} они буду собирать приложения? бред какойто...

--------------------

в итоге единственное адекватное что я понял из новости -- Microsoft говорит что ".msi -- это чтото типа ваших .deb , поэтому мы ТОЖЕ ТРУЪ-Фри-Опен-Сурс"...
и... "спрашивайте у ваших любимых СПО-разработчиков -- MSI-пакеты любимых программ" :-)
(по аналогии с -- "смотрите наш фильм во всех кинатеатрах страны")

> Позволяет собирать приложения для Windows пользователям, не имеющих навыков разработчика;

за это мс - 5++!!!

потрясающе!!! наконец свершилось чуда,  Windows пользователи все разом рвут компилировать kerlnel32.dll !!!

emerge для винды вроде как уже был. Изобретают велосипед?

Обычно я администрирую FreeBSD.
20 минут в серверной у провайдера до того момента как поднимется ssh.
Всё остальное дома, в кресле с котом на коленях и чаем на столе.

но вот недавно пришлось ставить на сервер Win 2003 server.
Лицензионный диск у клиента даже без SP2. Не смотря на наличие купленной лицензии, новый диск с сервиспаками и апдейтами Microsoft не распространяет.

Однако, пока не накатишь апдейты - нельзя открывать порты на доступ снаружи т.к. сервер за 20 мин. забивается вирусами (был опыт). Значит весь процесс надо торчать рядом с серваком.

Это был ужас. 8 часов рядом со стойкой под кондиционером +10 град. (На улице было +35. Представляете как я был одет. Хорошо что не в шортах). В конце этого действа у меня не гнулись ни пальцы ни спина.

Жмешь кнопку "апдейтить всё". Затем загрузка, установка, рестарт, снова ввожу пароль администратора. Снова в броузере выбираю "апдейтить всё" и так по кругу.

При этом все апдейты довольно жирные. Это не дифы. Это полные дистрибутивы компонент системы. По моим подсчетам было выкачано 2-3 Гб.

Каменный век.

Поэтому, у нашей компании дорогой сетап Виндов. Приходится оплачивать полную смену системного адвминистратора.

Cool story, bro.
Я серьёзно - прочитал с интересом и улыбкой. Поучительно :-)

>Cool story, bro.
>Я серьёзно - прочитал с интересом и улыбкой. Поучительно :-)

А йа вот накатываю всё в оффисе, с коффеем и секретаршами :) А потом высылаю готовый сервак в data-cent[e]r[e] с инструкцией какие кабеля куда втыкать. Но это скучнее, да :)

круто, в office + java сервак накатать...

>А йа вот накатываю всё в оффисе, с коффеем и секретаршами :)
>А потом высылаю готовый сервак в data-cent[e]r[e] с инструкцией какие кабеля
>куда втыкать. Но это скучнее, да :)

У меня сервак стоял в стойке в датацентре. Один клиент ушел. Другой пришел.
Не потащишь же сервак обратно в офис. 70 км. Половина по пробкам.

Другое прикольно. 8 ядер, железный RAID и интернет 500Мбит/сек не привели хоть к какому-то ускорению установки.

Интересный рассказ.

10 градусов - хорошая серверная, челябинская)
Насколько я знаю, обычно держат температуру 18-19 градусов.

>Однако, пока не накатишь апдейты - нельзя открывать порты на доступ снаружи
>т.к. сервер за 20 мин. забивается вирусами (был опыт). Значит весь
>процесс надо торчать рядом с серваком.

Шож вы за порты такие открывали, если не секрет?)
Могу порекомендовать пару вещей:
- vnc/radmin/что_там_ещё на нестандартный порт + пароль посложнее = успеете накатить все апдейты из дома.
- есть порт ipfw для винды - wipfw. Даже таблицы есть. Думаю, полезность понимаете =) Можно ограничить трафик до домашнего ip адреса.

> Шож вы за порты такие открывали, если не секрет?)

Все порты. Взял у клиента оригинальный диск Win 2003 standard. Руками установил драйвера (на моей память мастер драйверов не нашел автоматически ни одного драйвера). Разрешил доступ через Remote Desktop. Поехал в офис.

Оказалость, что это старый диск. Без SP2. Значит без фаервола вообще. Все порты открыты. А количество уязвимостей так велико, что если фаерволом не заткнуть - вирусы спокойно проникают в систему без всякой авторизации. Дикость.

Когда я ставлю FreeBSD всего этого не нужно.
Свежий дистрибутив лежит на сайте.
Драйвера ставятся сами, ssh сервер ставится и поднимается сам.
Пустая система спокойно стоИт без фаервола неделями.

ставьте современные версии ОС, а не восьмилетней давности... Современная - Windows Server 2008 R2

>ставьте современные версии ОС, а не восьмилетней давности... Современная - Windows Server
>2008 R2

Уплоченное клиентом выкидывать изволите повелеть?  А как же TCO и ROI?

>Современная - Windows Server 2008 R2

А там с сетапом лучше не стало. Сетапер какогониить эксченжа эпично посылает юзера в пешее эротическое путешествие с напутствием "откройте сервер манагер и поставьте там то-то, то-то и то-то". Воистину, система для мартышек. Вместо того чтобы, блин, взять и поставить то-то, то-то и то-то - надо послать юзера самого отпедалить инсталлежку всего этого. Спасибо еще если эта эпопея уложится в сутки секаса с системой и какие-то 3-4 ребута. Потому что у обезьян из редмонда зависимости их недоразумением MSI попросту не рюхаются и у сетапера нет способа установить гребаные нужные компоненты запросив их как "depends". Вместо этого - в сетап пхается проверка посылающая юзера ставить нужные компоненты. Торжество кретинизма. Занавес.

P.S. ах да, особенно прикольно - поставить 2008 R2 чтобы ... чтобы потом после длительного траха с разруливанием зависимостей, когда сетап Excnahge 2007 уже практически согласен запуститься ... узнать что оказывается эксченж 2007 с распоследним SP ... не совместим с этой версией ОС. Это эпично!!! Сильнее приложиться фэйсом об тэйбл крайне нелегко. Будь моя воля - расстрелял бы тех кто делал этот сетап без суда и следствия, они это старательно заслужили. А нельзя сразу было послать? Без просьб к админу разрулить зависимости? Феноменальные уроды!

>но вот недавно пришлось ставить на сервер Win 2003 server.
>Это был ужас. 8 часов рядом со стойкой под кондиционером +10 град.

Я разок сношался двое суток. Мало того что все что вы упомянули в силе, так еще и wintel такой wintel: интельские дрова не захотели ставиться на винду 2003 с сервиспаком новее чем известный им. При том интель технично засунул все и вся в монолитный EXE (ну уроды же, а?) так что система была без шансов их найти сама. А сетапер задетектив вроде как правильную ОС но ниасилив новый сервиспак дурел и не мог завершить установку. Алсо, интель порадовал, забив на апдейты дров для своего крапа ... менее чем через 2 года его покупки обладателями сервака. Так что более нового пакета дров который бы прожевал более актуальную поддерживаемую 2003 у них не оказалось. Малацца, да. В итоге прыгал с бубном почти 2 дня, монолит пришлось задекомпрессить соотв. нагугленной утилсой вручную и в конце концов - через двое суток прыжков с бубном как минимум базовые дрова запустились. Вашумать, это был мой личный рекорд времени установки ОС за 15 лет. Аться два дня чтобы система просто заработала и завелись базовые девайсы (сеть, диски) - это нечто.

Какой кошмар. Это выходит мне еще повезло. 8 часов до подключения в мире виндов - это гуд - большая удача.
У меня от всех этих рассказов волосы в трусах шевелятся (про голову вообще не говорю)

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

Очередной магазин прямо под рукой

Новость зачетная, весь в ожидании холивара! XD А по сути у них с зависимостями проблем будет еще больше чем в linux и больше всего интересует где они репозитарий разместят.

>Эта штука может стать серьёзным ударом как по Linux-у так и по
>всему свободному ПО. Люди могут начать массовую миграцию на проприетарную систему,
>её закрытые библиотеки и стандарты, просто из-за того что "удобно". Уже
>предчувствую высказывания вроде: "почти как линукс и все проги знакомые, нафиг
>с чем-то другим париться". Это очень очень опасно.

Увы, весь бизнес Microsoft на такой методологии ведения "конкуренции" выехал:
http://en.wikipedia.org/wiki/Embrace,_extend_and_extinguish
http://ru.wikipedia.org/wiki/Embrace,_Extend,_and_Extinguish

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

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

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

>Рано радуетесь. Кончится тем, что ставить софт можно будет только с подписаных
>пакетов с официальных репозитариев. И настанет тотальный DRM.

Это тот самый DRM, который постоянно ломают?
Пусть настает)

>И настанет тотальный DRM.

Если кто-то громко плачет - довыпендривался значит. В смысле, так этим варезникам будет и надо, по большому счету. И да, если кто еще не понял - схема Trusted Computing в полной ее инкарнации не ломается по простому. Если проц проверит подпись загрузчика, загрузчик - подпись OS Loader, он - подпись ядра а оно - подписи дров и программ, да, вы не сможете просто взять и похакать это. Потому что взлом будет вызывать срабатывание предыдущего звена в цеплчки а отломать в самом начале оной вы не сможете поскольку оно запихано в сам процессор (в современных CPU от интель и амд вся механика для этого фокуса УЖЕ встроена, кстати). Так что да, приветы варезникам. Моя задница чует что однажды варезников будут ждать очень непростые времена, когда запуск вареза будет требовать таких же злостных прыжков с бубном как на иксбоксах360 и т.п. а онлайн аккаунты будут выбанивать миллионами под гневный писк попавшихся варезников. Да, будущее создается сегодня. И стоит понимать что в том числе и от нас зависит каким оно будет.

P.S. только факты:
- Современные CPU интель и амд умеют проверять подпись начального запускаемого блока кода насколько я знаю. Ну а этот блок может дальше проверять подписи если хочет. Ага?
- В современных виндах (виста, семерка) загрузчик снабжен цифровой подписью. Правда забавно? :)
- Дрова современных виндов тоже снабжены цифровой подписью. Более того, 64 битная виста и семерка неподписанные дрова не будут грузить вообще без плясок с бубном. Ну да, номинально это конечно для защиты от малвари. Ага. Стоит добавить что судя по всему i386 микрософт вообще хотел бы однажды закопать.
- Большая часть софта от MS нынче подписана цифровыми подписями в бинарях и MS настаивает чтобы эту практику поддерживали и их партнеры.
- У MS наблюдается желание пересадить разработчиков на managed язык программирования, где код напрямую вообще выполнять по сути нельзя.

извините, не удержался - надеюсь, модераторы поймут правильно и не удалят/забанят :-)

кому:
steve@microsoft.com

текст письма:
Здраствуйте. Я, Кирилл. Хотел бы чтобы вы сделали пакетный менеджер, суть такова...
Пользователь может манипулировать пакетами, зависимостями и системой сборки.
Можно грабить исходники. И dll'кам раз динамические то сделать так что там большой выбор
А движок можно поставить так что вдали пакеты на сервере, когда скачиваешь они загружаются и устанавливаются.
Можно удалять и т.п. возможности как в apt-get. И правила сборки тоже, и утилиты тоже.
Можно переустанавливать и т.п. Если устанавливать много пакетов то надо слушаться менеджера, и защищать систему от поломанных зависимостей (механизма я не придумал) и пакетов с ошибочными check-суммами, неавторизованных пакетов, и качать на апдейты.
Пользователь сам себе командир может делать что сам захочет прикажет своим пакетам. Всего в менеджере 4 команды. Т.е. менеджер и в нем есть 4 команды, 1 - установить, 2- удалить, 3-обновить, 4 - собрать/пересобрать/сканпелировать... (с сервера, там есть исходники...) Так же чтобы в менеджере могли быть не только жёсткие зависимости к пакетам но и мягкие и если пользователю менеджер ломает зависимости, то он чинится, так же проблемы но пользователь может локально поставить пакеты. Транзакции делать можно...
P.S. Я джва года хочу такой пакетный менеджер.

подписываюсь под этим письмом

А я думаю -- ну и пускай разрабатывают :)

Вот бы еще можно бы было скормить этой программе tar.bz2 и на выходе получить exe или просьбу дать tar.bz2/dll от зависимости...
Недавно скачал FileZilla в Интернет-кафе, чтобы отзеркалить себе последние иксы. Так в "О программе" сказано, что платфрма - 32-битная винда, а скомпилировано в 64-битном в Линуксе... Как это сделать? Я тоже хочу! :-)
P.S. Ну а саму FileZilla в Linux пришлось из исходников ставить, понадобился лишь wxWidgets. Зависимость glibc в Debian 5.0, где делали бинарник, оказалась выше по версии, чем была у меня.

mingw32 + версии библ под mingw32.

apt - однозначно рулит! А в винде каждый "умный" инсталлятор пишет свои dll-ки куда хочет, заменяя оригинальные. Не АЙС

>apt - однозначно рулит! А в винде каждый "умный" инсталлятор пишет свои
>dll-ки куда хочет, заменяя оригинальные. Не АЙС

А что ему ещё остается делать?
Заменить системную dll-ку на более новую?
Так могут и дать это сделать.
Или сделать может и дадут (когда юзер под админом сидит), только после этого некоторые программы могут "внезапно" перестать работать.
Вот и остается держать нужные dll-ки при себе.

>apt - однозначно рулит!

так а в чем сила ? в том что решает зависимости ? так если либы держать при себе то такой проблемы и вовсе не возникает, а если держать общие версии то как удовлетворить требование ПО к конкретной версии либы ? тоже держать несколько ? в чем тогда смысл ? я конечно понимаю что apt не лишняя сущность ;), но всетаки ?

>>apt - однозначно рулит!
>так а в чем сила ? в том что решает зависимости ?
>так если либы держать при себе то такой проблемы и вовсе
>не возникает

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

>а если держать общие версии то как удовлетворить требование
>ПО к конкретной версии либы ? тоже держать несколько ?

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

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

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

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

>Да, другая возникает, но первая уходит ;) какая из них серьезнее спорить
>можно до потери пульса, давайте не будем

Да и зачем бы.

>я тоже могу сказать что лишнее место на диске это фигня

Да, это не самое главное.  Хотя для SSD пока чувствительней.

>а гребля с зависимостями особенно если без сети это даа !

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

>и возможные сбои из-за изменения либы тоже, давайте не будем, с этим все очевидно,
>есть плюсы, есть минусы.

Конечно-конечно, специально ж на LWN ссылку дал -- почитайте по диагонали статью.  А ещё если доведётся линуксовый софт "под зуб" сдавать -- может быть интересен ряд методов, опубликованных в рамках околоальтовских проектов QA Robot и Repocop:
http://sisyphus.ru/srpm/qa-robot
http://www.altlinux.org/Repocop

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

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

>Пользу от апта и иже с ним вижу в возможности управления этим
>болотом общих библиотек, но кто им будет управлять ? домохозяйка ?

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

>тогда зачем вообще винда ?

Воооот. :)

>apt - однозначно рулит!

Рулит и педалит.

http://www.linux.org.ru/forum/talks/4754445
[q] [debian][nvidia] идиоты

Место действия - тестинг. Попытка установить драйверы проприетарные nvidia. Хочу поставить nvidia-kernel-source, собрать из неё модули ядра и поставить nvidia-glx.

nvidia-kernel-source рекомендует nvidia-glx, который зависит от модулей ядра nvidia-kernel-173.14.09. Ну ничего, aptitude ставит рекомендации по умолчанию, вместе с исходниками придётся тянуть сами модули, которые обычно скомпилированы не под ту версию ядра. Переживём.

А самое страшное - что-то из этого списка конфилктует с xorg из того же тестинга.

Всё, сил моих больше нету. Почему, почему в анстейбле всё нормально работает? Должно ведь наоборот...
melkor217 * (08.04.2010 0:12:06)[/q]

>> Позволяет использовать возможности встроенной в Windows системы по сбору информации о
>> крахах в приложениях - Windows Error Reporting, что позволит разработчику улучшить
>> качество Open Source приложения при работе на платформе Windows.

что позволит разработчику улучшить качество Windows Error //fxd

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

>странно что тут спорят практически только разработчки, а как же то обстоятельство, что >в никсах таким способом можно установить _любую_ программу, а мелкософтовском можно >будет установить только прогу от мелкософт?

Почему? где вы это прочитали?

>>а мелкософтовском можно будет установить только прогу от мелкософт?
>Почему? где вы это прочитали?

Потому что см. про репозиторий, наш юный друг.

Когда речь о свободном (или freely distibutable хотя бы) софте, то поддерживать его права есть автоматически.  А когда другие на своих делянках ковыряется, то согнать их в колхоз выйдет только под дулом.  Если угораздит инновационно изобрести колхоз, конечно.

Ну и про условия вписки в Apple Store тоже неслучайно упоминалось.

>Почему? где вы это прочитали?

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

Запустил ща поиск на домашней винде. В итоге около десятка zlib.dll разного размера.

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

Прям анекдот про самосовершенствующийся Windows, превратившийся в конечном итоге в Linux, сбывается :)