Slackware 11

[Sanya]

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

У мене абсолютно протилежна думка

[Sanya]

Слака на distrowatch займає 9-е місце и це про щось вже говорить.
На Слаку переліз бо не люблю rpm(його залежності) & SysV(там все запутано) и мені подобається її консервативність. Слака гарна своєю простотою

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

Слака на distrowatch займає 9-е місце и це про щось вже говорить.

Про те, що ще трохи - й Слака вилетить з першої десятки під тиском таких дистрибутів як Ubuntu(Debain) - 1 місце,  OpenSuSE - 2, Fedora - 3, та інших.

На Слаку переліз бо не люблю rpm(його залежності) & SysV(там все запутано) и мені подобається її консервативність. Слака гарна своєю простотою

Залежності rpm дуже допомагають отримати працюючу систему заточену спеціально під конкретне завдання. Ми, напр., задаємо в якості цілі для yum тільки один пакет, а він вже підтягує своїми залежностями всю систему. В результаті - нічого зайвого і ніякої ручної роботи.

Щодо "запутаності" SysV - rpm легко дозволяє встановити який пакет є власником конфігураційного файлу та які конфігураційні файли та документацію має пакет. Так що ніяких проблем у мене досі не виникало. А можливість автоматично встановлювати систему яка готова до роботи відразу після встановлення значно спрощує життя.

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

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

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

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

До речі, в режимі "qemu vmlinuz" qemu фактично працює як віртуалізатор а не емулятор і по швидкодії та надійності цілком придатний для роботи - я проводив відповідні тести, коли вибирав систему віртуалізації для нашого проекту (ми зупинилися на VServer). Напевно там дійсно дуже крутий проект, якщо їм не підходить те, що підходить решті нормальних людей. ;-)

Якщо їм потрібно буде пускати цю приблуду на іншій апаратній платформі, то вони від qemu нікуди не дінуться.

В будь-якому випадку, GNU/Linux - відкрита платформа, і там завжди можна підкрутити код в потрібну сторону. В мене, принаймні, суттєвих проблем з цим не виникало (а я з ними стикаюся досить регулярно).

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

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

Зробится, тому що rpmbuild робить багато суттєвих перевірок та автоматично додає необхідні залежності до пакетів. Без нього якість пакетів суттєво впаде, відповідно імовірність збою при встановлені/оновлені суттєво виросте, відповідно від yum/apt/smart буде зовсім мало користі. Витягуєш rpmbuild і Fedora з FedoraExtras розсипаються як картковий будиночок. Я зрозуміло розтлумачив?

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

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

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

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

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

В нас на сервері є розділ для ісо-шок з дистрами. Там є каталоги для ~50 дистрів, але слаки серед них нема.

Я знайомився з BSDStyle на FreeBSD-ці 4-ій.

[Cthulhu]

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

Не сумніваюсь.

До речі, в режимі "qemu vmlinuz" qemu фактично працює як віртуалізатор а не емулятор і по швидкодії та надійності цілком придатний для роботи - я проводив відповідні тести, коли вибирав систему віртуалізації для нашого проекту (ми зупинилися на VServer). Напевно там дійсно дуже крутий проект, якщо їм не підходить те, що підходить решті нормальних людей. ;-)

Власне, 2.4 - то є вимога інженерів і/або менеджерів WSI, те чудо зав'язане на дуже специфічні залізяки (дуже весело було програмувати речі, з ними пов'язані, коли самих залізяк нема. Добре, хоч не драйвери))) і rhel3. Я, власне, спочатку (поки не взявся до роботи) хотів поставити щось новіше, хай з відкотами деяких пакетів, хоч мені й популярно пояснили, що так робити не треба... Поки не побачив, скільки воно важить і ресурсів жере. Про емуляцію я взагалі не думав, був переконаний, що неюзабельно.

Зробится, тому що rpmbuild робить багато суттєвих перевірок та автоматично додає необхідні залежності до пакетів. Без нього якість пакетів суттєво впаде, відповідно імовірність збою при встановлені/оновлені суттєво виросте, відповідно від yum/apt/smart буде зовсім мало користі. Витягуєш rpmbuild і Fedora з FedoraExtras розсипаються як картковий будиночок. Я зрозуміло розтлумачив?

М-да? Не знав, що воно там так інтегровано... Дякую за інформацію.

