Серверний лінукс

[gvy]

А щодо опитування, то на мою думку для Слаки там має бути місце оскільки її популярність є досить високою

Слака - чудовий десктоп (хоча я вже кілька місців облизуюсь в бік арча), а от на сервері - IMO це ССЗБ, хоча я можу помилятись - досвіду такого не маю.

Популярність слаки роздмухується нувославоводами без зайвої розумної аргументації  Це скоріш емоційно-вірусне явище на кшталт "два мільони лемінгів"

(хто спробує мене на тому зохавати -- сперш аргУменти в студію, pls

[gvy]

Я на попередній роботі підняв офіс на Debian Etch + LTSP5. Спочатку (під час підготовки) там був LTSP4.2, але коли почали працювати - перелізли на 5. Можете спитати gvy - він особисто бачив що я там робив.

LTSP в тебе робив, а от головного -- виперти фрю з заліза, де вона не робить -- ти не зробив

Можеш підказати, що в нас на такому добре робить, а ще коли брали залізку на апгрейд веб-сервера -- там в людей ще буде SAS-контролер з дисками, можеш порадити своїм екс-колегам щодо дискової підсистеми.  Бо FreeBSD та SATA при тому навантаженні на тому залізі -- це вішалка.  Потестуватися можна в нашому офісі десь до середини серпня, думаю.

[Sanya]

...
А щодо брендових серверів - в мене теж на роботі SLES на брендовому сервері, якби мене до нього пустили - був би Дебіан. А то якось гидко від SLES на брендовому сервері - це скоріш система для початківців на домашні мережі в 3 компа.
...

До речі на твоїй роботі(Львівська Політехніка) на SLES крутяться сервіси Novell і ставити туди Debian може тільки такий фанатик як ти

[Sanya]

Я на попередній роботі підняв офіс на Debian Etch + LTSP5. Спочатку (під час підготовки) там був LTSP4.2, але коли почали працювати - перелізли на 5. Можете спитати gvy - він особисто бачив що я там робив.

LTSP в тебе робив, а от головного -- виперти фрю з заліза, де вона не робить -- ти не зробив

Можеш підказати, що в нас на такому добре робить, а ще коли брали залізку на апгрейд веб-сервера -- там в людей ще буде SAS-контролер з дисками, можеш порадити своїм екс-колегам щодо дискової підсистеми.  Бо FreeBSD та SATA при тому навантаженні на тому залізі -- це вішалка.  Потестуватися можна в нашому офісі десь до середини серпня, думаю.

  у нас залишилась ще одна FreeBSD їй ще залишилось жити 1-2 тижні

[Cthulhu]

(хто спробує мене на тому зохавати -- сперш аргУменти в студію, pls

Таки спробую.

Популярність слаки роздмухується нувославоводами без зайвої розумної аргументації  Це скоріш емоційно-вірусне явище на кшталт "два мільони лемінгів"

Звичайно, так. Але, тут слово "слака" можна замінити будь-яким іншим. За моїми спостереженнями червоноокість користувачів ніяк не корелюється з дистрибутивом, просто на слаці тупо більше початківців. Чому - питання інше. В основному завдяки деяким характерним мінусам і плюсам слаки.

Якщо говорити про плюси - це в першу чергу система пакетів (любителям розказувати про make install та слаку - марш ботати матчастину). Пакет дуже легко створити, на що існує ціла купа способів, модифікувати, перепакувати etc. Вся база пакетів з індексом підконтрольних файлів лежить в /var/log/packages, всі скрипти - /var/log/scripts. Залежності контролюються не всередині пакетів, а зовнішніми скриптами установки, які теж надзвичайно просто контролювати. Найкраще рішення, що існує на цю тему - zenwalk netpkg. Ну і ще - немає розділу на devel-пакети. Все це робить слаку надзвичайно приємним дистрибутивом для розробки.

А от тепер про мінуси... Простота редагування конфігів, я в першу чергу маю на увазі BSD-скрипти, є значною мірою вигаданою. Оскільки початківець з ними нічого особливого не робить, це видається дуже простим і природним. В цьому місці починаються граблі. Коротко їх можна охарактеризувати так: на даному етапі BSD скрипти перестали бути такою зручною штуковиною, як були колись. Крапка.

Не так давно я змушений був відлагоджувати rc.inet1, а потім і rc.uwd скрипти в zenwalk-4.6.0beta1. Чесно зізнаюсь - за дві години цього нездорового заняття я всерйоз подумував знайти того, хто це придумав, і здійснити над ним фізичне насильство. Справа в тому, що складність скриптів зростає обернено пропорційно до їх кількості. В результаті, коли виникає необхідність прикрутити всякі сучасні цяцьки, розробники роблять там купу помилок. В релізах воно вже більш-менш вилизане, але факт наявності помилок це не відміняє, і виникають всякі милі речі типу затирання fstab.

[Абрамчук Вадим]

...
А щодо брендових серверів - в мене теж на роботі SLES на брендовому сервері, якби мене до нього пустили - був би Дебіан. А то якось гидко від SLES на брендовому сервері - це скоріш система для початківців на домашні мережі в 3 компа.
...

До речі на твоїй роботі(Львівська Політехніка) на SLES крутяться сервіси Novell і ставити туди Debian може тільки такий фанатик як ти

А то я не в курсі, що в мене тут SLES . Сам працюю з eDirectory (в основному через LDAP), і мені вже просто-напросто набридло спостерігати шаманство своїх коллег у спробах змусити його працювати. Так, я фанатик. Я фанатик двох речей - нормального ПЗ і сигарет Camel. Ну що ж, холліваримо далі!

Оффтоп: як добре, що мій основний напрям - FreeBSD  

[Sanya]

...
А щодо брендових серверів - в мене теж на роботі SLES на брендовому сервері, якби мене до нього пустили - був би Дебіан. А то якось гидко від SLES на брендовому сервері - це скоріш система для початківців на домашні мережі в 3 компа.
...

До речі на твоїй роботі(Львівська Політехніка) на SLES крутяться сервіси Novell і ставити туди Debian може тільки такий фанатик як ти

А то я не в курсі, що в мене тут SLES . Сам працюю з eDirectory (в основному через LDAP), і мені вже просто-напросто набридло спостерігати шаманство своїх коллег у спробах змусити його працювати. Так, я фанатик. Я фанатик двох речей - нормального ПЗ і сигарет Camel. Ну що ж, холліваримо далі!

Поганому танцюристу....

[Sanya]

Оффтоп: як добре, що мій основний напрям - FreeBSD  

Як добре що мій напрямок Linux і те що FreeBSD по трохи вимирає я вже зрозумів

[Абрамчук Вадим]

Як добре що мій напрямок Linux і те що FreeBSD по трохи вимирає я вже зрозумів

ЩО???
Фрішка вимирає? Чоловіче, ви звідки впали? :-?
Linux ніколи не буде мати такої швидкості і надійності, як FreeBSD.

[niii]

Linux ніколи не буде мати такої швидкості і надійності, як FreeBSD.

 
Ага вмира  
ви чили про генту ?

[Sanya]

Як добре що мій напрямок Linux і те що FreeBSD по трохи вимирає я вже зрозумів

ЩО???
Фрішка вимирає? Чоловіче, ви звідки впали? :-?
Linux ніколи не буде мати такої швидкості і надійності, як FreeBSD.

подивіться статистику, До речі в Уарнеті відмовились від FreeBSD на користь RHEL і по трохи преводять сервера.

А в FreeBSD нехай в першу чергу зроблять нормальну і швидку ФС, а про підтримку заліза Фряхою я взагалі мовчу, тут як то кажуть без коментарів

А якщо у вас Лінукс ненадійний і нешвидкий то виною у всьому руки

[gvy]

Популярність слаки роздмухується нувослаководами без зайвої розумної аргументації  Це скоріш емоційно-вірусне явище на кшталт "два мільони лемінгів"

Звичайно, так. Але, тут слово "слака" можна замінити будь-яким іншим. За моїми спостереженнями червоноокість користувачів ніяк не корелюється з дистрибутивом, просто на слаці тупо більше початківців. Чому - питання інше. В основному завдяки деяким характерним мінусам і плюсам слаки.

Та якраз віршам на кшталт СРПБ, про які й кажу.  Звідки новачку розуміти, де тут правда, а де -- самовпевнення?

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

Якщо говорити про плюси - це в першу чергу система пакетів (любителям розказувати про make install та слаку - марш ботати матчастину).

Плюсів не бачу, бачу мінус (пакунки є, менеджера нема -- бо package mgr без можливості контролю залежностей як директор без печатки).

Код: [Вибрати]

- А що, в Slackware Linux нема менеджера пакунків з перевіркою залежностей?
- Є, але він знаходиться ззовні комп'ютера

Ну і ще - немає розділу на devel-пакети. Все це робить слаку надзвичайно приємним дистрибутивом для розробки.

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

Код великими шматками зручний за вбогих засобів керування ним.  От як в класичному Red Hat Linux: хочеш перл -- тримай 20M .rpm bundle.  А в дебіані, альті, любому _нормальному_ дистрибутиві воно сто років як нарізане на базовий пакунок та купу (lib)perl-*, які можна класти до розробки за потребою.  Так само й з рештою.

Як це _прямо_ впливає на якість результату розробки -- можу показати на прикладі zlib.

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

Якщо те, що в нас живе в zlib-devel-static, є в системі укупі з самою zlib -- то маємо чималий шанс (залежить від травм мозку апстрима) отримати таку само ситуацію та статичну збірку.  Особливо для не-autotools-based та дюже кросплатформних.

Якщо *-devel-static просто не ставити без дуже чітко зрозумілої потреби, то залишається контролювати відсутність bundled libraries, незбирання з ними чи от як в ALT: є пакунок qa-robot, а в ньому -- поміж іншого аналізатор дублікатів ELF-символів, який таке ловить.

Це все не тільки для zlib актуально й не тільки для окремих софтинок -- коли весь репозиторій вкритий таким QA, його придатність для розробки якісних рішень зростає на порядок.

Ще розповісти чи вже є над чим подумати?

А от тепер про мінуси... Простота редагування конфігів, я в першу чергу маю на увазі BSD-скрипти, є значною мірою вигаданою.

Та редагувати й sysv можна, але зазвичай просто не треба.

Не так давно я змушений був відлагоджувати rc.inet1, а потім і rc.uwd скрипти в zenwalk-4.6.0beta1. Чесно зізнаюсь - за дві години цього нездорового заняття я всерйоз подумував знайти того, хто це придумав, і здійснити над ним фізичне насильство.

:-(

Коли набридне -- welcome на ті ж дебіан чи альт.  Й там, й там вистачає своїх родових травм, але проблеми зовсім іншого рівня, про цей вже й забули.

В альті зараз вирішують, як би зручніше зробити роботу з результатами збирання пакунків прям із git, коли git не використовується (в "звичайних" src.rpm може бути купка патчів, а в git зазвичай живуть ктулхи бранів, й в принципі можливо вести по бранчу на кожний окремий патч, який є ортогональним до решти, й отримувати з них такі само індивідуальні патчі, але тенденція така, що або upstream живе в master branch й робиться один мегапатч в звичайному стилі Debian, або іноді взагалі тарбол містить patched source -- проти чого досить багато сказано)... проблема трошечки схожа на SUSE'шні спеки, які в них породжуються автоматичною системою збірки з метаописів.

Ну тобто можна лопатити свою розробку в своєму git (самому чи з іншими, масштабується воно непогано), а коли час збирати -- однією командою сказати зробити з git-репозиторію тарбол (та за потреби патчі) й spec-файл, з них -- src.rpm, потім зробити чистенький чрут для збірки (із використанням кешу розгорнутої базової збіркової системи, якщо хеші репозиторію пакунків не змінювались), потім додати те, що вказане в спеку як необхідне для збірки, встановити зроблений src.rpm в чрут та стартувати збірку; якщо вона успішна -- витягнути пакунки з chroot та додати до окремого репозиторію із результатами.

PS: можу дати доступ у збірковий VPS на погратися.

[gvy]

Linux ніколи не буде мати такої швидкості і надійності, як FreeBSD.

Звісно, бо FreeBSD 6.x тільки-тільки дійшла до тієї комбінації, яка була властива Linux 2.2 років шість тому.  Особливо на SMP/multicore.  Куди воно рухається -- он в пана прапорщика спитайте, може, йому не ліньки буде розповісти у кольорах та фарбах.

Про масовані проблеми в ДНК архітекторів портів (починаючі з принципової відсутності можливості їх бранчити чи доробити таку можливість розумними зусиллями) -- гучно мовчу.

Ну тобто як може вмерти те, що не живе -- моя не розумійт.

PS: останню фрю з *.osdn.org.ua, мабуть, до кінця року виведемо з експлуатації.  Бо там вже нічого майже й не залишилось, все на Linux з OpenVZ або VServer, а щоб її поновити -- то простіше новий корень згенерувати.

[Cthulhu]

Плюсів не бачу, бачу мінус (пакунки є, менеджера нема -- бо package mgr без можливості контролю залежностей як директор без печатки).

Код: [Вибрати]

- А що, в Slackware Linux нема менеджера пакунків з перевіркою залежностей?
- Є, але він знаходиться ззовні комп'ютера

Написати на стінці великими буквами - netpkg.

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

Код великими шматками зручний за вбогих засобів керування ним.  От як в класичному Red Hat Linux: хочеш перл -- тримай 20M .rpm bundle.  А в дебіані, альті, любому _нормальному_ дистрибутиві воно сто років як нарізане на базовий пакунок та купу (lib)perl-*, які можна класти до розробки за потребою.  Так само й з рештою.

Зараз я сиджу за RHEL 3.0 WS (Ніяк не можуть 5.0 осилити=).

rpm -qa | grep devel | wc -l
     76

Круто, да? В WS воно в основній масі йде з коробки. А от якщо треба було б щось робити на простому RHEL - то звиняйте, дядьку, ставте пакетики руцями. Red Hat - молодці, цю проблемку чудово розуміють і випускають окремий варіант дистру для розробки. А якщо такого нема?

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

Це голова нехай розробникам програми і майнтернерам пакету болить, якщо, звичайно, розробник не я=) Ця проблема вирішується. І потім...

Якщо те, що в нас живе в zlib-devel-static, є в системі укупі з самою zlib -- то маємо чималий шанс (залежить від травм мозку апстрима) отримати таку само ситуацію та статичну збірку.  Особливо для не-autotools-based та дюже кросплатформних.

...ви ще використовуєте статичну лінковку? Тоді ми йдемо до вас! І де ви бачили диструбитив з статичними лібами з коробки?

Якщо *-devel-static просто не ставити без дуже чітко зрозумілої потреби, то залишається контролювати відсутність bundled libraries, незбирання з ними чи от як в ALT: є пакунок qa-robot, а в ньому -- поміж іншого аналізатор дублікатів ELF-символів, який таке ловить.

За лінк дякую, цікаво...

Та редагувати й sysv можна, але зазвичай просто не треба.

Угу, але практика підказує, що наробити помилок в скрипті на 50 рядків важче, ніж в скрипті на 500. тільки шукати по них часом не дуже зручно.

Коли набридне -- welcome на ті ж дебіан чи альт.  Й там, й там вистачає своїх родових травм, але проблеми зовсім іншого рівня, про цей вже й забули.

Скоріше вже арч, ідеологічно мені ближче=)

[МАКС]

Усім привіт
в мене є маленьке запитання : чи знає хто як підключити до LTSP 5 (Linux Terminal Server Project) USB та клавіатуру ?
чи хоч скажіть де можна дізнатися
заздалегідь дякую.