Slackware 11

[gvy]

Їде    Завтра у першій половині мають приїхати всі 6 CD. Буде і дівіді теж. Коли буде готово - напишу на Дошку роздачі слонів... тобто - Пінгвінів

Патрику, я вже пожалів -- вночі воно буде на ftp.linux.kiev.ua (ISO, якщо треба дерево -- ну можу теж забрати).  UA-IX.

UPD: ftp://ftp.linux.kiev.ua/pub/Linux/Slackware/slackware-11.0-iso/

Апач - 1.3.37   Мабуть знов прийдеться ставити 2.0.* з сирців.

А ось тут тільки пожаліти й залишається.  Це ж яким наївним сисадміном треба бути, щоб заміняти 1.3 на *2.0*... якщо б на 2.2 -- то воно принаймні поки не таке лайно, яким був з самого початку apache-2.0.

[Cthulhu]

2Володимир Лісівка: Ядро 2.6.18 знаходиться в testing, тобто технічно його можна поставити, але користуватись не рекомендується. Для стабільної інсталяції наявне 2.6.17.13.

2gvy: Щодо сьомих іксів можу погодитись. Але! Якщо комусь треба буде, запросто збере їх під слакою сам. Особисто мені вони зараз просто не потрібні (хоча я не показник, я взагалі з xfree тільки того року зліз:)).

Щодо glibc. Подібні речі зараз можуть бути потрібними kernel-девелоперам, а також розробникам програмного забезпечення, в яке кров з носа треба додати нові фічі, а без цих нових можливостей ну ніяк. Більшість програмних продуктів мають апробовану модель розробки, усталений API etc, і просто так це ламати ніхто не буде. Тим більше, що сумісність з попередніми версіями з великою вірогідністю летить під три чорти. Таке можна собі дозволити у невеликих проектах з малою аудиторією, але строго протипоказано у більш-менш солідних. Хіба що - як експериментальна гілка. Тому, думаю, з такої точки зору повна підтримка старого glibc буде тягнутись ще від року двох.

Щодо gcc - аргумент справді серйозний:) Єдине що можу сказати - певна частина програм без напильників ним не скомпілюється, а політика Патріка у цьому відношенні - не вносити змін у офіційні релізи пакетів. Що, в принципі, дуже виправдано.

Навряд чи я скоро перейду на інший дистрибутив... Можливі переваги надто дрібні порівняно з проблемами, що однозначно виникнуть при зміні. З цієї точки зору я навіть на Zenwalk не став переходити, а то річ справді чудова. А про те, що в мене слака, я згадую тільки підчас апгрейдів (треба ж знати, куди за пакетами лізти) або флейму)))

ЗІ користувач Slackware з v9.1.

[gvy]

2Володимир Лісівка: Ядро 2.6.18 знаходиться в testing, тобто технічно його можна поставити, але користуватись не рекомендується. Для стабільної інсталяції наявне 2.6.17.13.

Так зараз або нормальні треди (2.6-only), або 2.4/2.6.

2gvy: Щодо сьомих іксів можу погодитись. Але! Якщо комусь треба буде, запросто збере їх під слакою сам. Особисто мені вони зараз просто не потрібні (хоча я не показник, я взагалі з xfree тільки того року зліз:)).

Ну я колись на Black Cat новомодні четверті ікси збирав та ставив з тарболів.  Бо вже було зрозуміло, що тій інсталяції капець (поруч вже стояв та дуже подобався Spring 2001).

Але щодо слаки та "сам" -- згоден, смітник від того аж ніяк не постраждає (бо нема чому). :-)

Щодо glibc. Подібні речі зараз можуть бути потрібними kernel-девелоперам, а також розробникам програмного забезпечення, в яке кров з носа треба додати нові фічі

Гірше -- он колезі на кластерах воно конце потрібно.  Й ще одній конторі -- для свого тредового спецсерверу.  І...

а без цих нових можливостей ну ніяк. Більшість програмних продуктів мають апробовану модель розробки, усталений API etc, і просто так це ламати ніхто не буде.

Справа не в "просто так", а в суттєвій різниці в швидкості.

Тим більше, що сумісність з попередніми версіями з великою вірогідністю летить під три чорти.

RTFM release notes -- у glibc підтримують зворотню сумісність досить непогано.

Таке можна собі дозволити у невеликих проектах з малою аудиторією, але строго протипоказано у більш-менш солідних. Хіба що - як експериментальна гілка. Тому, думаю, з такої точки зору повна підтримка старого glibc буде тягнутись ще від року двох.

FYI: linuxthreads вже давно (з 2.4) винесені з core.  Навіть альт, навіть Owl, навіть я, котрий *дуже* полюбляє 2.4 -- вже на 2.6.  Й нові сервери теж вже на 2.6.

