форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка

Вариант для распечатки		Пред. тема | След. тема
Форумы Разговоры, обсуждение новостей (Public)
Изначальное сообщение		[ Отслеживать ]

"OpenNews: Решит ли возрождение проекта Berlin API проблемы с..."

Сообщение от opennews on 24-Июн-08, 16:13

Установка ПО в Linux - задача достаточно сложная и по большей части не может контролироваться даже самим пользователем системы. Раньше, когда весь софт компилировался из исходников вручную, это был хоть и долгий, но более управляемый процесс. В дальнейшем появились пакетные менеджеры, такие как rpm и dpkg, которые в силу различия форматов пакетов и репозиториев не могли работать совместно. Более того, предложение по созданию API, который бы внес единообразие в процесс инсталляции ПО, натолкнулось на сопротивление и, не получив поддержки, угасло. С предложением возобновить создание такого API выступил Denis Washington, один из разработчиков Fedora. Первоначальный проект, под названием Berlin Packaging API, не вызвал энтузиазма и Washington, взявшись за дело собственными руками, написал прототип интерфейса, назвав его LSB Package API (http://www.linuxfoundation.org/en/LSB_Package_API). В основе лежит интерфейс D-Bus и описание пакета в формате XML файла. На данный момент реализация п... URL: http://www.osnews.com/story/19901 Новость: http://www.opennet.dev/opennews/art.shtml?num=16620

Высказать мнение | Ответить | Правка | Cообщить модератору

Сообщения по теме

[Сортировка по времени | RSS]

1. "Решит ли возрождение проекта Berlin API проблемы с инсталляц..."

Сообщение от trey on 24-Июн-08, 16:13

>Установка ПО в Linux - задача достаточно сложная и по большей части не может контролироваться даже самим пользователем системы. как страшно жить...

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	24. "Решит ли возрождение проекта Berlin API проблемы с инсталляц..."
	Сообщение от xcode on 24-Июн-08, 21:25
	>Установка ПО в Linux - задача достаточно сложная и по большей части не может >контролироваться даже самим пользователем системы. Уу, охренеть как сложно, особенно в моей кубунте.Жмем K -> add\remove и ставим.Даже по категориям разложено - там мультимедия, а там - графика.Или если крутые запускаем adept или aptitude.А при попытке послушать MP3 плеер сам предложет втулить кодеки :).Вообще, нереально зубодробильно в управлении! Если у редхата и федоры вечные грабли с софтом, они что, хотят чтобы другие за них решали их проблемы?Лично мне за глаза хватает .deb пакетов для убунты, как и для дебиана а dpkg показал себя достаточно адекватным и удобным пакетным манагером который тем не менее довольно сложно убить.Во всяком случае за 2 года юзания убить его не вышло.Было пару сбоев но он еще и подсказывает как чинить если из консоли пнуть :).Кроме того dpkg в отличие от некоторых других постепенно и плавно эволюционирует а не перекореживается каждый раз до неузнаваемости.И потому в отличие от редхата нет у других этих проблем.Ну вот они и не дергаются. А вот редхату хочется сказать свое "фи" за то что они постоянно перекореживают свои пакетные манагеры.Они хотят чтобы у всех было так же хреново как у них?Спасибо им большое... но у меня по этому поводу энтузазизма как раз тоже нет.Шли б они в ... с их иксэмэлками и дэбасами.Работает - не трожь!А то потом и у других будет такой же трах с постоянным освоением новых версий пакетных тулзов.Нафиг-нафиг...
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	27. "Решит ли возрождение проекта Berlin API проблемы с инсталляц..."
	Сообщение от Анонимус on 24-Июн-08, 22:10
	>Уу, охренеть как сложно, особенно в моей кубунте.Жмем K -> add\remove и ставим.Даже по категориям разложено - там мультимедия, а там - графика.Или если крутые запускаем adept или aptitude.А при попытке послушать MP3 плеер сам предложет втулить кодеки :).Вообще, нереально зубодробильно в управлении! Только не забывай, что сон разума рождает чудовищ.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	30. "Решит ли возрождение проекта Berlin API проблемы с инсталляц..."
	Сообщение от xcode on 24-Июн-08, 22:21
	>Только не забывай, что сон разума рождает чудовищ. А уж сколько чудовищ рождают программеры... особенно это касается пакетных манагеров редхата, кстати.Я не знаю где там у них разум был но вечными перетрясками своих пакетных манагеров они малость заколебали а rpm в его разных инкарнациях просто ужасен.Что тупорылая структура пакетов что сам манагер.Вот уж кого я не стал бы ставить как эталон в плане пакетных систем так это редхат.Они IMHO представляют из себя отличный пример того как делать НЕ НАДО!И они будут учить других делать пакетные манагеры?!Упаси боже от таких учителей :\
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	36. "Решит ли возрождение проекта Berlin API проблемы с инсталляц..."
	Сообщение от borey (??) on 24-Июн-08, 22:48
	Простите. Но разложите мне пожалуйста,как сей продукт использующего, по пунктам чем rpm так уж сильно отличается от deb к примеру.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	37. "Решит ли возрождение проекта Berlin API проблемы с инсталляц..."
	Сообщение от trey on 24-Июн-08, 22:55
	>Простите. Но разложите мне пожалуйста,как сей продукт использующего, по пунктам чем rpm >так уж сильно отличается от deb к примеру. эх ты.. я уж думал что никто не попадется... Или это xcode, видя что никто не начинает спорить сейчас сам с собой от разных ников поспорит?
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	44. "*sigh*"
	Сообщение от Michael Shigorin (ok) on 25-Июн-08, 01:52
	>Что тупорылая структура пакетов что сам манагер. Уважаемый, Вас тупорыло несёт второе сообщение. dpkg несколько лучше изначально спроектирован для универсальных применений (тыскыть научный подход), а rpm -- для прикладных (инженерный).  Это выливается в разные выборы в подобных ситуациях (например, штатность возможности интерактива при установке отдельного пакета). А путать редхат, федору, RPM и .rpm в одну кашу в голове -- не следует.  При всей моей иронии относительно федоры-то. 2 trey: видите ли, убунтушники в массе своей отличаются не только повальным отсутствием сообразительности, но и тем, что их заразным образом несёт.  Вот и этого экземпляра пронесло, а кто-то ведь и купиться может.  Можно грохнуть, но бывает лучше объяснить, где неправ -- вдруг дойдёт. 2 blkdog: перевод во многих местах нелокализованный, сильно рекомендую по возможности почитать грамотно изданную литературу на аглицком (не рассылки).  E.g. "что не в этом случае" -- видимо, "это не так" (this is not the case).  Если хотите, можно попробовать порой в жабере помогать.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	70. "*sigh*"
	Сообщение от User294 (ok) on 25-Июн-08, 13:24
	>dpkg несколько лучше изначально спроектирован для универсальных применений (тыскыть научный подход), а >rpm -- для прикладных (инженерный).   Интересно, для каких прикладных задач придумывали RPM если на практике и в реальной жизни DEB удобнее?Я например оба пользовал и RPM (несколько разных версий в разных версиях CentOS) мне не понравились. >А путать редхат, федору, RPM и .rpm в одну кашу в голове >-- не следует.  При всей моей иронии относительно федоры-то. Редхат эту заварушку и заварил.Развели зоопарк да еще постоянно все перетрясают, так что там черт ногу сломит.Почему-то debian based обходятся без такого жуткого бардака.Даже IT OS на Nokia n8x0 использует стандартный манагер пакетов хоть и с своей графической мордочкой к нему, но собственно все свойства дебиановского манагера пакетов - при нем.А консольный вариант вообще ничем таким от десктопных не отличается.Вопрос: кому и нафига при этом кроме редхата надо какое-то непонятное апи если и без него проблем особых нет? >Вот и этого экземпляра пронесло, а кто-то ведь и купиться может. Объясняю в чем у вас ошибка: вы выпускаете систему на основе этого ... добра.И потому во первых нечаянно и нисколько не задумываясь делаете им скидку.Сами того не подозревая скорее всего.Во вторых вы все это знаете на уровне гуру и вам кажется что все просто и понятно.Ваша ошибка типична.Не будут люди со стороны делать скидок редхату на их кривульки.И разбираться в всем этом бардаке большей части пользователей и админов обычно неохота. > Можно грохнуть, но бывает лучше объяснить, где неправ -- вдруг >дойдёт. А вам можно сказать: у вас неплохая система.Но вот как раз базированность на редхате все портит.Если честно - простите но лично я например не верю в то что у вашей системы большое будущее.Как раз из-за основанности на редхате.Редхат что-то из себя представляет на энтерпрайз поприще а на остальные рынки даже всерьез и не пытается соваться, понимая что не переспективно это с тем что у них есть.Может конечно у вас что-то и получится.Тогда я за вас порадуюсь.Но сам я вашу систему юзал бы дома только если бы она была основана на дебиане или даже лучше (для домашнего использования) убунту.Может редхат и был хорош когда вы начинали делать вашу ос и был лучше других.А сейчас... сейчас редхат что-то из себя представляет только в энтерпрайз секторе.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	79. "*sigh*"
	Сообщение от Michael Shigorin (ok) on 26-Июн-08, 01:52
	>Интересно, для каких прикладных задач придумывали RPM Промышленные дистрибутивы, вестимо.  Он более деревянный и при этом издревле (v3, что ли) умеет подписи и контрольные суммы. >>А путать редхат, федору, RPM и .rpm в одну кашу в голове >>-- не следует.  При всей моей иронии относительно федоры-то. >Редхат эту заварушку и заварил. Да, но с тех пор она кипит довольно замысловато. >Развели зоопарк да еще постоянно все перетрясают, так что там черт ногу сломит. Самый большой бардак в rpm world -- это rpm macro hell.  Бишь то, что исходный редхатовский набор макросов уж очень убог и просто напрашивается на расширение (будучи прекрасно расширяемым).  Дальше каждый танцевал под своё сопровождение :-) Возможно, это порешают в рамках rpm5.org.  Возможно, нет.  Не берусь предсказывать. >Вопрос: кому и нафига при этом кроме редхата надо какое-то непонятное апи >если и без него проблем особых нет? API чего именно?  Впрочем, я всё равно вряд ли отвечу достаточно компетентно, но на своём уровне сборщика и внедренца могу попробовать. >Объясняю в чем у вас ошибка: вы выпускаете систему на основе этого ... добра. Есть такое. >И потому во первых нечаянно и нисколько не задумываясь делаете им скидку. Подсознательно -- скорее всего, но вообще-то именно выпуская, развёртывая и поддерживая системы на базе чего-либо -- лучше всего знакомишься с проблемами этого чего-либо. Правда, альтовский rpm очень сильно отличается от редхатовского.  Но наш майнтейнер входит в rpm5 team :) >Во вторых вы все это знаете на уровне гуру и вам кажется что все просто и понятно. Какого нафиг гуру... >Ваша ошибка типична.Не будут люди со стороны делать скидок редхату на их кривульки. И я не делаю, когда речь о кривульках.  Хотите -- поищите shigorin|gvy redhat rpm крупноблочный. Да только ни rpm, ни dpkg как инструменты управления единичными (по сути) пакетами -- где то вооооон там, далеко внизу.  Для пользователя низкий уровень -- это apt, ну или там yum какой :-) >А вам можно сказать: у вас неплохая система.Но вот как раз базированность >на редхате все портит.Если честно - простите но лично я например >не верю в то что у вашей системы большое будущее.Как раз >из-за основанности на редхате. Как бы Вам сказать... вон арабы и евреи -- они и те, и те семиты. Только почему-то слегка расходятся во взглядах.  Так и тут. Если хотите, найдите слово "исходники" здесь: http://lists.altlinux.org/pipermail/devel/2005-March/031495.... и прочтите абзац, в котором оно находится.  Это довольно ёмкое описание. >Редхат что-то из себя представляет на энтерпрайз поприще >а на остальные рынки даже всерьез и не пытается соваться, понимая >что не переспективно это с тем что у них есть. У них другие проблемы, как мне кажется.  С rpm как техсредством не связанные. Могу попробовать расписать, но это уже на статью потянет, а сейчас не вполне удобно. >Может конечно у вас что-то и получится.Тогда я за вас порадуюсь. Спасибо :-) >Но сам я вашу систему юзал бы дома только если бы она была основана >на дебиане или даже лучше (для домашнего использования) убунту. На убунте нельзя надёжно основываться, это авторитарный апстрим. Я в 2005 всерьёз такой вариант для нашей конторы обдумывал и несколько месяцев изучал обстановку.  Выводы были сделаны и с тех пор не опровергались :( >Может редхат и был хорош когда вы начинали делать вашу ос и был лучше >других.А сейчас... сейчас редхат что-то из себя представляет только в >энтерпрайз секторе. hint: альт в 2002--2003 сделал многое из того, что было уже сделано в дебиане, а в федоре и opensuse началось только пару лет как.  Начиная с мелкоблочной порезки, гораздо менее растяпистого подхода к зависимостям (поскольку в 2001 был внедрён apt параллельно, а потом и вместо *&^&*^ мандрейковского urpmi) и весьма впечатляющей разработки по их автоматическому обнаружению (как сборочных, так и установочных; как для бинарников, так и для скриптовых языков). Кстати, научная работа по зависимостям в альте тоже не имеет известных мне аналогов ни в одном из известных мне по этой части дистрибутивов.  Вместе со своим весьма практическим применением. Это важно для качества пакетной базы.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	43. "Решит ли возрождение проекта Berlin API проблемы с инсталляц..."
	Сообщение от kostbebix on 25-Июн-08, 01:43
	>[оверквотинг удален] >Если у редхата и федоры вечные грабли с софтом, они что, хотят >чтобы другие за них решали их проблемы?Лично мне за глаза хватает >.deb пакетов для убунты, как и для дебиана а dpkg показал >себя достаточно адекватным и удобным пакетным манагером который тем не менее >довольно сложно убить.Во всяком случае за 2 года юзания убить его >не вышло.Было пару сбоев но он еще и подсказывает как чинить >если из консоли пнуть :).Кроме того dpkg в отличие от некоторых >других постепенно и плавно эволюционирует а не перекореживается каждый раз до >неузнаваемости.И потому в отличие от редхата нет у других этих проблем.Ну >вот они и не дергаются. Подтвердите слова свои? Особенно про грабли в федоре с софтом) > >А вот редхату хочется сказать свое "фи" за то что они постоянно >перекореживают свои пакетные манагеры. К примеру когда они их перекореживали? >Они хотят чтобы у всех было так же >хреново как у них?Спасибо им большое... но у меня по этому >поводу энтузазизма как раз тоже нет.Шли б они в ... с >их иксэмэлками и дэбасами.Работает - не трожь!А то потом и у >других будет такой же трах с постоянным освоением новых версий пакетных >тулзов.Нафиг-нафиг... Что вы знаете о deb и rpm?
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

