tiphareth: лицензионное программное обеспечение для российских школ

(Читать комментарии) - (Добавить комментарий)

pzz
2007-11-29 14:36 (ссылка)

Сейчас неи никаких трудностей писать кросс-платформенный софт

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

У матери на работе поставили убунту, она и разницу не заметила

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

Стандартная оболочка виндовса, конечно, без проблем заменяется на ее аналог из KDE или GNOME - все три одинаковые говны, мало пригодные для жизни. А если хочется жить хоть немного поудобнее, то тут уже пути виндовса и линуха расходятся. Скажем, для виндовса хочется что-то типа Far'а, а в линухе командная строка достаточно удобна, если уметь ей пользоваться.

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

(Ответить) (Уровень выше) (Ветвь дискуссии)

dkor2005.livejournal.com
2007-11-29 14:50 (ссылка)

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

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

"Это так только для тех, кто использует пару стандартных програм,"

нет это не только со стандартными программами, посмотрите в сторону SAP, это далеко не стандартные программы.

Сервак 1С написали для линукса, за клиентом думаю не постоит. Чем не специализированный софт?

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

(Ответить) (Уровень выше) (Ветвь дискуссии)

pzz
2007-11-29 15:21 (ссылка)

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

Не надо на меня гавкать - я и сам неплохо умею это делать.

Единственный приличный мултиплатформенный гуевый тулкит - это Qt. Qt, как известно, написан на C++. C++ ABI ломался в линухе за последние немного лет 2 раза, при переходе на gcc 3.2 и 3.4. Программы, собранные компилятором с одной версией API, не будут работать с динамическими библиотеками, собранными другой версией.

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

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

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

Если сравнивать с вендой, то ее есть всего 3: w2k (уже умирающая), XP и Vista. Обратная совместимость выдерживается очень хорошо. С Маком примерно та же ситиация.

С учетом того, что продать линуксоидам все равно ничего не возможно, надо понимать, что коммерческие вендоры поддерживают линух в основном не ради коммерции, а из жалости по отношению к красноглазым линуксоидам :-)

Расскажите еще, что для Adobe была бы большая проблема переписать свой софт для линукса

У них всегда была юниксовская версия, для Silicon Graphics. JFYI.

(Ответить) (Уровень выше) (Ветвь дискуссии)

dkor2005.livejournal.com
2007-11-29 16:14 (ссылка)

Все нестыковки с различными библиотеками решаются просто. библиотеки собираются и ставятся в корень с прогой - одно решение, или же кодеры учитывают нестыковки и пишут макрокоманды, код qt ими полон. при сборке Qtшных прог в qmake можно прописать, какой хидерник или сурсный файл прикреплять при какой версии системы, библиотек, оси и т.д. Это все решаемо. Разные установочные пакеты тоже никого не волнуют, пишется свой инсталлятор, который все распихает куда надо и, о боже, поставит прогу в любую папку, хоть в хоум директорию и пути тоже пропишет. Большим компаниям приходится считаться с линуксом уже сейчас, пока не в России, к сожалению, но лет через 10 и в России придется. Ну а насчет Adobe, вы и сами видите, что не проблема таки софт писать по юниксовые машинки, хоть силикон графикс и не PC. Под линукс тоже будут писать, никуда не денутся.

(Ответить) (Уровень выше) (Ветвь дискуссии)

pzz
2007-11-29 16:32 (ссылка)

или же кодеры учитывают нестыковки и пишут макрокоманды

Я говорю не о source-level совместимости. Это как раз фигня. На уровне исходников линух сам с собой очень хорошо совместим.