Щодо gcc - аргумент справді серйозний:) Єдине що можу сказати - певна частина програм без напильників ним не скомпілюється, а політика Патріка у цьому відношенні - не вносити змін у офіційні релізи пакетів. Що, в принципі, дуже виправдано.

Патрик просто визнає свою некомпетентність та неспроможність слідкувати за всим, що йому самотужки доводиться збирати.  Ото й має неінтегрований дистро на дві руки.  Щось ініціативи на кшталт Dropline більш не спостерігаю, типу, save the patricks.

(щоб було зрозуміло, про що я -- можете спитати про патчі у будь-якому з моїх пакунків у тому ж ALT Linux, наприклад, в xmms; про суттєву кількість можу розповісти, що навіщо та чим це краще за те, що мають зі слаквар'ю)

Навряд чи я скоро перейду на інший дистрибутив... Можливі переваги надто дрібні порівняно з проблемами, що однозначно виникнуть при зміні.

Хє.  Приходьте якось до нас в офіс (Київ, Лесі Українки), чи ото на коференції якщо будете -- в мене на ноуті достатньо на показати, щоб не-перший-день розробник зацінив, що в нас є ;-)

ЗІ користувач Slackware з v9.1.

Тю, хіба то термін.  В мене до першого лінукса кернель із саундом на Slackware 4.0, здається, компілявсь... (а достатньо було sndconfig сказати, між іншим)

Насправді я просто шукаю собі помічників на декілька страшенно цікавих (для мене принаймні), але досить часоємних розробок, щоб не виходило дістатися до них самому.  Й навколо osdn.org.ua, й навколо altlinux.org.  Та досить багато вже бачив людей, які декілька років робили щось своє з тієї ж слакварі чи взагалі самотужки, щоб потім знайти свою команду...

PS: перечитав -- ну от, знов скажуть, Шигорін слакваристів збочує... :-)

[Cthulhu]

gvy, не ображайтесь, але ви абсолютно не вмієте формулювати свою думку. Слів ви написали багато, а зрозуміло з них відсотків 5. Я чесно старався щось розібрати:

Справа не в "просто так", а в суттєвій різниці в швидкості.

Бенчмарки в студію. А заодно випадки, коли цей виграш є справді принциповим.

RTFM release notes -- у glibc підтримують зворотню сумісність досить непогано.

Охохо... Моє повідомлення слабо почитати?

FYI: linuxthreads вже давно (з 2.4) винесені з core.  Навіть альт, навіть Owl, навіть я, котрий *дуже* полюбляє 2.4 -- вже на 2.6.  Й нові сервери теж вже на 2.6.

В курсі. І що ви хотіли цим сказати?

Хє.  Приходьте якось до нас в офіс (Київ, Лесі Українки), чи ото на коференції якщо будете -- в мене на ноуті достатньо на показати, щоб не-перший-день розробник зацінив, що в нас є ;-)

На жаль, нічого з цього не вийде. Я, гм, далеченько живу.

Все інше не осилив. Численні провокації флейму я теж опустив.
Розпишіть краще по пунктах, що ви хотіли сказати...

[gvy]

gvy, не ображайтесь, але ви абсолютно не вмієте формулювати свою думку. Слів ви написали багато, а зрозуміло з них відсотків 5.

Ой, вибачте, зовсім не хотім образити чи навантажити :-(  Дійсно, зауваження цілком слушне (TM)

Справа не в "просто так", а в суттєвій різниці в швидкості.

Бенчмарки в студію. А заодно випадки, коли цей виграш є справді принциповим.

google://nptl+linuxthreads+benchmark; цей виграш іноді буває принциповим (чи тягне залізяка навантаження, чи ні), але частіше це просто питання ціни.  Так от якщо софтварно можна вирішити те саме, що й хардварно, то це має іншу економіку.  Тобто не безкоштовно, але тим дешевше, чим більше заліза було б потрібно замінювати чи додавати.

Дивіться, наприклад, тута приклад про httpd.

RTFM release notes -- у glibc підтримують зворотню сумісність досить непогано.

Охохо... Моє повідомлення слабо почитати?

Та не слабо, але нібито ми з Вами на різній хвилі. :-)

В курсі. І що ви хотіли цим сказати?

Що linux-2.4 та glibc-2.3 -- покійники.  Й базувати на них "новий" дистрибутив -- некрофілія.  Втім, це не протирічить решті.

Все інше не осилив. Численні провокації флейму я теж опустив.

Ех ;-)

Розпишіть краще по пунктах, що ви хотіли сказати...

Що для розробників та адміністраторів, які цінують свій час та мозок, в інших місцях вже давно є більш цікаві варіанти іх гаяти.

Наприклад, в нас зараз такий toolchain є:

