Несовместимость Linux

Ну и что? В чем проблемы? Каждый дистрибутив самодостаточен. Хотя... за все не ручаюсь. Слака по крайней мере самодостаточна.

Поставка пакетов в редхатоподобных оставляет желать лучшего. Я ни разу не видел обновлений, как в debian/gentoo. Чтобы обновиться приходится ждать нового релиза дистрибутива.

Слака выкинула GNOME, которым я пользуюсь.

Freerock GNOME и Dropline GNOME - слышали? Ну вот... При большом желании в слаке есть ВСЕ.

юзайте нормальный дистр и будет всё ок

> (ага-ага: "а ты не смотри", мне потом с некоторыми такими обособленными работать)

Ну больше и нечего тут сказать. Мой дистр --- что хочу, то и делаю и ЛОР-Толкс не верю!

> Слака выкинула GNOME, которым я пользуюсь.

1. Это Offtopic. 2. Загляните в LOR-FAQ :-)

> юзайте нормальный дистр и будет всё ок

Использую Slackware, поддерживает и свой BSD-init и System V init (т.е. Oracle и прочие установятся по части init-скриптов без особых плясок с бубном).

> Ну и что? В чем проблемы? Каждый дистрибутив самодостаточен. Хотя... за все не ручаюсь. Слака по крайней мере самодостаточна.

А что делать разработчикам программ, которые не входят в дистрибутивы, а пользователю, который захочет такую программу установить? Посмотрите на исходники большинства даже стандартных пакетов: присутствует и ebuild и suse.spec и fc.spec, а то и vms, os2, win32 папки с исходниками, до кучи еще и zlib каждый хочет запихнуть к себе в дерево (см. tar.gz для cvs, gcc, freetype, старые libpng), tar.gz libwmf включает в себя кусок gd, libexif содержит кусок libjoeg. И это только примеры на-вскидку.

Это ведь делается не от хорошей жизни. Разработчики не стали бы включать в исходники своего tar.gz куски сторонних tar.gz, если бы были уверены в совместимости...

да ладно, успокойся ты... все и так знают что линупс гавно, а венде скоро капец, что патрик - бох, birdie - бот етц етц...

> да ладно, успокойся ты...

да я спокоен %)

> все и так знают что линупс гавно, а венде скоро капец, что патрик - бох, birdie - бот етц етц...

если бы так было, то это было бы слишком просто :-)

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

Ровнять руки и компилить сорцы. Или ждать пока Патрик или slacky.it community соберут нормальный слак-пакет :)

Все путем.
Вон, какая FreeBSD. Нет таких проблем с совместимостью как в линуксе.

Только вот что FreeBSD стесняется теснить линукс где либо.

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

видимо http://www.autopackage.org/ единственно вменяемый вариант

А ещё дальше ... надстройка над надстройкой ... make, autoconf, pkg-config .... а над ними дистростроители с не всегда прямыми рукаи ... и ... манагер пакетов с его зависимостями ... хех ...

Всё развивается. Что будет не востребовано - просто со временем исчезнет. Действительно "а те не смотри". Можно с успехом пользоваться одним дистром, обновлять его, и жить счастливо.

ага, всё от того, что нужно иметь возможность содержать несколько версий программ на одном линуксе (я же могу поставить фотошот 7, CS, CS2 на одну венду!)

поэтому правильная установка пакета выглядит так:
cd /usr/src
wget tarball-1.2.3.tar.gz
tar -zxf tarball-1.2.3.tar.gz
cd tarball-1.2.3
./configure
make


дальше нужно самому раскидать файлы по папкам

как вы собираетесь успользовать apt-get и emerge я не понимаю

>теперь и init-скрипты отличаются...

Пардон муа, но как стартовые скрипты скажутся тотально на несовместимости пакетов?

> видимо http://www.autopackage.org/ единственно вменяемый вариант

Видимо он не совсем такой уж и вменяемый, потому что некоторые его не используют (да тот же qpxtool сейчас висит в новостях LOR и он использует scons). От себя могу добавить, что программа общим весом в 43Кб, использующая большое количество различных функций и компилируемая простым gcc *.c -lm -o myprog при сборке через autopackage-ские configure, make, make install (checkinstall) займет в 7-10 раз больше времени.

>как вы собираетесь успользовать apt-get и emerge я не понимаю

Я не знаю, как использовать emerge, но для использования dpkg есть два варианта начала действий:

cd tarball-1.2.3 mkdir debian

либо

cd tarball-1.2.3 dh_make

Ну а дальше расписывать не буду - маны рулят.

Да, и в конце никаких ./configure и тем более make - dpkg-buildpackage.

> Пардон муа, но как стартовые скрипты скажутся тотально на несовместимости пакетов?