2. "Решит ли возрождение проекта Berlin API проблемы с инсталляц..."

Сообщение от Аноним (??) on 24-Июн-08, 16:25

"Установка ПО в Linux - задача достаточно сложная и по большей части не может контролироваться даже самим пользователем системы." Ха. Как хорощо узнать, что ты не единственный, кто видит кривизну. Осталось подождать пока заметное кол-во людей, наевшись кактусов, начнут спрашивать "а что ты там говорил про управление пакетами прикладного ПО".

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	29. "Решит ли возрождение проекта Berlin API проблемы с инсталляц..."
	Сообщение от Анонимус on 24-Июн-08, 22:21
	>Ха. Как хорощо узнать, что ты не единственный, кто видит кривизну. Осталось >подождать пока заметное кол-во людей, наевшись кактусов, начнут спрашивать "а что >ты там говорил про управление пакетами прикладного ПО". По обкурке и не то увидишь. Вопрос не в устанавливаемых пакетах, а в недостаточной единообразности подходов к установке и отсутствию стандартов и договорённостей на эту тему.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

3. "Решит ли возрождение проекта Berlin API проблемы с инсталляц..."

Сообщение от anarsoul on 24-Июн-08, 17:01

> Установка ПО в Linux - задача достаточно сложная Бред, чего сложного в пакетных менеджерах и их фронтендах? (Типа synaptic) И с какой это стороны неуправляемо пользователем системы??

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	10. "Решит ли возрождение проекта Berlin API проблемы с инсталляц..."
	Сообщение от Knuckles (ok) on 24-Июн-08, 17:30
	Думаю, под неуправляемостью подразумевается тот факт, что после автомагического разрешения 10-20 зависимостей для пакета и установки нужной тебе софтины ты вряд ли вспомнишь, что еще нужно удалить вместе с этим пакетом, чтобы вернуть "все как было". И чтоб ничего не поломать. И чтоб быстро. А пакетов мноооого... Я слышал, в последней мандриве пакетный менеджер будет определять, что пакет более не используется другими пакетами и предлагать его удаление. Не знаю, как там это будет работать, но грызут сомнения, что не идеально.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	16. "Решит ли возрождение проекта Berlin API проблемы с инсталляц..."
	Сообщение от anonymous (??) on 24-Июн-08, 17:59
	бгг, аптитуда уже давно умеет, причем по умолчанию. да и пакман тоже.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	18. "Решит ли возрождение проекта Berlin API проблемы с инсталляц..."
	Сообщение от Аноним (??) on 24-Июн-08, 18:41
	но в apt сей функционал почему-то включать не хоят
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	19. "Решит ли возрождение проекта Berlin API проблемы с инсталляц..."
	Сообщение от ewrw on 24-Июн-08, 18:54
	>но в apt сей функционал почему-то включать не хоят а что такое apt-get autoremove ?
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	39. "emerge рулит :)"
	Сообщение от himik (??) on 24-Июн-08, 23:59
	emerge в Gentoo по моему неплохо справляется с задачей кдаления неиспользуемых пакетов..
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

4. "Решит ли возрождение проекта Berlin API проблемы с инсталляц..."

Сообщение от pavlinux (ok) on 24-Июн-08, 17:11

Он думал, - зачем ставить в RedHat, пакет от Ubuntu или от SuSE в Debian???

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

5. "Решит ли возрождение проекта Berlin API проблемы с инсталляц..."

Сообщение от Дмитрий Ю. Карпов on 24-Июн-08, 17:20