В нас на сервері є розділ для ісо-шок з дистрами. Там є каталоги для ~50 дистрів, але слаки серед них нема.

Тобто як - нема?? Я ж там навіть zenwalk раз бачив. Може, вже потерли...

Я знайомився з BSDStyle на FreeBSD-ці 4-ій.

М-м-м... це трошки різні речі... Ви в курсі, що слака цілком і повністю сумісна з SysV-скриптами, і, більше того, деякі включені в типову "коробочну" інсталяцію? Нариклад, cups там саме так завантажується.

[Cthulhu]

Слака на distrowatch займає 9-е місце и це про щось вже говорить.

Про те, що ще трохи - й Слака вилетить з першої десятки під тиском таких дистрибутів як Ubuntu(Debain) - 1 місце,  OpenSuSE - 2, Fedora - 3, та інших.

Як, поясніть ви мені, це має статись, коли вони і так вище:) У слаки своя сформована аудиторія, і не думаю, що народ зі слаки дружно ламанеться (якщо ламанеться) на перераховані вами. Скоріше вже на Debian/Arch/Gentoo/Zenwalk.

[Sanya]

Слака на distrowatch займає 9-е місце и це про щось вже говорить.

Про те, що ще трохи - й Слака вилетить з першої десятки під тиском таких дистрибутів як Ubuntu(Debain) - 1 місце,  OpenSuSE - 2, Fedora - 3, та інших.

На Слаку переліз бо не люблю rpm(його залежності) & SysV(там все запутано) и мені подобається її консервативність. Слака гарна своєю простотою

Залежності rpm дуже допомагають отримати працюючу систему заточену спеціально під конкретне завдання. Ми, напр., задаємо в якості цілі для yum тільки один пакет, а він вже підтягує своїми залежностями всю систему. В результаті - нічого зайвого і ніякої ручної роботи.

Щодо "запутаності" SysV - rpm легко дозволяє встановити який пакет є власником конфігураційного файлу та які конфігураційні файли та документацію має пакет. Так що ніяких проблем у мене досі не виникало. А можливість автоматично встановлювати систему яка готова до роботи відразу після встановлення значно спрощує життя.

РПМ розрулує залежності не погано, але яким чином? Я вже не памятаю що я ставив(якийсь відео плеєр), але ці залежності потянули MySQL бо там була та бібліотека що необхідна для роботи плеєра [smiley=cry.gif].
На рахунок SysV, то я нічого проти нього не маю и знаю що є утиліти для його налаштування(я певний час користувався Debian GNU/Linux testing), але BSD-style для мене більш зрозумілий і логічний.

З.І. Мені подобається як розрулюються залежності в *.deb дистрах

[Sanya]

В нас на сервері є розділ для ісо-шок з дистрами. Там є каталоги для ~50 дистрів, але слаки серед них нема.

Слаку треба поважати хочаб за те що вона найстаріша за всі дистри, що иснують на даний час [smiley=cool.gif]

Я знайомився з BSDStyle на FreeBSD-ці 4-ій.

Я зараз вивчаю FreBSD 6.1 і можу сказати, що в Слакі і Фрі вони відрізняються

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

РПМ розрулує залежності не погано, але яким чином? Я вже не памятаю що я ставив(якийсь відео плеєр), але ці залежності потянули MySQL бо там була та бібліотека що необхідна для роботи плеєра [smiley=cry.gif].
На рахунок SysV, то я нічого проти нього не маю и знаю що є утиліти для його налаштування(я певний час користувався Debian GNU/Linux testing), але BSD-style для мене більш зрозумілий і логічний.

З.І. Мені подобається як розрулюються залежності в *.deb дистрах

Це не залежить від формату пакету (rpm можна конвертнути в deb і навпаки без втрати інформації про залежності). Це залежить від того, що в ті пакети пихають, тобо як програми компілюють і розбивають на пакети.

В свій час пакети в RedHat велися тільки розробниками з RedHat, відповідно їм хотілося мати по менше роботи (пакетів), а проблеми з трафіком та місцем на вінчестері їх не обходили (та і зараз не обходять, це в Федорі нарешті почали звертати на це увагу). Деколи самі програми не підтримують модульну структуру, тому необов'язкові залежності принципово неможливо винести в окремий пакет.