Я говорю о бинарной совместимости между дистрибутивами. Под бинарной совместимостью я имею ввиду:
1. Набор динамических библиотек, стандартно установленных, или которых пользователя несложно уговорить доставить (т.е., они есть на дистрибутивном диске или в стандартном yam/apt'ном репозитории)
2. Их версии
3. Версия компилятора, которым все это хозяйство собрано - увы, в долбанном линухе ABI меняется с каждой новой версией компилятора
4. Функциональность ядра, на которую можно рассчитывать - там тоже много чего меняется от версии к версии или в зависимости от конфигурации
5. Соглашения об именовании стандартных каталогов
6. Дектоп - KDE/GNOME/...

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

Это все решаемо

Я не сказал, что это не решаемо. Я сказал, что это геморройно. Из 3-х платформ, линух, венда и мак, линух - самая геморройная для binary-only software.

Разные установочные пакеты тоже никого не волнуют

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

Большим компаниям приходится считаться с линуксом уже сейчас, пока не в России, к сожалению, но лет через 10 и в России придется

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

(Ответить) (Уровень выше)

yushi
2007-11-29 17:29 (ссылка)

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

Речь о закрытом или открытом продукте?

Если о закрытом, то это не проблема платформы. Это проблема менеджмента, который выбрал бизнес-модель, плохо совместимую с данной конкретной платформой. iPod нельзя увидеть как стандартный съёмный USB-носитель, но никто не обвиняет в этом кривизну USB.

Если об открытом, то, по-моему, проблемы (если мы не пишем дистроспецифичную конфигурационную утилиту) не наблюдается. Если использовать хорошо написанные библиотеки типа Qt и правильные утилиты управления сборкой (хотя бы automake/autoconf), то точно всё хорошо.

(Ответить) (Уровень выше) (Ветвь дискуссии)

pzz
2007-11-29 17:48 (ссылка)

Это проблема менеджмента, который выбрал бизнес-модель, плохо совместимую с данной конкретной платформой

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

iPod нельзя увидеть как стандартный съёмный USB-носитель, но никто не обвиняет в этом кривизну USB

Железным эквиавалентом было бы существование 20-и разных, немного несовместимых разъемов USB.

Если использовать хорошо написанные библиотеки типа Qt и правильные утилиты управления сборкой (хотя бы automake/autoconf), то точно всё хорошо

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

(Ответить) (Уровень выше) (Ветвь дискуссии)

yushi
2007-11-29 21:40 (ссылка)

Поддержка Скайпом линуха - ошибка менеджеров Скайпа.

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

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

Я бы, кстати, только обрадовался, если бы Скайп перестал поддерживать linux-версию — тогда, глядишь, быстрее допилили бы голосовые расширения к XMPP. Знакомые у меня, кстати, пользуются SIP и особого проигрыша в качестве связи относительно "пирингового" Скайпа не видят.

>iPod нельзя увидеть как стандартный съёмный USB-носитель, но никто не обвиняет в этом кривизну USB
Железным эквиавалентом было бы существование 20-и разных, немного несовместимых разъемов USB.

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

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

Не разу не использовал, а чем, скажем, плох dirnotify? И зачем это надо?

(Ответить) (Уровень выше) (Ветвь дискуссии)

pzz
2007-11-29 23:31 (ссылка)

Если ребята не способны придумать способ зарабатывания денег, совместимый со стандартными методами работы с платформой

Что такое стандартные методы работы с платформой Линух? Где их можно прочитать?

Я бы, кстати, только обрадовался, если бы Скайп перестал поддерживать linux-версию — тогда, глядишь, быстрее допилили бы голосовые расширения к XMPP

Скайп в первую очередь замечателен тем, что он умеет терминировать звонки на обычных телефонах. Причем за смешные деньги. И это работает out of box.

Знакомые у меня, кстати, пользуются SIP и особого проигрыша в качестве связи относительно "пирингового" Скайпа не видят

Наверное, им медведь на ухо наступил. Чем быстрее помрет SIP и RTP, тем лучше. Это плохие протоколы, придуманные еще в те времена, когда никто не знал, как они будут использоваться.

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

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

И в чем заключается этот способ, если окружением является линух, а изделием - программа?

Не разу не использовал, а чем, скажем, плох dirnotify? И зачем это надо?

Зачем надо, не важно. Понадобилось вот.

Чем он плох, написано, например, здесь: http://www-128.ibm.com/developerworks/linux/library/l-inotify.html

(Ответить) (Уровень выше) (Ветвь дискуссии)

yushi
2007-12-02 22:32 (ссылка)

Что такое стандартные методы работы с платформой Линух? Где их можно прочитать?

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

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

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

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

Кстати, я не против p2p-архитектуры, при прочих равных, наоборот, за. Просто противно наблюдать QWERTY-эффект: закрытый протокол с единственной кривоватой реализацией не должен становиться стандартом. Как будто мало Flash и ICQ.

И в чем заключается этот способ, если окружением является линух, а изделием - программа?

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

(Ответить) (Уровень выше) (Ветвь дискуссии)

pzz
2007-12-02 22:37 (ссылка)

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

autoconf решает проблему сборки, а не пакаджинга.

Ну а кто их содержит сейчас? Хозяева этих серверов, наверное

А их кто-то сейчас содержит?

Кстати, я не против p2p-архитектуры, при прочих равных, наоборот, за. Просто противно наблюдать QWERTY-эффект: закрытый протокол с единственной кривоватой реализацией не должен становиться стандартом. Как будто мало Flash и ICQ

Так нету ни открытого протокола, ни реализации. SIP это не серьезно.

(Ответить) (Уровень выше)

(Читать комментарии) -