Да просто, если в какую-нибудь старенькую Slackware (только с BSD-init) попробовать поставить oracle/lotus/trendmicro (они все под SuSE/RedHat с System V init), то после установки и перезагрузки ничего не запустится. Что случится сейчас в Debian или Gentoo могу только догадываться.

Да, в Slackware идет штатно rpm и им можно пользоваться для установки новых rpm-пакетов, т.е. с rpm у нее проблем нет, а вот заработает ли rpm ;-)

> - ядра в дистрибутивах отличаются;

версиями

> - glibc в дистрибутивах отличаются;

версиями

> - версии наборов стандартных библиотек и сами библиотеки тоже отличаются;

версиями

> - теперь и init-скрипты отличаются...

Бл# скрипты были есть и будут скриптами. И даже в 10-й соляре с ее сервис манагером тебе никто не мешает воткнуть в зюмельный сценарий тот же старт скрипт.

> Видимо он не совсем такой уж и вменяемый, потому что некоторые его не используют (да тот же qpxtool сейчас висит в новостях LOR и он использует scons). От себя могу добавить, что программа общим весом в 43Кб, использующая большое количество различных функций и компилируемая простым gcc *.c -lm -o myprog при сборке через autopackage-ские configure, make, make install (checkinstall) займет в 7-10 раз больше времени.

видимо кто-то из нас чегой-то путает :) autopackage это package-система, а отнють не build - то есть у него нет родных-своих configure/make/etc.. есть инструкция как интегрировать её с autoconf/automake..есть приятная инструкция как сделать пакет более переносимым..есть тулзы для построения пакета..Но чем этот пакет компилится/собирается абсолютно пофик - хоть руками, хоть зубами :)

>> - ядра в дистрибутивах отличаются; > версиями

Ну да! Особенно у RedHat, самые обычные ядра (они добавили NPTL в ядро 2.4.x).

>> - glibc в дистрибутивах отличаются; > версиями

То же самое про RedHat (они добавили NPTL в glibc для 2.4.x).

>> - версии наборов стандартных библиотек и сами библиотеки тоже отличаются; > версиями

Ваше версиями иногда равно работоспособностью.

>> - теперь и init-скрипты отличаются... > Бл# скрипты были есть и будут скриптами. И даже в 10-й соляре с ее сервис манагером тебе никто не мешает воткнуть в зюмельный сценарий тот же старт скрипт.

Чего так переживаешь? System V в Solaris вполне обычный, как и в SCO, как и в AIX...

> видимо кто-то из нас чегой-то путает :) autopackage это package-система, а отнють не build

Да, ошибся. Но какой дистрибутив имеет autopackage в смоем штатном составе (кроме многопакетников типа Gentoo или Debian)? Да и это все сборкой попахивает, которая не гарантированно будет успешной. Хочется бинарников и простоты ;-) как в Windows, как в Linux 10 лет назад.

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

Это проблемы некоторых.

>От себя могу добавить, что программа общим весом в 43Кб, использующая большое количество различных функций и компилируемая простым gcc *.c -lm -o myprog при сборке через autopackage-ские configure, make, make install (checkinstall) займет в 7-10 раз больше времени.

Причем тут autopackage??? Ты по ссылке вообще ходил??? В autopackage необходимо сделать только

bash Example.package

и все. Хотя софта с autopackage у меня маловато поставлено, так как все либо есть в репозитории, либо в бэкпортах. Но например xaralx стоит именно c autopackage

> Да, ошибся. Но какой дистрибутив имеет autopackage в смоем штатном составе (кроме многопакетников типа Gentoo или Debian)? Да и это все сборкой попахивает, которая не гарантированно будет успешной. Хочется бинарников и простоты ;-) как в Windows, как в Linux 10 лет назад.

отвлекитесь от топтания клавиатуры - пройдитесь таки по ссылке.. это оно самое и есть :)

> отвлекитесь от топтания клавиатуры - пройдитесь таки по ссылке.. это оно самое и есть :)

Да помню я этот autopackage, я кажется им только игрушки и ставил (только один раз что то по работе) :-)

http://www.autopackage.org/packages/ небольшой список...

Меня пакеты вида *.package раньше всегда пугали, сейчас уже привык, но я давно с Linux, а новички? Для них никто даже не пишет, что после скачивания нужно сделать chmod 0777 *.package

> Видимо он не совсем такой уж и вменяемый, потому что некоторые его не используют (да тот же qpxtool сейчас висит в новостях LOR и он использует scons). От себя могу добавить, что программа общим весом в 43Кб, использующая большое количество различных функций и компилируемая простым gcc *.c -lm -o myprog при сборке через autopackage-ские configure, make, make install (checkinstall) займет в 7-10 раз больше времени.