rpm: встановлення/видалення/поновлення пакунків із скриптами на ці події та обробкою поновлення конфігів
apt: рівень вище, ніж rpm -- дозволяє автоматичне врахування залежностей (в тому числі при їх зміні)
# це було корисно усім, а далі переважно розробницьке
hasher: генерування чрутів заданого складу за допомогою apt та fakeroot з наданого репозиторію пакунків
gear: збирання пакунків за допомогою hasher безпосередньо з розробницького git-репозиторію
# а це -- розробнику дистрибутивів та адміну
spt: генерація ISO (livecd, installer) чи тарболів (для контейнерів openvz чи vserver) за допомогою hasher
control: простий фреймворк для керування об'єктами системи
# NB: wiki -- .ru

Все це дозволяє автоматично вирішувати завдання того рівня, вирішення яких таким чином для слакварі неможливе; ми про те із Хотабичем та Сколотом спілкувались -- не вистачає %pre/%postun IIRC скриптів, залежностей пакунків того рівня коректності, щоб вистачало мінімального списку "кінцевих" потреб для підтягування усього, що їм треба: наприклад, template cache для openvz нещодавно робив із $SPTDIR/profile/packages/main вигляду basesystem apt etcnet glibc sysklogd (s/ /\n/g).

Втім, в людей дійсно може просто не бути завдань цікавіше за localhost... а тоді дистро неважливий, були б люди хороші.

[Cthulhu]

google://nptl+linuxthreads+benchmark; цей виграш іноді буває принциповим (чи тягне залізяка навантаження, чи ні), але частіше це просто питання ціни.

В 4-8 рази, значить... Що ж, справді дуже непогано.

Та не слабо, але нібито ми з Вами на різній хвилі. :-)

Я казав про сумісність програмного продукту, а не glibc.

Що linux-2.4 та glibc-2.3 – покійники.

А ось тут ви жорстоко помиляєтесь. Зараз у світі існує... скажімо так, значна кількість проектів заточених тільки і виключно під linux-2.4. Точних цифр, на жаль, назвати не зможу. Але сам я в такому проекті працював не далі як цього року. І на те, щоб тримати його на 2.4 є поважні причини. Холєра, один мій знаймий до цих пір на 2.2 працює, бо в них там якась хитра екзотика))

Кілька загальних слів про те, чому я вважаю неправильним ліпити в стабільний диструбутив найновіші фічі. Не буду говорити про слаку – ви це, гм, якось дивно сприймаєте. Візьмем, скажімо, redhat-и. Їх модель розробки і тестування проста – надодають всяких фіч у халявну реалізацію, community протестує, обкатає, виявить граблі, деякі з них виправить. Отримуємо результат: rhel (дуже надійний і стабільний комерційний дистр) і Fedora – ультрасучасний дистрибутив напханий найновішими фічами (яку, правда, перідично потужно проглючує). Але! Здогадайтесь, який glibc у поточному Fedora-testing:) А тепер, за вашою логікою, ви маєте сказати, що федора – г...но і морально застаріла, бо не включили новий glibc за цілий (ви тільки уявіть!) тиждень після релізу.
Або Debian. То й же принцип – Debian sid і stable. Скажіть комусь, що Debian застарів... Навіть на гентушних дзеркалах glibc-2.5 з'явилось позавчора-вчора. Не встигають гетушники за плином часу! Не вганяються!:)

Про що, власне, мова. Є тестові дистрибутиви. І є дистрибутиви для роботи. Слака належить до тої ж категорії, що і Debain stable, і rhel – це дитсрибутив який а) ніколи не глючить, не падає і б) всі граблі, які є, давно виправлені і задокуменовані. Єдине що, можливо, вводить вас в оману – що у слаки немає тестового дистру. Розробляє і тестує його дуже обмежена громада. А ви пропонуєте запинути туди нетестоване програмне забезпечення. Давайте експеримент: запропонуйте оце Red Hat inc. або Debain team, а ми заміримо, хто вас далі пошле)))

Чому я не хочу використувувати тестовий дистр навіть на десктопі? А ви здогадайтесь. Я розробляю і тестую певне програмне забезпечення. І хочу чітко знати, що моя ОС НЕ глючить. Щоб не було такого, коли три дні фіксиш багу, а потім виявляється, що то хитрий глюк криво зібраної ліби  в дистрі.

Наприклад, в нас зараз такий toolchain є

Дуже мило, і місцями дуже корисно. Але мене наразі pkgtools влаштовують))) І не треба розводити на цю тему флейм – просто з моїми задачами воно справляється. На кожну задачу – свій інструмент.

Да, хто такі Хотабич і Сколот?

[Володимир Лісівка]

Наприклад, в нас зараз такий toolchain є:

rpm: встановлення/видалення/поновлення пакунків із скриптами на ці події та обробкою поновлення конфігів