Якщо автори дистрибутиву скомпілювали пакет із залежністю від MySQL, яка вам не потрібна, то єдиний вихід - тягати src.rpm-и і перекомпільовувати їх так як вам треба.

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

Слаку треба поважати хочаб за те що вона найстаріша за всі дистри, що иснують на даний час [smiley=cool.gif]

Коли Слака помре, найстарішим дистром стане SuSE. ;-)

Я знайомився з BSDStyle на FreeBSD-ці 4-ій.

Я зараз вивчаю FreBSD 6.1 і можу сказати, що в Слакі і Фрі вони відрізняються

Само собою, так GNU/Linux - це  SysV відсотків на 50-60 (дуже багато чого прийшло і з FreeBSD теж). Дистрибут Лінукса можна організувати в стилі BSD але ніхто ж не буде викидувати всі наробки для SysV.

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

Власне, 2.4 - то є вимога інженерів і/або менеджерів WSI, те чудо зав'язане на дуже специфічні залізяки (дуже весело було програмувати речі, з ними пов'язані, коли самих залізяк нема. Добре, хоч не драйвери))) і rhel3. Я, власне, спочатку (поки не взявся до роботи) хотів поставити щось новіше, хай з відкотами деяких пакетів, хоч мені й популярно пояснили, що так робити не треба... Поки не побачив, скільки воно важить і ресурсів жере.

Попросіть щоб вам доставили пам'яті.

Про емуляцію я взагалі не думав, був переконаний, що неюзабельно.

Вам емуляцію ніхто і не пропонував. s/емуляцію/віртуалізацію/?

Зробится, тому що rpmbuild робить багато суттєвих перевірок та автоматично додає необхідні залежності до пакетів. Без нього якість пакетів суттєво впаде, відповідно імовірність збою при встановлені/оновлені суттєво виросте, відповідно від yum/apt/smart буде зовсім мало користі. Витягуєш rpmbuild і Fedora з FedoraExtras розсипаються як картковий будиночок. Я зрозуміло розтлумачив?

М-да? Не знав, що воно там так інтегровано... Дякую за інформацію.

Інтеграція тут ні до чого. Це банальний QA, який виконується автоматично.

Інший приклад - до того як з'явився mock, часто не вдавалося зібрати пакет з src.rpm через те, що розробник забувся вписати якусь залежність. Зараз таких проблем не виникає, відповідно вже можна починати бавитися з такими програмами як apt-src. Mock, в даному випадку, - ключовий елемент, який дозволяє роботу apt-src.

Я знайомився з BSDStyle на FreeBSD-ці 4-ій.

М-м-м... це трошки різні речі... Ви в курсі, що слака цілком і повністю сумісна з SysV-скриптами, і, більше того, деякі включені в типову "коробочну" інсталяцію? Нариклад, cups там саме так завантажується.

Ну а куди вона дінеться? :-)
Але проблема не в /etc/init.d/ а в шаблоні ".d". BSD-ники люблять складувати все в один файл, що створює купу проблем при автоматичному конфігуруванні. ".d" дозволяє покласти конфіг в пакет і не заморочувати собі голову.

[Cthulhu]

Попросіть щоб вам доставили пам'яті.

Я на ss вже не працюю. Та й не допоможе - TVI, приміром, на старті (причому, з вимкненням деяких сервісів) жере > 1G. На моїй машині стояло два, гальмувало непогано. Скільки ще туди запропонуєте впихнути?

Вам емуляцію ніхто і не пропонував. s/емуляцію/віртуалізацію/?

Угу.

вже можна починати бавитися з такими програмами як apt-src. Mock, в даному випадку, - ключовий елемент, який дозволяє роботу apt-src.

М-м-м... Генту?

Але проблема не в /etc/init.d/ а в шаблоні ".d". BSD-ники люблять складувати все в один файл, що створює купу проблем при автоматичному конфігуруванні. ".d" дозволяє покласти конфіг в пакет і не заморочувати собі голову.

Так я й кажу! Ніхто і ніщо не заважає з чистою совістю впихнути в пакет скрипт, і він буде виконуватись "з коробки". Якщо ж ставиться якась мегаекзотика і без своїх скриптів... все одно доведеться писати свій.

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

вже можна починати бавитися з такими програмами як apt-src. Mock, в даному випадку, - ключовий елемент, який дозволяє роботу apt-src.