Мне кажется весьма удобной система пакаджей во FreeBSD - пора бы портировать её в Linux. Впрочем, если линуксоиды будут жестоко преследовать нарушителей GPL-лицензии, мир скоро перейдёт на FreeBSD.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	6. "Решит ли возрождение проекта Berlin API проблемы с инсталляц..."
	Сообщение от Аноним (??) on 24-Июн-08, 17:24
	>мир скоро перейдёт на FreeBSD. Не перейдёт, потому что есть ArchLinux, вобравший в себя самые лучшие особенности FreeBSD
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	55. "Решит ли возрождение проекта Berlin API проблемы с инсталляц..."
	Сообщение от tux2002 on 25-Июн-08, 08:42
	>>мир скоро перейдёт на FreeBSD. > >Не перейдёт, потому что есть ArchLinux, вобравший в себя самые лучшие особенности >FreeBSD Slackware тоже нормально.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	8. "Решит ли возрождение проекта Berlin API проблемы с инсталляц..."
	Сообщение от Аноним (??) on 24-Июн-08, 17:27
	ИМХО там совсем нет системы этих самых пакаджей. Есть система портов, а это вовсе не одно и то же.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	13. "Решит ли возрождение проекта Berlin API проблемы с инсталляц..."
	Сообщение от anonymous (??) on 24-Июн-08, 17:42
	Давно портировали, Gentoo называется. И удаление неиспользуемых пакетов работает.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	21. "Решит ли возрождение проекта Berlin API проблемы с инсталляц..."
	Сообщение от .3 on 24-Июн-08, 19:35
	>Мне кажется весьма удобной система пакаджей во FreeBSD - пора бы портировать >её в Linux. Впрочем, если линуксоиды будут жестоко преследовать нарушителей GPL-лицензии, >мир скоро перейдёт на FreeBSD. Ничего хуже системы портов FreeBSD я не знаю. Простая задача: есть самописная софтина, она зависит, ну, например, от стандартного sqlite (не важно). Расскажите, как же мне поставить мою софтину хотя бы на 20 серверов.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	28. "Решит ли возрождение проекта Berlin API проблемы с инсталляц..."
	Сообщение от Guest (??) on 24-Июн-08, 22:17
	Пожалуйста, 7 строчек. PORTNAME=       myprog PORTVERSION=    1.0 CATEGORIES=     devel MASTER_SITES=   ftp://local_ftp/ LIB_DEPENDS=    sqlite3.8:${PORTSDIR}/databases/sqlite3 PLIST_FILES=    myprog .include <bsd.port.mk> потом touch pkg_descr && make makesum и дальше как угодно - можно добавить в дерево портов, расшаренное по NFS / в локальное зеркало дерева портов и ставить через for server in "a b c d"; do ssh server "cd /usr/ports/devel/myprog && screen -d -m make install clean"; done - можно сделать package и сделать то же самое, только с pkg_add -r Для деплоя как раз лучше портов ничего не придумали.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	33. "Решит ли возрождение проекта Berlin API проблемы с инсталляц..."
	Сообщение от .3 on 24-Июн-08, 22:40
	А ничего, что в случае pkg_add -r мне надо хранить ВСЕ стандартные пакеты (и их синхронизировать каждый день)? И я еще молчу про то, что библиотеки изредка меняются в пределах одной major.minor версии. И проверить это можно только с помощью getosreldate (здравствуй, статическая линковка!). Собирать на продакшен машинах, конечно, смешная идея, но в некоторых случаях это возможно. Но то, что это будет проходить под рутом (да, я знаю про fakeroot), уже нехорошо. В случае же, когда программа постоянно меняется, а выкатывается раз в месяц, иногда реже, сборка может продолжаться очень долго. На продакшене. Ага. Порты фри были хороши когда их придумали. Они были не так плохи в 2002--ом. Но сейчас остальные системы куда совершенее.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	42. "Решит ли возрождение проекта Berlin API проблемы с инсталляц..."
	Сообщение от Guest (??) on 25-Июн-08, 01:05
	> А ничего, что в случае pkg_add -r мне надо хранить ВСЕ стандартные пакеты (и их синхронизировать каждый день)? Какие пакеты? Зачем хранить? Куда синхронизировать? Что за бред? > Собирать на продакшен машинах, конечно, смешная идея Ничего смешного. Там что, компилятора нет? Или может процессор 486? > но в некоторых случаях это возможно. Но то, что это будет проходить под рутом (да, я знаю про fakeroot), уже нехорошо. А вам что там, надо неизвестно чей софт собирать? Тогда пакаджи, все абсолютно аналогично портам. > В случае же, когда программа постоянно меняется, а выкатывается раз в месяц, иногда реже, сборка может продолжаться очень долго. На продакшене. Ага. Телепаты в отпуске, угадывать какие у вас там продакшны и какие программы. Собирается долго - ставьте кластер и собирайте на нем. > Порты фри были хороши когда их придумали. Они были не так плохи в 2002--ом. Но сейчас остальные системы куда совершенее. Да что вы?
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	46. "*sigh*"
	Сообщение от Michael Shigorin (ok) on 25-Июн-08, 02:11
	Нет, ну это просто феерическое нечто. >> А ничего, что в случае pkg_add -r мне надо хранить ВСЕ стандартные пакеты >> (и их синхронизировать каждый день)? >Какие пакеты? Зачем хранить? Куда синхронизировать? Что за бред? Вы всерьёз предлагаете каждый раз собирать?  Никогда не слышали про "воспроизводимость сборки" случайно?  Что вообще-то код, собранный на одной машине -- может работать на тысячах совершенно других и при этом отладка стека ПО на любой физически исправной из них будет эквивалентна, а не уникальна по надцати параметрам? >> Собирать на продакшен машинах, конечно, смешная идея >Ничего смешного. Там что, компилятора нет? Или может процессор 486? Вы всерьёз о компиляторе на продакшене, который не сборочный сервер?  Может, ещё самолёты в рейсе модернизировать? >Телепаты в отпуске, угадывать какие у вас там продакшны и какие программы. Телепатов у вас там явно нет вообще, так что не надо про отпуск.  Гадать тоже не умеете: где продакшен, там очень сильно помогает от головной боли воспроизводимость.  А с source-based это свойство не дружит, только с package-based при условии наличия сборочной технологии, включающей создание изолированной воспроизводимой среды сборки и возможности фиксации состояния пакетной базы для этой самой воспроизводимости. >Собирается долго - ставьте кластер и собирайте на нем. Под рукой есть три кластера, а вот идиотов, чтобы "собирать на нём" (для чего -- для каждой ноды?  или сэр даже слышал про distcc?) -- пока не нашлось. Так что совет того, бесплатный. >> Порты фри были хороши когда их придумали. Они были не так плохи в 2002--ом. >> Но сейчас остальные системы куда совершенее. >Да что вы? Выдыхай, бобёр.  Выдыхай.  Только осторожно, скрытая камера фиксирует для истории. Я вот этот образчик так отложу себе в тематическую коллекцию шедевров.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	51. "*sigh*"
	Сообщение от oops on 25-Июн-08, 06:54
	>[оверквотинг удален] > >>> А ничего, что в случае pkg_add -r мне надо хранить ВСЕ стандартные пакеты >>> (и их синхронизировать каждый день)? >>Какие пакеты? Зачем хранить? Куда синхронизировать? Что за бред? > >Вы всерьёз предлагаете каждый раз собирать?  Никогда не слышали про "воспроизводимость >сборки" случайно?  Что вообще-то код, собранный на одной машине -- >может работать на тысячах совершенно других и при этом отладка стека >ПО на любой физически исправной из них будет эквивалентна, а не >уникальна по надцати параметрам? Ничего не надо собирать на продакшне. делаем пакет на любой доступной машине и пихаем его в пакетный репозиторий. >>> Собирать на продакшен машинах, конечно, смешная идея >>Ничего смешного. Там что, компилятора нет? Или может процессор 486? >Вы всерьёз о компиляторе на продакшене, который не сборочный сервер?  Может, >ещё самолёты в рейсе модернизировать? Вы давно видели фряху? Там компилятор идет из коробки и всегда присутствует в системе. >>Телепаты в отпуске, угадывать какие у вас там продакшны и какие программы. >Телепатов у вас там явно нет вообще, так что не надо про >отпуск.  Гадать тоже не умеете: где продакшен, там очень сильно >помогает от головной боли воспроизводимость.  А с source-based это свойство >не дружит, только с package-based при условии наличия сборочной технологии, включающей >создание изолированной воспроизводимой среды сборки и возможности фиксации состояния пакетной базы >для этой самой воспроизводимости. Фиксируйте на здоровье. Поставьте машинку для этих целей или jail поднимите. Там хоть зафиксируйтесь. Создать собственный пакетный репозиторий времени занимает не так много, и делается один раз. >>Собирается долго - ставьте кластер и собирайте на нем. >Под рукой есть три кластера, а вот идиотов, чтобы "собирать на нём" >(для чего -- для каждой ноды?  или сэр даже слышал >про distcc?) -- пока не нашлось. без комментариев. >Так что совет того, бесплатный. >>> Порты фри были хороши когда их придумали. Они были не так плохи в 2002--ом. >>> Но сейчас остальные системы куда совершенее. >>Да что вы? >Выдыхай, бобёр.  Выдыхай.  Только осторожно, скрытая камера фиксирует для истории. >Я вот этот образчик так отложу себе в тематическую коллекцию шедевров. Отложите и подумайте где вы не правы.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	80. "*sigh*"
	Сообщение от Michael Shigorin (ok) on 26-Июн-08, 02:15
	>>>> Собирать на продакшен машинах, конечно, смешная идея >>>Ничего смешного. Там что, компилятора нет? Или может процессор 486? >>Вы всерьёз о компиляторе на продакшене, который не сборочный сервер?  Может, >>ещё самолёты в рейсе модернизировать? >Вы давно видели фряху? Недавно последнюю четвёрку хоронил, где был логин, а что? >Там компилятор идет из коробки и всегда присутствует в системе. То-то и оно.  Могу ещё раз повторить своё утверждение: "Вы всерьёз о компиляторе на продакшене, который не сборочный сервер?" Впрочем, фрю к продакшен-системам не отношу по ещё более веским причинам, чем компилятор в basesystem -- чуть выше повторялся про бранчи портов. >Поставьте машинку для этих целей или jail поднимите. Спасибо, я вчера походя склонировал два и перенёс ещё два контейнера (на поднятые в т.ч. для них машинки). >Создать собственный пакетный репозиторий времени занимает не так много, >и делается один раз. Репозитории... "дежурные" генерируются инструментарием после каждой успешной сборки (их бывает и десяток пакетов в день), руками genbasedir тоже порой делаю. Давайте лучше соглашусь с этими Вашими словами, чем буду развивать тему про репо? :) > За сборку и тесты на продакшне надо отрывать руки. > За апгрейд без обкатки на тестовой машине - голову. Только вот ведь какая штука -- инструментально очерченный процесс гораздо более проработан на пакетных линуксах.  Бишь вероятность ошибиться неочевидным образом на порядки меньше. >>Я вот этот образчик так отложу себе в тематическую коллекцию шедевров. >Отложите и подумайте где вы не правы. Это было сделано в процессе перечитывания перед отправкой. Как видите, и то отправил, и это. Поясните?
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	84. "*sigh*"
	Сообщение от oops on 26-Июн-08, 06:41
	>>Вы давно видели фряху? >Недавно последнюю четвёрку хоронил, где был логин, а что? Значит давно. >>Там компилятор идет из коробки и всегда присутствует в системе. >То-то и оно.  Могу ещё раз повторить своё утверждение: >"Вы всерьёз о компиляторе на продакшене, который не сборочный сервер?" Вам компилятор жить мешает? Ну так на то и source based система, порты без компилятора как-то.. сами понимаете. Напомню, что порты являются основным средством установки софта. >Впрочем, фрю к продакшен-системам не отношу по ещё более веским причинам, чем >компилятор в basesystem -- чуть выше повторялся про бранчи портов. тогда рекомендую заглянуть в них на досуге и увидеть например вот это: databases/mysql41-client databases/mysql41-scripts databases/mysql41-server databases/mysql50-client databases/mysql50-scripts databases/mysql50-server databases/mysql51-client databases/mysql51-scripts databases/mysql51-server вы всерьез полагаете что там нужны бранчи? >>Поставьте машинку для этих целей или jail поднимите. >Спасибо, я вчера походя склонировал два и перенёс ещё два контейнера (на >поднятые в т.ч. для них машинки). Согласен, это проще. >Репозитории... "дежурные" генерируются инструментарием после каждой успешной сборки (их бывает и десяток пакетов в день), руками genbasedir тоже порой делаю. И этот десяток прямо-таки необходим в продакшне, и каждый день? Не смешите. >Давайте лучше соглашусь с этими Вашими словами, чем буду развивать тему про >репо? :) pkg_create -b и получаем готовый репозиторий со свежепоставленной машины. или make package в портах. >Только вот ведь какая штука -- инструментально очерченный процесс гораздо более проработан >на пакетных линуксах. Не совсем понимаю о каком процессе идет речь. >Бишь вероятность ошибиться неочевидным образом на порядки >меньше. Как это отменяет сборку и тестирование на отдельном железе? >>>Я вот этот образчик так отложу себе в тематическую коллекцию шедевров. >>Отложите и подумайте где вы не правы. >Это было сделано в процессе перечитывания перед отправкой. >Как видите, и то отправил, и это. Поясните? Из вашего первого утверждения про снесенную четверку я могу предположить, что вы обсуждаете ось которую можно сказать в глаза не видели. Поэтому подобное высказывание: "фрю к продакшен-системам не отношу по ещё более веским причинам, чем компилятор в basesystem" я склонен не воспринимать всерьез. По своему опыту могу сказать, что люди плюются на фряху больше потому, что она "не как linux", часто не понимая как она живет в реальных условиях и что с ней делать. Я вижу это каждый день.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	86. "*sigh*"
	Сообщение от pavel_simple (??) on 26-Июн-08, 08:20
	> Я вижу это каждый >день. я вот, до недавнего времени, как и Вы видел это каждый день и знаете -- мне очень надоело... и я таки закончил миграцию с фряхи. P.S. И Вы не поверите.... -- "всё правильно сделал!" (C) Какая-то там страховая компания.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	91. "*sigh*"
	Сообщение от Michael Shigorin (ok) on 26-Июн-08, 16:57
	>>>Вы давно видели фряху? >>Недавно последнюю четвёрку хоронил, где был логин, а что? >Значит давно. К сожалению, в контексте обсуждаемого вопроса та поросшая мхом немигрируемая 4.10 -- это тоже "недавно". >>Вы всерьёз о компиляторе на продакшене, который не сборочный сервер? >Вам компилятор жить мешает? Да.  Им можно слишком много начудить локального состояния.  Если не задумывались, чем оно плохо -- попробуйте представить себе, что гайки в коробке -- все M5, а не каждая чуть-чуть со своей резьбой. Вот недавно людям сказал, что компилятора не будет, и предложил собрать пакет со своим индексером.  С этим -- помогу. (кстати, надо бы таки помочь) >Ну так на то и source based система, порты без компилятора как-то.. сами понимаете. >Напомню, что порты являются основным средством установки софта. Ну так я и поясняю, куда идёт source based и порты в частности -- лесом.  Если головняка с поддержкой хочется поменьше, конечно. >>Впрочем, фрю к продакшен-системам не отношу по ещё более веским причинам, чем >>компилятор в basesystem -- чуть выше повторялся про бранчи портов. >тогда рекомендую заглянуть в них на досуге и увидеть например вот это: >вы всерьез полагаете что там нужны бранчи? Я ещё раз повторюсь: всерьёз полагаюсь, что для осмысленной по усилиям поддержки широкого спектра программ под несколько поддерживаемых веток платформы бранчи _необходимы_. В качестве нечастой, но яркой иллюстрации -- вспомните, когда последний раз в apache-2.0 одновременно починили дырень и сломали API, а mod_perl2 не успел ещё обновиться. Бранч и current -- это возможность использовать разный подход при делании изменений: консервативный для бранча, экономично-прогрессивный -- для current.  При этом уменьшается плотность конфликтов между теми, кому работать, и теми, кому хакать. >>Репозитории... "дежурные" генерируются инструментарием после каждой успешной сборки >>(их бывает и десяток пакетов в день), руками genbasedir тоже порой делаю. >И этот десяток прямо-таки необходим в продакшне, и каждый день? Не смешите. Зависит. Просто немного тут участвую в разработке ALT Linux, соответственно минимум три активных репозитория есть практически всегда (current, stable и oldstable), а обычно есть ещё несколько тематических -- например, обновлённые пакеты с LTSP5 и настраивалками, репо с которыми подключается при сборке инсталяционного исошника терминального сервера. >>Только вот ведь какая штука -- инструментально очерченный процесс гораздо >>более проработан на пакетных линуксах. >Не совсем понимаю о каком процессе идет речь. Когда возможно, например, проверить целостность/замкнутость репозитория по тем же библиотекам. Если интересно -- можете глянуть пример здесь: http://lists.altlinux.org/pipermail/sisyphus-cybertalk/2008-... (download неинтересно, а вот unmets и bad_elf_symbols бывают крайне полезны) Это пакет qa-robot (http://sisyphus.ru/srpm/qa-robot).  Опирается на apt (работа с репозиторием), который, в свою очередь, у нас опирается на rpm (работа с зависимостями конкретных пакетов). >>Бишь вероятность ошибиться неочевидным образом на порядки меньше. >Как это отменяет сборку и тестирование на отдельном железе? Никак не отменяет.  То, что порой бывает удобней собирать в контейнере (или на кластере :), а тестировать в qemu -- непринципиальные детали. Кстати, сборка тут и происходит в сборочных контейнерах :)  Начиная с 32/64-битного current (aka Sisyphus). >>>Отложите и подумайте где вы не правы. >>Поясните? >Из вашего первого утверждения про снесенную четверку я могу предположить, >что вы обсуждаете ось которую можно сказать в глаза не видели. Ну как Вам сказать.  Если с 2.2.7 (или 2.2.8?) через 3.4 (или 3.5, что ли) и до 4.10 (или всё-таки 4.11?) нынче считается "в глаза не видел" -- ну ква. То, что ситуация по конкретно этому вопросу остаётся брежней -- мне и так есть у кого выяснить из тех, чьему мнению и опыту в нём я доверяю (например, netch@). Поскольку системное администрирование получается побочным занятием относительно манагерства (когда свалить не на кого, приходится делать самому), и не пытаюсь иметь собственный актуальный опыт по всему, что теоретически может подходить для решения наличных задач -- попросту не хватит здоровья. Кстати, этому же учили в лицее: пользоваться опытом других, не открывая америк. А выводы примерно десятилетней давности и сегодня остаются очень даже актуальными. К чему бы это? >Поэтому подобное высказывание: "фрю к продакшен-системам не отношу по ещё более >веским причинам, чем компилятор в basesystem" я склонен не воспринимать всерьез. Да пожалуйста :-) >По своему опыту могу сказать, что люди плюются на фряху больше потому, >что она "не как linux", часто не понимая как она живет в реальных условиях >и что с ней делать. Я вижу это каждый день. Это чуть другой момент, хотя и примерно двоюродный. Я прекрасно понимаю, что фря -- не линукс (и несколько понимаю, почему). А собсно говорю как раз о том, что у линуксов получается на эпоху лучше -- управление установленным программным обеспечением. Хотите -- спорьте, хотите -- попробуйте посмотреть под другим углом, нежели "в source-based"... Спорить с умными людьми полезно тем, что узнаёшь что-то новое и излагая то, что знаешь -- находишь в нём неожиданные грани. Потому на это время и находится порой. :-)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	75. "*sigh*"
	Сообщение от Guest (??) on 25-Июн-08, 20:27
	Три кластера под рукой.. Почему сразу не десять? Боже, даже комментировать не хочу. Дешевый непрофессиональный троллинг.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	81. "*sigh*"
	Сообщение от Michael Shigorin (ok) on 26-Июн-08, 02:25
	>Три кластера под рукой.. Почему сразу не десять? Потому что СКИТ-1, СКИТ-2, СКИТ-3 -- это три кластера, а не десять.  На КПИ-шный не ходок. >Боже, даже комментировать не хочу. Дешевый непрофессиональный троллинг. Ну так и не занимайтесь им, или тоже квалифицируйтесь на нормального тролля :-) http://icybcluster.org.ua/ [XXXX@ZZZZ ~]$ squeue | awk '{print $2;}' | sort -u PARTITION scit1 scit2 scit3 На scit3 вон коллега данные для автоматического переводчика обрабатывает :-) $ squeue | grep pere | wc -l           15 60 ядер и 120Gb RAM куда быстрей приводят к появлению и улучшению языковых пар, чем домашняя машинка...
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	60. "Решит ли возрождение проекта Berlin API проблемы с инсталляц..."
	Сообщение от .3 on 25-Июн-08, 10:38
	>> А ничего, что в случае pkg_add -r мне надо хранить ВСЕ стандартные пакеты (и их синхронизировать каждый день)? > Какие пакеты? Зачем хранить? Куда синхронизировать? Что за бред? А pkg_add -r уже научился ходить по разным серверам? >> Собирать на продакшен машинах, конечно, смешная идея > Ничего смешного. Там что, компилятора нет? Или может процессор 486? А то, что машина может быть загружена своей основной работой --- это ничего? После сборки надо прогнать тесты, или где--то не так? У тестов (да и у сборки) может быть еще одна большая куча зависимостей. И ее тоже надо будет поставить на продакшен. И следить за версиями.   И, прошу обратить внимание, не надо быть телепатом, что бы это знать. > Собирается долго - ставьте кластер и собирайте на нем. Если собирать на кластере, то, наверное потом это надо будет принести с кластера, или во фре уже есть libastral?
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	61. "Решит ли возрождение проекта Berlin API проблемы с инсталляц..."
	Сообщение от Осторожный on 25-Июн-08, 10:55
	>>> А ничего, что в случае pkg_add -r мне надо хранить ВСЕ стандартные пакеты (и их синхронизировать каждый день)? >> Какие пакеты? Зачем хранить? Куда синхронизировать? Что за бред? > >А pkg_add -r уже научился ходить по разным серверам? Вообще-то всегда умел :) export PACKAGEROOT=ftp://myserver-with-ports.mydomain.ru pkg_add -r gdbm perl && pkg_add -r bash && pkg_add -r sudo && \ pkg_add -r aspell joe && pkg_add -r lynx && pkg_add -r mc && \ pkg_add -r portaudit
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	66. "Решит ли возрождение проекта Berlin API проблемы с инсталляц..."
	Сообщение от .3 on 25-Июн-08, 11:44
	>[оверквотинг удален] > >Вообще-то всегда умел :) > >export PACKAGEROOT=ftp://myserver-with-ports.mydomain.ru > >pkg_add -r gdbm perl && pkg_add -r bash && pkg_add -r sudo >&& \ >pkg_add -r aspell joe && pkg_add -r lynx && pkg_add -r mc >&& \ >pkg_add -r portaudit Я тут вижу только один сервер.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	62. "Решит ли возрождение проекта Berlin API проблемы с инсталляц..."
	Сообщение от Осторожный on 25-Июн-08, 10:59
	>>> Собирать на продакшен машинах, конечно, смешная идея >> Ничего смешного. Там что, компилятора нет? Или может процессор 486? > >А то, что машина может быть загружена своей основной работой --- это >ничего? После сборки надо прогнать тесты, или где--то не так? У >тестов (да и у сборки) может быть еще одна большая куча >зависимостей. И ее тоже надо будет поставить на продакшен. И следить >за версиями. 1) Выделяется отдельный сервер 2) На нем синхронизуются порты 3) Делается сборка нужных портов с помощью portupgrade    Включая свою софтину 4) На этом же сервере можно делать тесты 5) Когда убедились что все работает, тогда ставим на production    Хотя вообще по-хорошему тесты надо делать еще когда пишется софтина :)    mount /usr/ports    portupgrade -aPPR my_program    umount /usr/ports
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	73. "Решит ли возрождение проекта Berlin API проблемы с инсталляц..."
	Сообщение от .3 on 25-Июн-08, 14:18
	> Хотя вообще по-хорошему тесты надо делать еще когда пишется софтина :) На некоторые тесты уходят часы. >   mount /usr/ports >   portupgrade -aPPR my_program >   umount /usr/ports Не правда ли проще подключить репозаторий, а потом сказать apt-get/yum?
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	71. "Решит ли возрождение проекта Berlin API проблемы с инсталляц..."
	Сообщение от oops on 25-Июн-08, 13:28
	>>> Собирать на продакшен машинах, конечно, смешная идея >> Ничего смешного. Там что, компилятора нет? Или может процессор 486? >А то, что машина может быть загружена своей основной работой --- это >ничего? После сборки надо прогнать тесты, или где--то не так? У >тестов (да и у сборки) может быть еще одна большая куча >зависимостей. И ее тоже надо будет поставить на продакшен. И следить >за версиями. >И, прошу обратить внимание, не надо быть телепатом, что бы это знать. За сборку и тесты на продакшне надо отрывать руки. За апгрейд без обкатки на тестовой машине - голову.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	72. "Решит ли возрождение проекта Berlin API проблемы с инсталляц..."
	Сообщение от .3 on 25-Июн-08, 14:11
	>За сборку и тесты на продакшне надо отрывать руки. >За апгрейд без обкатки на тестовой машине - голову. Мне это говорить не надо. Говорите это Guest'у, который не видит в этом ничего странного.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	76. "Решит ли возрождение проекта Berlin API проблемы с инсталляц..."
	Сообщение от Guest (??) on 25-Июн-08, 20:29
	> Говорите это Guest'у, который не видит в этом ничего странного. Из каких же моих слов вы сделали такой вывод?
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	77. "Решит ли возрождение проекта Berlin API проблемы с инсталляц..."
	Сообщение от .3 on 26-Июн-08, 00:25
	>> Говорите это Guest'у, который не видит в этом ничего странного. > >Из каких же моих слов вы сделали такой вывод? Сообщение #42, цитата: > Собирать на продакшен машинах, конечно, смешная идея Ничего смешного. Там что, компилятора нет? Или может процессор 486?
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	78. "Решит ли возрождение проекта Berlin API проблемы с инсталляц..."
	Сообщение от fi (ok) on 26-Июн-08, 00:37
	> За сборку и тесты на продакшне надо отрывать руки. > За апгрейд без обкатки на тестовой машине - голову. Этого мало!!! Лучше начинать с яиц -  безболезненней будет Да и сам компилятор лучше удалить с продакшин - большенство локальных уязвимостей требуют его. PS за что и признаны пакетные системы - софт уже идет протестенный. что конечно не отменяет обкатки.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	92. "gcc  wget"
	Сообщение от Michael Shigorin (ok) on 26-Июн-08, 17:18
	>Да и сам компилятор лучше удалить с продакшин - большенство локальных уязвимостей >требуют его. Вообще-то нет (и по словам опять же людей, которым склонен верить -- сейчас в основном молодёжь со своими бинарниками шарится), но рассматривание ряда .bash_history наводит на мысль, что мера предосторожности всё равно не лишняя. Особенно если libc и ядро -- не точь-в-точь убунто-редхатовские, а немного специфичны ;-) BTW дочитавшим досюда маленький бонус: http://sisyphus.ru/srpm/apache-honeypot
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	22. "Решит ли возрождение проекта Berlin API проблемы с инсталляц..."
	Сообщение от kostbebix on 24-Июн-08, 20:20
	Кхм кхм. Совершенно недавно на работе я таки добился установки bugzilla. На сервак с freebsd - пишу фигню с портом (спасибо сисадмину, помог строчкой) - установило, сиди и пили сколько угодно дальше, потом еще пилил... Установил. Почти. Заняло ~2 часа, должно работать, но там какая-то фигня с сэндмэйлом, которая так и не заработала (лень разбираться). Попробовал на Gentoo. Тоже. Из портов сначала не собралось, потом где-то чего-то подпилили, собралось. Пилил пилил - та же фигня что и во фре с сэндмэйлом. Снова лень разбираться (в генте тоже никогда ничего не делал, да и сервак не мой, экспериментировать сильно не хотел). Ради чистоты эксперимента попробовал у себя под федорой. yum -y install bugzilla а далее - создать пользователя bugs и запустить скрипт багзилловский. Сорри что много текста лишнего, просто наболело. Я к чему это все - в портах минус: не всегда оно собирается, надо чего-то делать еще. В rpm и deb'ах все куда вероятнее что заработает с полупинка (по крайней мере у меня так).
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	52. "Решит ли возрождение проекта Berlin API проблемы с инсталляц..."
	Сообщение от oops on 25-Июн-08, 06:58
	>Кхм кхм. Совершенно недавно на работе я таки добился установки bugzilla. На >сервак с freebsd - пишу фигню с портом (спасибо сисадмину, помог >строчкой) - установило, сиди и пили сколько угодно дальше, потом еще >пилил... Установил. Почти. Заняло ~2 часа, должно работать, но там какая-то >фигня с сэндмэйлом, которая так и не заработала (лень разбираться). pkg_add -r <pkgname> или portupgrade -PP <origin> с сэндмейлом надо понимать на месте. или отключить его и поставить MTA который вы знаете.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	63. "Решит ли возрождение проекта Berlin API проблемы с инсталляц..."
	Сообщение от kostbebix on 25-Июн-08, 11:25
	>>Кхм кхм. Совершенно недавно на работе я таки добился установки bugzilla. На >>сервак с freebsd - пишу фигню с портом (спасибо сисадмину, помог >>строчкой) - установило, сиди и пили сколько угодно дальше, потом еще >>пилил... Установил. Почти. Заняло ~2 часа, должно работать, но там какая-то >>фигня с сэндмэйлом, которая так и не заработала (лень разбираться). > >pkg_add -r <pkgname> или portupgrade -PP <origin> >с сэндмейлом надо понимать на месте. или отключить его и поставить MTA >который вы знаете. Ну там основное время ушло на сборку модулей перла (руками надо было каждую прописывать, а потом, по идее, отвечать на кучу вопросов, но я делал yes2all, и все равно не все установилось). В федоре (в той же) оно сделано иначе. На примере пхп: чтоб проинсталлировать пхп надо сделать yum install php Чтобы подключить поддержку mysql не надо ничего пересобирать или еще чего. Достаточно сделать yum install php-mysql Так же и с перлом и остальными.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	68. "Решит ли возрождение проекта Berlin API проблемы с инсталляц..."
	Сообщение от oops on 25-Июн-08, 13:07
	>Ну там основное время ушло на сборку модулей перла (руками надо было >каждую прописывать, а потом, по идее, отвечать на кучу вопросов, но >я делал yes2all, и все равно не все установилось). Случайно не через cpan ставились? >Чтобы подключить поддержку mysql не надо ничего пересобирать или еще чего. Достаточно >сделать >yum install php-mysql > >Так же и с перлом и остальными. Чем это сложнее pkg_add -r или portupgrade -PP? оба варианта поставят исключительно бинарный пакет безо всяких пересборок и приплясываний..
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	87. "Решит ли возрождение проекта Berlin API проблемы с инсталляц..."
	Сообщение от kostbebix on 26-Июн-08, 11:07
	>Случайно не через cpan ставились? Да, он. >Чем это сложнее pkg_add -r или portupgrade -PP? оба варианта поставят исключительно >бинарный пакет безо всяких пересборок и приплясываний.. Типа установлен php, не надо его пересобирать с флагом --with-gd (к примеру), а можно сделать что-то вроде yum install php-gd2? типа pkg_add -r php-gd2? (чисто интуитивно)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	89. "Решит ли возрождение проекта Berlin API проблемы с инсталляц..."
	Сообщение от oops on 26-Июн-08, 13:27
	>>Случайно не через cpan ставились? >Да, он. тогда получаете кучу вопросов и не факт что соберется. ставьте портом. >>Чем это сложнее pkg_add -r или portupgrade -PP? оба варианта поставят исключительно >>бинарный пакет безо всяких пересборок и приплясываний.. > >Типа установлен php, не надо его пересобирать с флагом --with-gd (к примеру), >а можно сделать что-то вроде yum install php-gd2? типа pkg_add -r >php-gd2? (чисто интуитивно) portupgrade -PP graphics/php5-gd (или graphics/php4-gd) Для pkg_add нужно знать точное имя пакета. можно посмотреть в порту.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	90. "Решит ли?! :-D"
	Сообщение от Andrey Mitrofanov on 26-Июн-08, 13:31
	>>а можно сделать что-то вроде yum install php-gd2? типа pkg_add -r >>php-gd2? (чисто интуитивно) >portupgrade -PP graphics/php5-gd (или graphics/php4-gd) >Для pkg_add нужно знать точное имя пакета. можно посмотреть в порту. ...что снова возвращает нас к вопросу, "Решит ли возрождение проекта Berlin API проблемы с инсталляцией ПО"?? :-))))
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	35. "Решит ли возрождение проекта Berlin API проблемы с инсталляц..."
	Сообщение от Guest (??) on 24-Июн-08, 22:47
	> Мне кажется весьма удобной система пакаджей во FreeBSD Нет системы пакаджей, есть система портов. А бинарные пакаджи, которые из нее получаются, не очень то и удобны. > пора бы портировать её в Linux Гентушный portage в некотором смысле аналог, хотя у него есть смои большие плюсы и большие минусы pkgsrc можно использовать вообще почти везде, от linux до solaris, он к портам гораздо ближе. Вообще дело не в этом. Дело в том имхо, что любая система пакетов должна основываться на исходниках, но при этом уметь порождать самодостаточные бинарные пакеты. Это значит, что не maintainer'ы не собирают пакеты как хотят, а пишут инструкцию, как пакет собрать (аналог порта FreeBSD или ebuild'а), после чего добавляют ее в репозиторий. Заодно могут залить и сам пакет, по ней собранный. Итого: имеем все плюсы source-based систем. Автоматизированная проверка и сборка подо все архитектуры, возможность быстро обновить порт до новой версии (просто взяв существующий и изменив циферку) и т.д. В то же время из этого должны получаться пакеты, которые как минимум знают, с какими версиями зависимых пакетов они могут работать. FreeBSD'шные пакаджи, например, не знают. Будут писать ворнинги, если версии не совпадают, и если, например, shared lib версия поменялась или еще какой косяк, ничего сделать не cмогут. Ну и системная библиотека для управления этим всем, чтобы любой пакет можно было установить одной командой, причем установка из исходников/бинарников меняется одним ключиком. Короче, потенциально есть куда развиваться всем существующим пакетным менеджерам, но то, что `Установка ПО в Linux - задача достаточно сложная', и идеи о новом API, основанном на D-BUS (!!!) и XML - такой концентрированный параноидальный бред, что мне даже страшно.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	45. "какие пакаджи..."
	Сообщение от Michael Shigorin (ok) on 25-Июн-08, 02:00
	>Мне кажется весьма удобной система пакаджей во FreeBSD - пора бы портировать >её в Linux. Дмитрий, от Вас не ожидал. Во-первых, пакетные системы в линуксах -- как минимум apt -- на порядок более развиты, чем зачаточная пакетная система FreeBSD.  Можете поискать да хотя бы и в архивах r.o.c разборы полётов :-) Во-вторых, _портаджи_ в Gentoo и ряде подобных дистров тоже есть и несмотря на улучшения относительно портов FreeBSD -- продолжают иметь ряд принципиальных и архитектурных проблем оригинала (например, отсутствие бранчей по версиям поддерживаемых дистрибутивов, когда желательно поддерживать их в режиме минимальных изменений). В-третьих, порты даже в той же NetBSD по последнему пункту сделаны куда грамотней, чем во фряке. Когда кажется -- креститься пора :-) >Впрочем, если линуксоиды будут жестоко преследовать нарушителей GPL-лицензии, >мир скоро перейдёт на FreeBSD. Бздюшники пытались жёстко гнобить тех, кто нарушил даже не текст их лицензии, а то, что они себе возомнили.  Всё равно за бортом. Впрочем, не верьте мне на слово -- просто смотрите внимательно сами.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	50. "Решит ли возрождение проекта Berlin API проблемы с инсталляц..."
	Сообщение от oops on 25-Июн-08, 06:41
	>Мне кажется весьма удобной система пакаджей во FreeBSD - пора бы портировать >её в Linux. Впрочем, если линуксоиды будут жестоко преследовать нарушителей GPL-лицензии, >мир скоро перейдёт на FreeBSD. Система пакаджей во фряхе довольно убога: 1. Пакетная база - набор каталогов с информацией о структуре и содержимом пакета. На большом количестве установленного софта начинаются заметные тормоза, так как упираемся в дисковую подсистему. 2. Жесткие зависимости. т.е. при обновлении пакета на который ссылается другой пакет получаем битую зависимость. 3. Отсутствие апгрейда как такового. Система портов тоже не без недостатков. В частности: 1. Приходится долго и аккуратно подгонять make.conf под свои нужды, чтобы собраться скажем именно с апачем версии 2.0 и с нужными опциями, которые не всегда можно получить по make config(но присутствуют в Makefile порта). 2. Зачастую невозможно собрать два пакета с разными опциями с одного порта и сложить в один пакетный репозиторий, т.к. имена таких пакетов вероятнее всего совпадут. Бывают правда и исключения например для опции WITH_THREADS. 3. Апгрейд никакой. Вобщем для _пользователя_ подобная схема в большинстве случаев неприемлема. Все это более или меннее лечится portupgrade и ижи с ними, но знакомым точно не поставлю. Хотя сам фряшник и гибкость портовой системы покрывает все эти недостатки.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	53. "Решит ли возрождение проекта Berlin API проблемы с инсталляц..."
	Сообщение от oops on 25-Июн-08, 07:04
	Из плюсов могу отметить гибкость портовой системы и _предсказуемость_ поведения как портов так и пакетов. Для админа эти плюсы легко перевешивают все минусы перечисленные выше.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	64. "Решит ли возрождение проекта Berlin API проблемы с инсталляц..."
	Сообщение от Осторожный on 25-Июн-08, 11:25
	>Система пакаджей во фряхе довольно убога: >1. Пакетная база - набор каталогов с информацией о структуре и содержимом >пакета. На большом количестве установленного софта начинаются заметные тормоза, так как >упираемся в дисковую подсистему. >2. Жесткие зависимости. т.е. при обновлении пакета на который ссылается другой пакет >получаем битую зависимость. >3. Отсутствие апгрейда как такового. Обновлений нет. А раз так, то в пункте 2 написана фигня - "при обновлении пакета". При каком обновлении ? Получить битую зависимость можно если удалить пакет с ключом "force". Иначе pkg_delete просто не даст удалить пакет если есть зависящие от него. Ну а раз использовал "force" - то наверное знал что делаешь ? :) >Система портов тоже не без недостатков. В частности: >1. Приходится долго и аккуратно подгонять make.conf под свои нужды, чтобы собраться >скажем именно с апачем версии 2.0 и с нужными опциями, которые >не всегда можно получить по make config(но присутствуют в Makefile порта). А зачем подгонять make.conf ? Нужно использовать 1) make config 2_ portupgrade c pkgtools.conf - там прописывают все остальные опции которые не входят в конфиг. Да один раз нужно создать /var/db/ports/ и pkgtools.conf под себя. Но скажем если взять rpm-based и debian-based - то там опции сборки уже решены за вас и если вы захотите делать часть пакетов со своими опциями сборки, то проблем будет не меньше чем в FreeBSD. > >2. Зачастую невозможно собрать два пакета с разными опциями с одного порта >и сложить в один пакетный репозиторий, т.к. имена таких пакетов вероятнее >всего совпадут. Бывают правда и исключения например для опции WITH_THREADS. Да - это проблема в FreeBSD. Нельзя собрать два конфликтующих пакета. Cам с собой пакет конфликтует по определению. Имена пакетов в принципе можно разрулить подправив Makefile. Но вот в FreeBSD сделано так, что для сборки пакета его нужно обязательно установить. И это мешает. >3. Апгрейд никакой. > >Вобщем для _пользователя_ подобная схема в большинстве случаев неприемлема. Все это более >или меннее лечится portupgrade и ижи с ними, но знакомым точно >не поставлю. Хотя сам фряшник и гибкость портовой системы покрывает все >эти недостатки. portupgrade хорошая вещь, но все равно не решает всех проблем.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	69. "Решит ли возрождение проекта Berlin API проблемы с инсталляц..."
	Сообщение от oops on 25-Июн-08, 13:22
	>[оверквотинг удален] >>3. Отсутствие апгрейда как такового. > >Обновлений нет. >А раз так, то в пункте 2 написана фигня - "при обновлении >пакета". При каком обновлении ? >Получить битую зависимость можно если удалить пакет с ключом "force". >Иначе pkg_delete просто не даст удалить пакет если есть зависящие от него. > >Ну а раз использовал "force" - то наверное знал что делаешь ? >:) гхм csup на /usr/ports и обновляемся за порта. а заодно получаем битую зависимость. Сюрприз. >>Система портов тоже не без недостатков. В частности: >>1. Приходится долго и аккуратно подгонять make.conf под свои нужды, чтобы собраться >>скажем именно с апачем версии 2.0 и с нужными опциями, которые >>не всегда можно получить по make config(но присутствуют в Makefile порта). >А зачем подгонять make.conf ? >Нужно использовать >1) make config >2_ portupgrade c pkgtools.conf - там прописывают все остальные опции которые не >входят в конфиг. 1. make config, как я уже написал не всегда содержит _все_ опции доступные в Makefile. И еще не для всех портов существует. 2. portupgrade не покрывает случаи когда я говорю make install в самом порту. Если это не апгрейд, то portupgrade никакого смысла использовать нет. make.conf _всегда_ предпочтительнее чем конфиг сторонней тулзы. >Да один раз нужно создать /var/db/ports/ и pkgtools.conf под себя. Это хорошо для одной машины. т.к. подразумевает определенный интерактив.(make config) >Но скажем если взять rpm-based и debian-based - то там опции сборки >уже решены за вас >и если вы захотите делать часть пакетов со своими опциями сборки, >то проблем будет не меньше чем в FreeBSD. Проблем будет гораздо больше, так как заточены на пакеты. >>2. Зачастую невозможно собрать два пакета с разными опциями с одного порта >>и сложить в один пакетный репозиторий, т.к. имена таких пакетов вероятнее >>всего совпадут. Бывают правда и исключения например для опции WITH_THREADS. > >Да - это проблема в FreeBSD. >Нельзя собрать два конфликтующих пакета. Cам с собой пакет конфликтует по определению. >Имена пакетов в принципе можно разрулить подправив Makefile. >Но вот в FreeBSD сделано так, что для сборки пакета его нужно >обязательно установить. Собрать можно например в chroot(DESTDIR=<chroot path> -DCHROOTED), сложить нельзя. >portupgrade хорошая вещь, но все равно не решает всех проблем. Он не решает даже половины реальных проблем если я захочу работать с пакетной базой в полностью автоматическом режиме - без собственного непосредственного участия. Смею заверить, напильник больше похож на собственную портовую систему.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	74. "Решит ли возрождение проекта Berlin API проблемы с инсталляц..."
	Сообщение от .3 on 25-Июн-08, 14:21
	> Получить битую зависимость можно если удалить пакет с ключом "force". > Иначе pkg_delete просто не даст удалить пакет если есть зависящие от него. Еще можно запустить portupgrade. Даже в мане написано: > After performing a binary upgrade, it is strongly recommended that > you run ``pkgdb -F'' to fix broken dependencies introduced by the > newly installed packages.t
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