Тобто ставиться пакет з трігерами, які спрацьовують на встановлення/оновлення/видалення іншого пакету, й відповідно правлять конфігурацію? Це цікаво, бо я вирішував цю проблему хоча і не руками але все ж не зовсім природнім способом. :-)

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

apt: рівень вище, ніж rpm -- дозволяє автоматичне врахування залежностей (в тому числі при їх зміні)

Ми yum-ом користуємся. З yum 2.0 проблем доволі мало.

# це було корисно усім, а далі переважно розробницьке
hasher: генерування чрутів заданого складу за допомогою apt та fakeroot з наданого репозиторію пакунків

У федорці є mock - дуже корисна штука, особливо коли треба зібрати пакет під іншу версію дистрибуту (в нас використовуються FC4 і RHEL4 а я сижу зараз на FC5).

gear: збирання пакунків за допомогою hasher безпосередньо з розробницького git-репозиторію

Мені довелося таку штуку писати самому для нашого проекту.

Таких систем трохи є різних, але у нас історично склалася специфічна система будування.  :-)

Все це дозволяє автоматично вирішувати завдання того рівня, вирішення яких таким чином для слакварі неможливе;

+1

[Володимир Лісівка]

Що linux-2.4 та glibc-2.3 – покійники.

А ось тут ви жорстоко помиляєтесь. Зараз у світі існує... скажімо так, значна кількість проектів заточених тільки і виключно під linux-2.4. Точних цифр, на жаль, назвати не зможу. Але сам я в такому проекті працював не далі як цього року. І на те, щоб тримати його на 2.4 є поважні причини. Холєра, один мій знаймий до цих пір на 2.2 працює, бо в них там якась хитра екзотика))

export ASSUME_KERNEL="2.4" ?

Про що, власне, мова. Є тестові дистрибутиви. І є дистрибутиви для роботи. Слака належить до тої ж категорії, що і Debain stable, і rhel – це дитсрибутив який а) ніколи не глючить, не падає і б) всі граблі, які є, давно виправлені і задокуменовані. Єдине що, можливо, вводить вас в оману – що у слаки немає тестового дистру. Розробляє і тестує його дуже обмежена громада. А ви пропонуєте запинути туди нетестоване програмне забезпечення. Давайте експеримент: запропонуйте оце Red Hat inc. або Debain team, а ми заміримо, хто вас далі пошле)))

RedHat славиться своєю любов'ю до всього найновішого. І це правильно. Тому що та ж федора з часом стає стабільною. Напр. FC4 колись була дуже глюкавою але потім помилки повиправляли й зараз FC4 дуже стабільний дистр.

Я не розумію, навіщо випускати Slacware 11, якщо реально там відмінностей на мажорну версію нема. Можна було випустити 10.1 - це було б зрозуміло. А так це чистий піар застарілого дистрибутиву.

Чому я не хочу використувувати тестовий дистр навіть на десктопі? А ви здогадайтесь. Я розробляю і тестую певне програмне забезпечення. І хочу чітко знати, що моя ОС НЕ глючить. Щоб не було такого, коли три дні фіксиш багу, а потім виявляється, що то хитрий глюк криво зібраної ліби  в дистрі.

Чому я хочу використувувати свіжий дистр особливо на десктопі? А ви здогадайтесь. Я розробляю і тестую певне програмне забезпечення. І хочу чітко знати, що моя програма не глючить з новою ОС. Щоб не було такого, коли три місяці пишеш фічу, а потім виявляється, що ту фічу доведеться переписувати з нуля через викидання старої ліби з дистру.

Наприклад, в нас зараз такий toolchain є

Дуже мило, і місцями дуже корисно. Але мене наразі pkgtools влаштовують))) І не треба розводити на цю тему флейм – просто з моїми задачами воно справляється. На кожну задачу – свій інструмент.

Не смішіть мої тапки. Я теж можу пакувати програми в тарболи, й вони справляться із задачою, просто _деколи_ я змушений буду витрачати свій час на ті завдання, які yum/rpm роблять автоматичн а в pkgtools не підтримуються. От власне цей додатковий час, який можна зекономити, і є важливим аргументом для мене на користь дитстру з RPM-ками, тому що в мене в проекті зараз вже більше сотні пакетів і весь час додаються нові. Помножте їх на 16 фізичних серваків (~50 віртуальних VServer-ів), помножте на 10-15 щоденних білдів та 20-40 інсталяцій, і зрозумійте, що навіть одна додаткова хвилина на пакет - це _дуже_ багато.

Для порівняння - коли ми ще не використовували RPM-ки а просто пакували все в zip-и, лише одне встановлення займало 3 дні, хоча об'єм коду був на порядок менший.

[Володимир Лісівка]