Самый кошерный способ вида "./configure && make && make install" будет работать всегда, а если кто-то себе изыскивает геморрой - то ССЗБ. Вообще проблемы с пакаджингом - то проблемы поддерживающих репозиторий, откуда и должны качаться и ставиться пакеты в специфичном для дистра формате. А задача програмера - не ипать моск ни себе ни остальным, а ориентироваться на кошерные GNU autotools (с которыми мейнтейнер тем самым checkinstall'ом получит базу для пакета), а не маргинальные поделки типа scons, из которых даже лога об ашшипках толком не вытащишь.

> - ядра в дистрибутивах отличаются;

+1. Но главная беда не этом, а в том, что отличаются они от ваниллы.

> - glibc в дистрибутивах отличаются;

Не отмаз, если писать софт по стандарту - то пофиг, а если пытаться тянуть кота за яйца как Оракел и прочие мега-софтины, то ССЗБ. Проблема - при втыкании в дистр свежака типа glibc-2.4 из CVS як в Федорином Горе, но то на продакшене юзать - еще больший ССЗБ, а вендорам - сигнал начинать переползать потихоньку.

> - версии наборов стандартных библиотек и сами библиотеки тоже отличаются;

Ну и чего? Я ж говорил, что прогеру суть задача - работать с сорцами, а не заморачиваться на темы "какая там версия".

> - теперь и init-скрипты отличаются...

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

> Все это создает тотальную несовместимость линуксов с линуксами, смотреть противно (ага-ага: "а ты не смотри", мне потом с некоторыми такими обособленными работать).

Правильно, нужно клепать софт слабозависимый от конкретной системы (или с нужным количеством ifdef'ов), а остальные вопросы решаться либо нормальной поддержкой, либо предоставлением сорцов.

> Ну да! Особенно у RedHat, самые обычные ядра (они добавили NPTL в ядро 2.4.x).

И неужто было нельзя выбрать ядро без НПТЛ?

> То же самое про RedHat (они добавили NPTL в glibc для 2.4.x).

-1, у них была и есть хитрая система LD_ASSUME_KERNEL, с еще боле хитрым деревом из десятка разных glibc, загружаемых под софтину.

> Ваше версиями иногда равно работоспособностью.

Неа. Или нестандарт.

> А задача програмера - не ипать моск ни себе ни остальным, а ориентироваться на кошерные GNU autotools (с которыми мейнтейнер тем самым checkinstall'ом получит базу для пакета), а не маргинальные поделки типа scons, из которых даже лога об ашшипках толком не вытащишь.

Да вы сверхчеловек, так все просто. А главное кроссплатформенно, наверное GNU autotools входят в состав и Solaris и AIX и SCO и.т.д.

P.S. Обидеть не хотел.

> Ну да! Особенно у RedHat, самые обычные ядра (они добавили NPTL в ядро 2.4.x).

И спрятали патчи от всех а дебиан на такое ядро скажет "Буээээ нихачу работать".

> То же самое про RedHat (они добавили NPTL в glibc для 2.4.x).

И ?

> Ваше версиями иногда равно работоспособностью.

Реальную ситуацию ффффстудию!

> Чего так переживаешь? System V в Solaris вполне обычный, как и в SCO, как и в AIX...

Я не переживаю, некто "сапер" открыл тему афигенной несовместимости скриптов. Кста в 10-ке уже не совсем обычный...

> Solaris и AIX и SCO и.т.д.

Кстати до кучи а каким местом тут дистры и совершенно различные операционки ? В которых кстати все д....т как хочут. Изредка следуя генеральной линии партии...

Вобщем трэшовая тема... Ты б лучше про бап че-нить написал повесилились бы...

> Да вы сверхчеловек, так все просто.

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

> А главное кроссплатформенно, наверное GNU autotools входят в состав и Solaris и AIX и SCO и.т.д.

Разумеется, на соляре autotools точно есть, как и куча GNU утилит. Даже больше - без них на соляре делать всякую рутину чрезвычайно тоскливо и напряжно ;) Ну а прочие древнеегипетские ОСи интересны разве что штучным девелоперам, для особо маленьких и особо больших систем. Разве что немецкие коллеги AIX хвалили, поэтому сделаем исключение.

> ага, всё от того, что нужно иметь возможность содержать несколько версий программ на одном линуксе

./configure --prefix=/opt/proga-1.2.3 ?

А что делать разработчикам программ, которые не входят в дистрибутивы,
Разработчикам - писать программы. Например, так:
ftp://ftp.communigate.com/pub/CGatePro/5.1/
Сложно? Не пишите программы, неужели под угрозой применения противоестественных средств заставляют? :-)
>а пользователю, который захочет такую программу установить?
rpm -i proga.rpm
dpkg -i proga.deb
installpkg proga.tgz
...
P.S. Все операционки можно легко загнать в виртуальную машину и запускать перед релизом своей проги.