9. "Решит ли возрождение проекта Berlin API проблемы с инсталляц..."

Сообщение от Аноним (??) on 24-Июн-08, 17:27

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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	11. "Решит ли возрождение проекта Berlin API проблемы с инсталляц..."
	Сообщение от Knuckles (ok) on 24-Июн-08, 17:33
	Не самая лучшая. Недавно решил удалить ненужные пакеты и понял, что не знаю, как. Ну покоцал, конечно, те, которые знаю, что точно не нужны. А сколько осталось lib*super-puper*.tgz и представить боюсь :)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	56. "Решит ли возрождение проекта Berlin API проблемы с инсталляц..."
	Сообщение от tux2002 on 25-Июн-08, 09:18
	>Не самая лучшая. Недавно решил удалить ненужные пакеты и понял, что не >знаю, как. >Ну покоцал, конечно, те, которые знаю, что точно не нужны. А сколько >осталось lib*super-puper*.tgz и представить боюсь :) Если ставишь через пакет, то и удаляешь removepkg. А то что make install DESTDIR= и затем makepkg это уж каждый кто устанавливает slackware должен знать сразу.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	57. "Решит ли возрождение проекта Berlin API проблемы с инсталляц..."
	Сообщение от tux2002 on 25-Июн-08, 09:20
	>>Не самая лучшая. Недавно решил удалить ненужные пакеты и понял, что не >>знаю, как. >>Ну покоцал, конечно, те, которые знаю, что точно не нужны. А сколько >>осталось lib*super-puper*.tgz и представить боюсь :) Ктому же есть /var/adm/packages
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	59. "Решит ли возрождение проекта Berlin API проблемы с инсталляц..."
	Сообщение от Knuckles (ok) on 25-Июн-08, 09:27
	Спасибо, как устанавливать и удалять пакеты я сам знаю :) Речь о другом: http://www.opennet.dev/openforum/vsluhforumID3/42532.html#10
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	82. "слакваристы"
	Сообщение от Michael Shigorin (ok) on 26-Июн-08, 02:29
	> это уж каждый кто устанавливает slackware должен знать сразу. Видите ли, те деятели, которые бегают и орут "слакарулит", это не склонны своим доверчивым жертвам рассказывать. Почему бы последние были "должны"?  Если я кому-то что-то впариваю, так это _я должен_ рассказать про подводные грабли, а не человек -- догадываться или впитать с молоком матери. Следствие: не утруждаетесь рассказывать -- не впаривайте, имейте совесть.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	47. "ух ты, слакварист 8)"
	Сообщение от Michael Shigorin (ok) on 25-Июн-08, 02:19
	>Зачем создавать ещё одну прослойку для линукса, и без того проблем хватает. [*] >Самая лучшая (но конечно не самая удобная и простая) А чем лучшая-то?  Она ведь ещё и не самая надёжная. >установка пакетов реализована в slackware. Это предел простоты Не простоты, а примитивности. >и вот это должно быть примером для всех создателей дистрибутивов. Вы мож сперва проблемы, которых хватает, порешайте?  А потом нам, убогим создателям дистрибутивов, придёте и расскажете чего-нить умного. Для начала предлагаю http://lafox.net/support/index.php?showtopic=11769
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	88. "ух ты, слакварист 8)"
	Сообщение от tux2002 on 26-Июн-08, 11:07
	>Вы мож сперва проблемы, которых хватает, порешайте?  А потом нам, убогим >создателям дистрибутивов, придёте и расскажете чего-нить умного. Вы дистрибутивы без обратной связи с конечными пользователями делаете? Может быть убогие пользователи чего и подсказали бы :). Насчёт slackware - мне хватает её уровня сложности (если хотите примитивности). Изучать что-то ещё мне нехватает времени. Пусть например CentOS хороший дистрибутив, но я не собираюсь мёрзнуть в серверной управляя через графику (вообще X на серверах не держим), или растаскивать симлинки в rc.d вручную. Возьмём примитивнейший пример настройки сетевого интерфейса. Я знаю где лежит конфигурационный файл, но он пуст. Крутые дистростроители забыли предложить шаблон  хотя бы в виде комментариев. Я что должен из-за такой фигни хэндбуки курить? Так что почаще с пользователями советуйтесь.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	93. "'хэндбуки' и 'с пользователями'"
	Сообщение от Michael Shigorin (ok) on 26-Июн-08, 17:35
	>>Вы мож сперва проблемы, которых хватает, порешайте?  А потом нам, убогим >>создателям дистрибутивов, придёте и расскажете чего-нить умного. >Вы дистрибутивы без обратной связи с конечными пользователями делаете? Ну почему же.  Отвечать могу только за себя -- стараюсь слушать, хотя тоже порой в своп ухожу :) >Может быть убогие пользователи чего и подсказали бы :) У нас обычно очень даже ничего пользователи, иной раз интереснейшие вещи рассказывают ;) >Насчёт slackware - мне хватает её уровня сложности (если хотите примитивности). >Изучать что-то ещё мне нехватает времени. Подсказать, почему не хватает, или сами догадаетесь?  Попробуйте сопоставить время на решение задачи и время на возню с системой, не направленное непосредственно на решение этой самой задачи. Сам-то как раз много "вожусь с системой", но поскольку это в основном пакеты и профили дистрибутивов, которые публикуются -- толку от такой возни бывает больше, чем на localhost. >Пусть например CentOS хороший дистрибутив, но я не собираюсь мёрзнуть >в серверной управляя через графику (вообще X на серверах не держим), >или растаскивать симлинки в rc.d вручную. Ну кто ж заставляет-то.  Да и ssh -X/-Y не отменяли, если кого угораздило держать. >Возьмём примитивнейший пример настройки сетевого интерфейса. Давайте. >Я знаю где лежит конфигурационный файл, но он пуст. Не очень хорошо. >Крутые дистростроители забыли предложить шаблон  хотя бы в виде комментариев. Повесите им багу, если будет время? (правда, скорее всего пошлют в редхат, но это уж судьба клонов) >Я что должен из-за такой фигни хэндбуки курить? Стоп.  Я согласен, что ситуация плохая и нехорошая.  Вы не пояснили, как это делаете на слаквари и чем именно получается легче (не стоит путать с "привычней"). Hint: сделать слакварь из кентоса несколько проще, чем обратное.  В данном разе ничто не мешает Вам пойти в /etc/{rc.d/,}rc.local и соорудить там нужный вид из modprobe, ifconfig и route (и/или на ip -- по вкусу и надобности). Точно так же и любая другая настраивалка.  Я вот до сих пор одним из первых дел выношу из создаваемых контейнеров alterator (который положил в заготовку), но надеюсь через годик эту привычку уже отменять -- поскольку надо же сделать удобный и обозримый интерфейс для управления OpenVZ VE (а то и другими видами контекстов) на своих же системах, ну не век же в голове столько контексту держать... (ещё хинт -- необязательно хэндбуки, можно fgrep -r ifcfg /usr/share/doc) >Так что почаще с пользователями советуйтесь. Давайте посоветуемся.  Только сразу предупреждаю, к CentOS/RHEL у меня отношение тоже ироничное, хоть и по другим поводам :-)  А в ALT стараюсь делать так, чтоб было удобно и полезно себе и другим.  И это скорее правило по команде (хотя бывают заскоки, конечно).
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	94. "'хэндбуки' и 'с пользователями'"
	Сообщение от tux2002 on 26-Июн-08, 18:29
	>Подсказать, почему не хватает, или сами догадаетесь?  Попробуйте сопоставить время на >решение задачи и время на возню с системой, не направленное непосредственно >на решение этой самой задачи. >Давайте посоветуемся.  Только сразу предупреждаю, к CentOS/RHEL у меня отношение тоже >ироничное, хоть и по другим поводам :-)  А в ALT >стараюсь делать так, чтоб было удобно и полезно себе и другим. > И это скорее правило по команде (хотя бывают заскоки, конечно). > Давайте посоветуемся и про затраченное время. ALT не видел, говорят хороший дистрибутив, посмотрю в ближайшее время. Загрузчик надеюсь предлагается запаролить при установке? Интересно как там у Вас со сборкой например зависимостей glibc->samba скажем с march=nocona.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	95. "буки' и 'с пользоват"
	Сообщение от Andrey Mitrofanov on 26-Июн-08, 18:38
	>ALT не видел, говорят хороший дистрибутив [...] >Интересно как там у Вас со сборкой например [...] >скажем с march=nocona. :-O То есть _не_ сорс-бейзеd дистрибутивов Вы вообще не видели? Мама-мама-мама...
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	96. "буки' и 'с пользоват"
	Сообщение от tux2002 on 26-Июн-08, 18:56
	>:-O То есть _не_ сорс-бейзеd дистрибутивов Вы вообще не видели? Мама-мама-мама... А что мне march=i486 mtune=i686 на сервер что ли ставить где 300 пользователей файлы гоняют самбой чараз кламав, да ещё жестоко VSS? Видел, на ноуте неплохо смотрятся.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	98. "'хэндбуки' и 'с пользователями'"
	Сообщение от Michael Shigorin (ok) on 26-Июн-08, 19:47
	>Давайте посоветуемся и про затраченное время /me listens >Загрузчик надеюсь предлагается запаролить при установке? В допнастройках -- хоть руками конфигурацию написать. >Интересно как там у вас со сборкой например зависимостей glibc->samba скажем >с march=nocona. Не уловил смысл, но можете поставить эксперимент -- hasher помогает. ftp://ftp.altlinux.org/pub/people/ldv/hasher/hasher.7.html ftp://ftp.altlinux.org/pub/people/ldv/hasher/thesis-2004.html Вообще самбу у нас собирает один из участников Samba Team -- проблемы последнее время бывали разве что вида "Саша медлит с релизом-с-буковкой, говоря, что там ещё сейчас патчик будет" :-)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