http://ring0-2007.livejournal.com/4835.html (ru)

[Cthulhu]

export ASSUME_KERNEL="2.4" ?

Не котить в силу багатьох причин. Всі перерахувати тут я не осилю, та й, вірогідно, не знаю я всіх.

Я не розумію, навіщо випускати Slacware 11, якщо реально там відмінностей на мажорну версію нема. Можна було випустити 10.1 - це було б зрозуміло. А так це чистий піар застарілого дистрибутиву.

Ви б хоча б поцікавились суттю питання, перед тим як оце писати. Останній Slackware - це 10.2, випущений більше року тому. І змін за рік - дуже багато. Підіть, почитайте чанджлоги.

Чому я хочу використувувати свіжий дистр особливо на десктопі? А ви здогадайтесь. Я розробляю і тестую певне програмне забезпечення. І хочу чітко знати, що моя програма не глючить з новою ОС. Щоб не було такого, коли три місяці пишеш фічу, а потім виявляється, що ту фічу доведеться переписувати з нуля через викидання старої ліби з дистру.

Головою треба думати, коли щось пишеш. І відслідковувати зміни в потрібних бібліотеках (тобто від яких залежиш), і ставити їх при потребі.  Самому, не чекаючи, поки дядечко туди кривих патчів накидає.
Маленька притча: нещодавно вийшов pygtk-2.10 і pyglade-2.10 з купою змін. Є такий маленький, але корисний програмний продукт під назвою Gajim, який використовує pygtk. Дивлячись на список змін pygtk, я можу відразу назвати купу покращень і оптимізацій для Gajim. А тепер здогадайтесь, від якого pygtk залежатиме наступна версія:)
Хоча, взагалі-то викидання ліби з дистру - не аргумент. По-перше, таке буває не так і часто. По-друге, ніхто не заважає включити потрібні шматки цієї ліби в програму. Он, ffmpeg окремо зараз  майже ніхто і не ставить, в xine і в gstreamer він встроєний.

Щодо вашого панегірика rpm/yum повторюю - для кожної задачі свої інструменти. А взагалі, я просив на цю тему не флеймити, нема тут про що говорити.

[Cthulhu]

http://ring0-2007.livejournal.com/4835.html(ru)

М-дя, дотепно)))

[Володимир Лісівка]

export ASSUME_KERNEL="2.4" ?

Не котить в силу багатьох причин. Всі перерахувати тут я не осилю, та й, вірогідно, не знаю я всіх.

Не треба нам цих казочок. Є ще інші змінні для підтримки сумісності, є compat- пакети зі старими бібліотеками скомпільованими для паралельної інсталяції з основними, є сирці пакетів, які завжди можна підправити, є різноманітні обгортки, які підвантажуються через LD_PRELOAD, є LD_*PATH, і т.ін.

Зворотня сумісність - це типова проблема, з якою часто стикаються, і тому вона досить добре обкатана.

Я не розумію, навіщо випускати Slackware 11, якщо реально там відмінностей на мажорну версію нема. Можна було випустити 10.1 - це було б зрозуміло. А так це чистий піар застарілого дистрибутиву.

Ви б хоча б поцікавились суттю питання, перед тим як оце писати. Останній Slackware - це 10.2, випущений більше року тому. І змін за рік - дуже багато. Підіть, почитайте чанджлоги.

Я вже почитав, це зайняло менше 5-ти хвилин. Чи у може у вас є якийсь інший список змін?

Чому я хочу використувувати свіжий дистр особливо на десктопі? А ви здогадайтесь. Я розробляю і тестую певне програмне забезпечення. І хочу чітко знати, що моя програма не глючить з новою ОС. Щоб не було такого, коли три місяці пишеш фічу, а потім виявляється, що ту фічу доведеться переписувати з нуля через викидання старої ліби з дистру.

Головою треба думати, коли щось пишеш.

Цікаво - який ще девайс можна для цього використовувати?

І відслідковувати зміни в потрібних бібліотеках (тобто від яких залежиш), і ставити їх при потребі.  Самому, не чекаючи, поки дядечко туди кривих патчів накидає.

Дуже цікаво, як я маю ці зміни відслідковувати і хто мені за це платитиме? І чому ви вважаєте що я з цією роботою справлюся краще ніж маінтейнери пакетів в дистрибутиві? І що це за дядечко (Патрік?)??

Маленька притча: нещодавно вийшов pygtk-2.10 і pyglade-2.10 з купою змін. Є такий маленький, але корисний програмний продукт під назвою Gajim, який використовує pygtk. Дивлячись на список змін pygtk, я можу відразу назвати купу покращень і оптимізацій для Gajim. А тепер здогадайтесь, від якого pygtk залежатиме наступна версія:)

І шо? Вам Slackware в цьому допоміг?