М-м-м... Генту?

А як же ж Слака? ;-)

Але проблема не в /etc/init.d/ а в шаблоні ".d". BSD-ники люблять складувати все в один файл, що створює купу проблем при автоматичному конфігуруванні. ".d" дозволяє покласти конфіг в пакет і не заморочувати собі голову.

Так я й кажу! Ніхто і ніщо не заважає з чистою совістю впихнути в пакет скрипт, і він буде виконуватись "з коробки". Якщо ж ставиться якась мегаекзотика і без своїх скриптів... все одно доведеться писати свій.

Нічого не зрозумів. При чому тут скрипти?

В програмуванні є таке поняття як "гарячий файл" - це файл, який часто редагується. З практики відомо, що такі файли створюють проблеми і від них треба позбуватися використовуючи той же ж ".d"-патерн. Напр. в Tomcat-і зробили один server.xml на всю конфігурацію, і щоб щось поміняти треба туди лізти й правити руками. В Апачі зробили (нарешті) conf.d, в який можна просто скинути файлик.

BSD way - все складуєм в один великий, добре відкоментований конфіг, щоб людина могла легко внести зміни.

SysV way - все розкидуєм по окремим файлам/каталогам, щоб машина легко могла внести зміни замість людини.

Саме тому BSD-ники волають про "незрозумілість" конфігів SysV.

У нас напр. коли новий адмін прийшов і йому дали завдання якусь програмуліну з крона викликати, то він відразу поліз редагувати системний /etc/crontab.   Повбивав би.

[gvy]

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

А ось тут ви жорстоко помиляєтесь. Зараз у світі існує...[/quote]
Скажімо так, я трохи в курсі.  А ще в нас унікальні modutils, які працюють від 2.2 до 2.6 -- це про щось каже?

Про що, власне, мова. Є тестові дистрибутиви. І є дистрибутиви для роботи. Слака належить до тої ж категорії, що і Debain stable, і rhel

Та ладно.

– це дитсрибутив який а) ніколи не глючить, не падає і б) всі граблі, які є, давно виправлені і задокуменовані. Єдине що, можливо, вводить вас в оману – що у слаки немає тестового дистру. Розробляє і тестує його дуже обмежена громада. А ви пропонуєте запинути туди нетестоване програмне забезпечення.

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

А проект однієї людини в наш збіднілий гераклами час не буває таким, що не глючить, не падає та ще й комусь потрібний при цьому :-(

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

А в мене такого й не буває.  Тобто іноді буває, що думаю, що то ОС глючить, але швидко з'ясовується, що то thinko, typo чи інша локальна проблема.

Відкрити секрет?  Якщо розробляти щось на тухлятині, то воно за два роки буде вимагати суттєвих зусиль на підтримку, якщо це не вимкнений археологічний лінукс у боксі в стінці.  Особливо якщо якась гидота на кшталт Python чи C++ використовується :-(

Якщо ж розробляти на unstable, але маючі оцінку того, коли воно стане stable та синхронізуючи таймлайни -- то цей тип додаткових розтрат часу зменшується.  Авжеж, в мене досить пакунків, деякі з котрих не потребують уваги роками -- але небагато апстримів *так* пишуть...

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

То радий за Вас :-)  От тількт як тиснути почне -- не видумуйте щось на тому, озірніться.

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

Ууу...  Ну то подивіться на lafox.net/support, не буду розвивати тему дружньої спільноти українських слакваристів.  То Ви може й Дмитра Глазова не знаєте зовсім?..

O tempora o mores. (keywords: linux-list dyug)

[gvy]

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

Тю, а ти не знав?

http://wiki.sisyphus.ru/devel/spectips/triggers [ru]
та було в Maximum RPM й документації rpm (manual/triggers)

Приклад -- e.g. http://alt.linux.kiev.ua/srpm/webalizer/spec (здуру видаляв користувача в %postun попередньої збірки, від чого внаслідок специфічного, хоча й документованого та досить логічного, порядку виконання пакункових скриптів старої та нової збірки після поновлення залишавсь без псевдоюзера -- тобто ніколи не роби %postun userdel!

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

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

В нас десь із 2003 був sandman, який інтегрований з CVS та ProjectView (форк dotProject).  Так, трохи є й ця будується принаймні таким самим чином із урахуванням проблем відомих попередників, як і отой git.