15. "Решит ли возрождение проекта Berlin API проблемы с инсталляц..."

Сообщение от idkfa on 24-Июн-08, 17:56

лучше всего в solaris :) никаких менеджеров - голова, блокнот и прямые руки :D

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	40. "Решит ли возрождение проекта Berlin API проблемы с инсталляц..."
	Сообщение от anonymous (??) on 25-Июн-08, 00:19
	> лучше всего в solaris :) > никаких менеджеров - голова, блокнот и прямые руки :D +1; Очень просто, не отягощено гипертрофированными зависимостями (и, когда я с ним работал, никаких навязчивых update'ов, приводящих систему с публичными сервисами в непредсказуемое состояние).
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	48. "Решит ли возрождение проекта Berlin API проблемы с инсталляц..."
	Сообщение от Michael Shigorin (ok) on 25-Июн-08, 02:21
	>> лучше всего в solaris :) >> никаких менеджеров - голова, блокнот и прямые руки :D Это простое человеческое щастье доступно пожалуй что на любом unix-like ;)  чем лучше-то? >+1; Очень просто, не отягощено гипертрофированными зависимостями Не переживайте, солярку уже пытаются привести в вид, приличный современному линуксу ;)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

23. "Решит ли возрождение проекта Berlin API проблемы с инсталляц..."