Хоча, взагалі-то викидання ліби з дистру - не аргумент. По-перше, таке буває не так і часто.

Таке буває не часто, але бібліотек дуже багато. Напр. при переїзді з X.org 6.x на 7.x дуже багато чого поплило і одна зміна зачепила і наш проект, хоча ми X-и взагалі не використовуєм. І це лише одна з проблем.

По-друге, ніхто не заважає включити потрібні шматки цієї ліби в програму. Он, ffmpeg окремо зараз  майже ніхто і не ставить, в xine і в gstreamer він встроєний.

Ви пропонуєте нам тягати за собою 6-і X-и? :-)

Щодо вашого панегірика rpm/yum повторюю - для кожної задачі свої інструменти. А взагалі, я просив на цю тему не флеймити, нема тут про що говорити.

Ну от власне, що rpm та yum/apt/smart/etc. - це інструменти, які відсутні в Слаці. Тому ми і не використовуємо Слаку. Слака - застарілий (не старий) дистрибутив.

[Cthulhu]

Не треба нам цих казочок.

Думаю, вам краще задуматись про сувору реальність. Продукт пропрієтарний, використовує закриті технології які пацюють тільки з 2.4. Це тільки одна причина. Вірогідно, існують інші - там такий комбайн, що я всі його можливості не осилив, не кажучи вже про те, щоб весь код перечитати. И?

Зворотня сумісність - це типова проблема, з якою часто стикаються, і тому вона досить добре обкатана.

Природно.

Я вже почитав, це зайняло менше 5-ти хвилин. Чи у може у вас є якийсь інший список змін?

Я за вас страшенно радий, що ви такий прудкий (за 5 хвилин!!!), шкода лишень, що не почитали перед попереднім вашим повідомленням. Списочок там потужний... Чи ви тільки список оновлених пакетів переглянули? Тоді справді в 5 хвилин можна вкластись. Але ж основні зміни якраз не там, це так, підтримка...

Якби ви хоч для інтересу спробували покористуватись слакою... Але такого свята я точно не дочекаюсь:)

Цікаво - який ще девайс можна для цього використовувати?

Не знаю. На лорі кажуть, що можна:)

Дуже цікаво, як я маю ці зміни відслідковувати і хто мені за це платитиме?

Відповідь на питання "як?": мовчки. Знаєте, є такі корисні речі - розсилки, rss... Відповідь на питання "хто?": той, хто завжди платить. Якщо ж ви пишете JFF, тo питання взагалі відпадає (хоча воно й так значною мірою надумане).

І чому ви вважаєте що я з цією роботою справлюся краще ніж маінтейнери пакетів в дистрибутиві?

У майнтейнерів конкретна задача - робити стабільний дистрибутив, щоб існуючі програми нормально працювали. Ще ненаписане нікого не цікавить. У вас задача - писате нове програмне забезпечення. Вловлюєте різницю?

І що це за дядечко (Патрік?)??

Ще раз ознайомтесь з повідомленнями в цьому треді:) Політика Патріка - використовувати тільки офіційні релізи пакетів без сторонніх змін (за виключенням найдрібніших в пакетах, на які забили розробники, або якщо є конкретна людина, що береться оце майнтейнити). І не тому, що, як висловився пан gvy, не осилив (патчів можна і з інших дистрів до посиніння накидати), а тому що тоді чітко зрозуміло, хто винен у неправильній функціональності конкретного пакету. Пам'ятаєте недавні події з firefox в Debian? Тепер тамтешнім розробникам доведеться, фактично, майнтейнити повноцінний форк вогнелиса, і не думаю, що багів від цього сильно поменшає. Автори ж GPL проектів не можуть вчинити як Mozilla, але не думаю, що їм подобається розгрібати багрепорти про не їхні помилки. Тобто головна проблема сторонніх патчів - нема кому капати на мозок, коли щось не працює (якщо у вас оплачений комерційний дистр - то, звичайно, є:)).

І шо? Вам Slackware в цьому допоміг?

Емоційне висловлювання через повну відсутність аргументів До речі, під слакою це легко і швидко робиться не ламаючи систему пакетів.

Ви пропонуєте нам тягати за собою 6-і X-и? :-)

Я приклад трошки про друге наводив... Не можу нічого пропонувати, бо не знаю специфіки вашого проекту. Таке, як правило, не є потрібним. І потім, хто там говорив про зворотну сумісність?

Ну от власне, що rpm та yum/apt/smart/etc. - це інструменти, які відсутні в Слаці. Тому ми і не використовуємо Слаку. Слака - застарілий (не старий) дистрибутив.

Порівняли... з пальцем... Інструменти типу yum мають зовсім інше призначення, ніж pkgtools та rpm (до речі, чого ви вліпили rpm з yum в  один ряд?). Перші - це системи поновлення операційної системи без додаткових зусиль з боку користувача, і існують їх цілком повноцінні аналоги під Slackware (інша справа, що я для себе не бачу сенсу їх використувати, на даному етапі). pkgtools, rpm, deb - системи, основною задачею якої є (не рахучуючи різних побічних можливостей - типу rpmbuild) тримати файлову систему в чистоті. Тому оце от ваше висловлювання, м'яко кажучи, необгрунтоване.

[Володимир Лісівка]

Не треба нам цих казочок.

Думаю, вам краще задуматись про сувору реальність. Продукт пропрієтарний, використовує закриті технології які пацюють тільки з 2.4. Це тільки одна причина. Вірогідно, існують інші - там такий комбайн, що я всі його можливості не осилив, не кажучи вже про те, щоб весь код перечитати. И?

Досить вже казочки розказувати. Продукт закритий але платформа відкрита. Можна зібрати нову конфігурацію, яка працюватиме точнісінько так само, як стара. В гіршому випадку qemu vmlinuz-2.4 ...

Я за вас страшенно радий, що ви такий прудкий (за 5 хвилин!!!), шкода лишень, що не почитали перед попереднім вашим повідомленням. Списочок там потужний... Чи ви тільки список оновлених пакетів переглянули? Тоді справді в 5 хвилин можна вкластись. Але ж основні зміни якраз не там, це так, підтримка...

Хтось тут про стабільність Слаки розказував...  

Я читав офіційний changelog на Slackware.com. Одна людина _фізично_ не в стані зробити великий об'єм роботи, тому він часто помиляється і тому його часто поправляють. Патрік навіть Гном викинув зі Слаки, щоб зменшити навантаження на себе (розумна ідея - але чому лише Gnome?).

Якби ви хоч для інтересу спробували покористуватись слакою... Але такого свята я точно не дочекаюсь:)

Щоб я сповз з SysV на BSD-style? Знущаєтесь?

Дуже цікаво, як я маю ці зміни відслідковувати і хто мені за це платитиме?

Відповідь на питання "як?": мовчки. Знаєте, є такі корисні речі - розсилки, rss...

О, дякую що повідомили, а то мені всі новини по телеграфу доставляли.

Відповідь на питання "хто?": той, хто завжди платить. Якщо ж ви пишете JFF, тo питання взагалі відпадає (хоча воно й так значною мірою надумане).

JFF я підтримую LOU, а на роботі співвідношення об'єм/час роботи дуже важливе.

І чому ви вважаєте що я з цією роботою справлюся краще ніж маінтейнери пакетів в дистрибутиві?

У майнтейнерів конкретна задача - робити стабільний дистрибутив, щоб існуючі програми нормально працювали. Ще ненаписане нікого не цікавить. У вас задача - писате нове програмне забезпечення. Вловлюєте різницю?

Звичайно. Саме тому майнтейнеру - майнтейнерово. Я не збираюся дублювати їхню роботу. Якби Патрик користувався послугами майнтейнерів, як це роблять в інших дистрибутах, Слака б розвивалася значно швидше.

І що це за дядечко (Патрік?)??

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

Патрік?

Дистрибутив повинен мати свою філософію, а не бути зборищем пакетів. Пакети повинні вирівнюватися під дистрибутив а не дистрибутив прогинатися під пакети.

Пам'ятаєте недавні події з firefox в Debian? Тепер тамтешнім розробникам доведеться, фактично, майнтейнити повноцінний форк вогнелиса, і не думаю, що багів від цього сильно поменшає.

В Debian своя філософія. І пакети або дотримуються її, або їх переписують. Debian зробив для руху GNU більше ніж усі інші дистрибутиви разом взяті. Щодо багів - їх буде або стільки само як Firefox (бо всі латки підуть і в Debian) або менше (бо не всі латки від Debian підуть в Mozilla Foundation). Скоріше за все їх буде менше, тому що при портуванні пакетів на різні архітектури виловлюється купа помилок.

Ну хіба ви зможете назвати в якості прикладу якийсь пакет, якому перебування в проекті Debian зашкодило. :-)

Автори ж GPL проектів не можуть вчинити як Mozilla, але не думаю, що їм подобається розгрібати багрепорти про не їхні помилки.

Зате їм подобається приймати вже готові й відтестовані латки.

Неправильні багрепорти приходять від некваліфікованих користувачів, від яких все-одно мало толку.

Ви ще б спамерів повісили на майнтейнерів.

Тобто головна проблема сторонніх патчів - нема кому капати на мозок, коли щось не працює (якщо у вас оплачений комерційний дистр - то, звичайно, є:)).

Ви що - слакварист? Проблеми з пакетом слід вирішувати з майнтейнером пакету шляхом надсилання вже готової латки або хоча б звіту про помилку.