Сообщение от coder on 24-Июн-08, 21:01

Вряд ли это что-то решит. У Линуха должен быть свой собственный API для установки ПО. Иначе все поставщики его дистрибутивов так и будут продолжать лепить свои установщики

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	26. "Решит ли возрождение проекта Berlin API проблемы с инсталляц..."
	Сообщение от xcode on 24-Июн-08, 21:31
	>Вряд ли это что-то решит. У Линуха должен быть свой собственный API >для установки ПО. Если в итоге получится такое же глюкавое говнище как MSI инсталлер которое встает колом на каждый пшик, почти нихрена не умеет (кроме как глючить) и с массой ограничений - не, нафиг-нафиг.Линукс хорош выбором и тем что в итоге можно выбрать и что-то стоящее и нужное именно мне и именно в конкретно моих задачах порой.Вы такие умные?А покажите какую-нить систему под которую софта больше чем под .deb и .rpm?Всего 2 манагера пакетов кстати.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	54. "Решит ли возрождение проекта Berlin API проблемы с инсталляц..."
	Сообщение от oops on 25-Июн-08, 07:07
	>Если в итоге получится такое же глюкавое говнище как MSI инсталлер которое >встает колом на каждый пшик, почти нихрена не умеет (кроме как >глючить) и с массой ограничений - не, нафиг-нафиг.Линукс хорош выбором и >тем что в итоге можно выбрать и что-то стоящее и нужное >именно мне и именно в конкретно моих задачах порой. Может говнище и глюкавое, но от транзакций на unix like осях лично я бы не отказался.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	83. "транзакции"
	Сообщение от Michael Shigorin (ok) on 26-Июн-08, 02:36
	>от транзакций на unix like осях лично я бы не отказался. Для меня apt+rpm обеспечивают два уровня: - rpm умеет обломить транзакцию в несколько пакетов вплоть до момента проверки на пересечение устанавливаемых/обновляемых пакетов на пересечения по файлам; - rpm умеет обломить (откатить) установку одного пакета, если вдруг упёрлись в место/квоту/бэд/битый пакет (бишь он сперва распаковывает в файлы со случайными суффиксами и только если всё распаковалось -- unlink() старое); - apt умеет обломить транзакцию по куче условий верхнего уровня (например, исчезновение нужного какому из пакетов soname из системы); - apt умеет откатываться на пакеты с определёнными свойствами (pin-priority) -- впрочем, этим пользовался очень давно и нечасто, как-то не привык. Как с первыми двумя пунктами у dpkg -- не доводилось выяснять (это всё-таки редкие случаи), но можно предположить, что где-то сопоставимо. Вот с откатом действий, производимых пакетными скриптами, может быть полный нетривиал.  В смысле чтение их глазами да соображание, что было и что стало.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	85. "транзакции"
	Сообщение от oops on 26-Июн-08, 06:51
	>Вот с откатом действий, производимых пакетными скриптами, может быть полный нетривиал.   >В смысле чтение их глазами да соображание, что было и что >стало в этом и заключается основная проблема. Как быть если я хочу поставить несколько пакетов в одной "транзакции"? при обломе я хочу откатиться на состояние до начала установки/апгрейда..
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	97. "транзакции"
	Сообщение от Michael Shigorin (ok) on 26-Июн-08, 19:03
	>>Вот с откатом действий, производимых пакетными скриптами, может быть полный нетривиал.   >>В смысле чтение их глазами да соображание, что было и что стало >в этом и заключается основная проблема. Вопрос, как обычно -- в том, какая именно проблема стоит и сколько готовности её решать. >Как быть если я хочу поставить несколько пакетов в одной "транзакции"? См. выше, тут это выходит в основном к apt и отчасти к rpm (насчёт пересечений). >при обломе я хочу откатиться на состояние до начала установки/апгрейда.. Облом бывает разноплановый: одно дело откатить версии пакетов (это элементарно), другое -- например, "провернуть назад" фарш обновлённой базы данных после пинка в ребилдилку из постустановочного скрипта.  Или вот ещё один из частных примеров: https://bugzilla.altlinux.org/show_bug.cgi?id=14917 (rpm умеет после транзакции выполнить предварительно заданный код -- например, перестройку собственной базы; это и имелось в виду под post mortem). Бишь задача поиска обратной функции к произвольной (а именно к ней сводится вопрос отката действий скриптов) -- боюсь, нерешаемая "в лоб". В более-менее общем случае при условии пренебрежимости в разнице по остальному находящемуся на той же ФС состоянию[*]... наверное, я бы копал в сторону XFS/LVM snapshots. * бишь пользователи или там базы могут и должны жить на других ФС, нежели пакетное ПО,   если уж актуальна такая точность/гарантированность отката состояния Но до сих пор хватало даже не аптовых pin'ов, а rpm -Uvh --oldpackage, благо случаи редки и происходят там, где и ожидаются (в основном unstable на буке). Кстати, на практике с этим тоже контейнеры помогают: делаешь клон, изучаешь процесс в деталях, но без риска уронить production, и если всё устраивает -- можно перекинуть адреса и оставить старую VE-шку в качестве бэкапа, пока пыль точно не осядет.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	41. "Решит ли возрождение проекта Berlin API проблемы с инсталляц..."
	Сообщение от anonymous (??) on 25-Июн-08, 00:28
	> Вряд ли это что-то решит. У Линуха должен быть свой собственный API для установки ПО. > Иначе все поставщики его дистрибутивов так и будут продолжать лепить свои установщики Есть мнение, что <<ужасное>> состояние инсталляции под Linux не идёт ни в какое сравнение с инсталляцией на W. С _любым_ PM (или без него) я способен найти приемлемый для меня use-case. Количество вариантов-кандидатов всегда > 1.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

32. "Решит ли возрождение проекта Berlin API проблемы с инсталляц..."

Сообщение от Guest (??) on 24-Июн-08, 22:28

> Установка ПО в Linux - задача достаточно сложная и по большей части не может контролироваться даже самим пользователем системы. Черт возьми. Ну доколе?! Откуда берутся эти идиоты и откуда они берут такие сложности? - Линукс для дома - ubuntu. Synaptic - любой пакет ищется, скачивается и устанавливается/обновляется со всем зависимостями в пару кликов. Либо одной командой apt для которой надо помнить только 3 флага. - Не десктопная FreeBSD. Любой порт ищется, устанавливается, скачивается/обновляется также одной командой, либо также одним кликом через GUI к портам (забыл уже как оно зовется). В gentoo все ничем не сложнее, и подозреваю что в остальных mainstream дистрибутивах тоже. Бывшие Windows пользователи ОХРЕНЕВАЮТ, что ВЕСЬ софт ставится единообразно и мгновенно, и, при этом чисто потом удаляется. Так нет, обязательно вылезет чудо, которое придумает свой суперпростой формат пакетов. Хорошим тоном у них еще считается все зависимости статически прилинковать, ага. Ну и найдется еще пачка странных людей, которые им поддакнут (см. посты #17 и #20). `Да-да, скажут, Linux для гиков, на любой чих ./configure надо и ядро пересобрать'. Научитесь думать мозгом, а пока проходите и не задерживайте.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	49. "Решит ли возрождение проекта Berlin API проблемы с инсталляц..."
	Сообщение от Michael Shigorin (ok) on 25-Июн-08, 02:26
	>Так нет, обязательно вылезет чудо, которое придумает свой суперпростой формат пакетов. Не просто суперпростой, а особенно суперпростой с XML и бантиками. >Хорошим тоном у них еще считается все зависимости статически прилинковать, ага. Ну эт скорее у слакваристов навроде rоdlinuх. Вообще же тем, для кого synaptic сложен -- в новом распрекрасном мире показаны Wii/Xbox/PS3, мобила и тырнет-таблетка.  И никаких универсальных программируемых расширяемых компьютеров.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

58. "Решит ли возрождение проекта Berlin API проблемы с инсталляц..."

Сообщение от Аноним (??) on 25-Июн-08, 09:20

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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	65. "Решит ли возрождение проекта Berlin API проблемы с инсталляц..."
	Сообщение от kostbebix on 25-Июн-08, 11:31
	>Появится еще один бажный линуксовый пакет. Мне так линукс давно интересен только >как встраиваемая система, в пользовательскую десктоп систему, я считаю, он не >вырастет никогда. Уже выросла, осталось "привыкнуть" народу к ней. Действительно много людей (из моего круга общения) либо перешли либо переходят и довольны. А насчет: > Ну а если ты например ставишь систему на какой-нить >Colibri PXA и еще не врубился как собрать и проинсталить пакет, >то тут уж ничего не поможет. - почему бы в таком случае не сделать вариант "деньги за поддержку". Вы отваливаете раз в месяц сис. админу, который периодически помогает вам и консультирует вас. На бедно-студенческом уровне это вообще что-то типа "пиво за поддержку" :-)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	67. "Решит ли возрождение проекта Berlin API проблемы с инсталляц..."
	Сообщение от Максим (??) on 25-Июн-08, 12:19
	Мне все же кажется создовать такой Ари надо ,но для РАЗРАБОТЧИКОВ программ .Например есть Такая програма как Firefox - хочеш установить обновление или дополнение ...хм если в пакетах нет то радости писать rpm что то не испытываю .
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить	Индекс форумов | Темы | Пред. тема | След. тема
Оцените тред (1=ужас, 5=супер)? [ 1 | 2 | 3 | 4 | 5 ] [Рекомендовать для помещения в FAQ]