Крім того - ну поправлять автори помилку, ну скажуть - юзайте glubc-2.5, а ви ї м - не можу, Патрік сказав що 2.3 - рулез. І що ви робитимете - чекатимете 13-ї Слаки? Чи поміняєте дистрибутив на якийсь інший - з більш розумною політикою?

І шо? Вам Slackware в цьому допоміг?

Емоційне висловлювання через повну відсутність аргументів До речі, під слакою це легко і швидко робиться не ламаючи систему пакетів.
[/quote]
Ніби це важко робити в будь-якому іншому пакетизованому дистрибуті. :-)

Ви пропонуєте нам тягати за собою 6-і X-и? :-)

Я приклад трошки про друге наводив... Не можу нічого пропонувати, бо не знаю специфіки вашого проекту. Таке, як правило, не є потрібним. І потім, хто там говорив про зворотну сумісність?

Зі зворотньою сумісністю нічого не трапилося. Я цю проблему легко залатав без змін в коді програми. Зміни я внесу потім - коли ми повністю злізем з FC4.

Ну от власне, що rpm та yum/apt/smart/etc. - це інструменти, які відсутні в Слаці. Тому ми і не використовуємо Слаку. Слака - застарілий (не старий) дистрибутив.

Порівняли... з пальцем... Інструменти типу yum мають зовсім інше призначення, ніж pkgtools та rpm (до речі, чого ви вліпили rpm з yum в  один ряд?).

І yum і rpm призначені для того, щоб легко встановити/оновити/видалити пакет (rpm) чи групу пакетів(yum). Yum/apt/etc. просто спрощують роботу з великими об'ємами rpm-ок.

Перші - це системи поновлення операційної системи без додаткових зусиль з боку користувача, і існують їх цілком повноцінні аналоги під Slackware (інша справа, що я для себе не бачу сенсу їх використувати, на даному етапі).

Я найчастіше використовую yum для того щоб встановити якусь програму з усіма залежностями маючи на руках лише її назву (а то і її не маючи) і тримати її в актуальному стані. При чому я встановлюю пакети не тільки в систему але й в різні chroot-и, використовуючи одне й те саме джерело пакетів.

Оновлення системи - це важлива частина yum/apt/etc, але не домінуюча.

pkgtools, rpm, deb - системи, основною задачею якої є (не рахучуючи різних побічних можливостей - типу rpmbuild) тримати файлову систему в чистоті. Тому оце от ваше висловлювання, м'яко кажучи, необгрунтоване.

Я дуже часто використовую ці "побічні можливості", тому я м'яко кажучи здивований такою заявою, хоча якщо ви такими утилітами не користуєтесь, то зрозуміти можна.  

Мене не стільки цікавить чистота файлової системи (до того ж rpm смітить в багатьох випадках, напр. файлами *.rpmsave, *.rpmnew) як автоматизм та надійність  роботи і повторюваність результатів.

[Cthulhu]

Досить вже казочки розказувати. Продукт закритий але платформа відкрита. Можна зібрати нову конфігурацію, яка працюватиме точнісінько так само, як стара. В гіршому випадку qemu vmlinuz-2.4 ...

Володимир, ви якийсь, вибачте, блаженний. Я вам про реальний світ (з метрикою Мінковського, залізом, ресурси якого обмежені, наркоманією, програмними монстрами, які задовбешся переносити, пропрієтарщиною, де слово замовника - закон, а в нього повна... м-м-м... свої потреби і атомними боєголовками), ви мені про сферичних коней в ідеальному вакуумі. (До речі, за "qemu vmlinuz-2.4" дякую, довго валявся під столом... )
Добре. Не буду я вам тут нічого розписувати, все одно не повірите -  сходіть в Palm/WSI (ви ж на SoftServe працюєте?) і розпитайте в людей, які працюють над цим прямо зараз. Можете запропонувати їм ноу-хау: запустити TVI під qemu:)

Я дуже часто використовую ці "побічні можливості", тому я м'яко кажучи здивований такою заявою, хоча якщо ви такими утилітами не користуєтесь, то зрозуміти можна.  

Користуюсь. Але, якщо викинути з rpm можливість rpmbuild, то з системою пакетів, інсталяціями, апдейтами тощо нічого ж не зробиться? Значить просто побічна приємна фіча.

Щоб я сповз з SysV на BSD-style? Знущаєтесь?

Якби Патрик користувався послугами майнтейнерів, як це роблять в інших дистрибутах, Слака б розвивалася значно швидше.

Дистрибутив повинен мати свою філософію, а не бути зборищем пакетів. Пакети повинні вирівнюватися під дистрибутив а не дистрибутив прогинатися під пакети.

В Debian своя філософія. І пакети або дотримуються її, або їх переписують.

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