Разработчики проекта pkgng (https://github.com/pkgng/pkgng), в рамках которого предпринята попытка создания полнофункционального пакетного менеджера для FreeBSD, объявили (http://lists.freebsd.org/pipermail/freebsd-current/2012-Janu...) о переходе на стадию бета-тестирования. Pkgng позиционируется как отвечающая современным реалиям замена инструментария pkg_install.В настоящее время pkg_install не поддерживает ряд важных функций, связанных с управлением бинарными пакетами, таких как возможность обновления пакетов, поддержка работы с репозиториями, учёт зависимостей и полноценная поддержка метаданных. Ограничения pkg_install во многом мешают развитию инфраструктуры портов, которая вынуждена работать с оглядкой на устаревший инструментарий, что приводит к появлению различных "хаков" в Mk/bsd.*.mk и метаданных, вносимых для обхода ограничений pkg_install. Предпринимаемые ранее попытки создания более современных утилит, например, portmaster и
portupgrade, также в конеч...URL: http://lists.freebsd.org/pipermail/freebsd-current/2012-Janu...
Новость: http://www.opennet.me/opennews/art.shtml?num=32971
Дельта апдейты хочу.
В XXI-то веке экономить копейки на трафике?
Не все инернеты еще в ХХИ-то веке.
Отучаемся говорить за всех. Домашнее задание: обосновать цены за мегабайт и мегабит во всех концах РФ, как минимум.
в некоторых ситуациях сэкономленное время дороже несэкономленного трафика
Экономить на I/O вызовах к диску :)
> Дельта апдейты хочу.Такой короткий список желаний :)
Можно ли считать, что FreeBSD превращается в GNU/Linux? Наверно скоро можно будет заменить и ядро, чего уж мелочиться. :))
Хм, из текста не ясно - откажутся ли они от компиляции портов или же все в бинарниках будет?
Конечно не откажутся, иначе это как серпом по (вписать желаемое).
> Хм, из текста не ясно - откажутся ли они от компиляции портов
> или же все в бинарниках будет?в линуксах ментейнеры сразу бинари пишут?;-) зашел значит ментейнер на офсайт, глянул сырцы и ОПППАА, пакет готов, без компиляции!
Ага, cat > package.deb :)
>> Хм, из текста не ясно - откажутся ли они от компиляции портов
>> или же все в бинарниках будет?
> в линуксах ментейнеры сразу бинари пишут?;-) зашел значит ментейнер на офсайт, глянул
> сырцы и ОПППАА, пакет готов, без компиляции!Гениально просто... А то это не известно было.
Я имел ввиду - откажутся ли они от компиляции портов в том виде, к отором оно щас есть для конечно потребителя...
> Я имел ввиду - откажутся ли они от компиляции портов в том
> виде, к отором оно щас есть для конечно потребителя...а раскажи в каком виде "оно щас есть для конечно потребителя".
но сначала ответь на вопрос чтобы я знал стоит ли читать дальше твой ответ. Итак вопрос: а ты freebsd видел/пользуешься?
Пользуюсь как на десктопе, так сервера все на ней вертятся.В том виде, в котором оно щас есть можно собирать/компилить пакеты под себя (ключи, опции, и тд). В новости сказано, что будет переход к репозиториям, но не сказано что ожидает дерево портов (можно тока предполагать, что возможности описанные выше останутся).
> Пользуюсь как на десктопе, так сервера все на ней вертятся.
> В том виде, в котором оно щас есть можно собирать/компилить пакеты под
> себя (ключи, опции, и тд). В новости сказано, что будет переход
> к репозиториям, но не сказано что ожидает дерево портов (можно тока
> предполагать, что возможности описанные выше останутся).а можно не предполагать, а просто почитать как этим делом пользоваться. я про WITH_PKGNG
а зачем?
>Можно ли считать, что FreeBSD превращается в GNU/Linux? Наверно скоро можно будет заменить и ядро, чего уж мелочиться. :))Я бы, кстате, был бы не против. Я настолько был бы не против что возможно на коленке это запилю.
Ну очень мне хочется на сервере пересобирать не GENERIC ядро со своими патчами при получении изменений через csup. А потом АВТОМАТОМ отдавать это ядро на пяток машин. И чтобы кроме бинарника ядра и модулей в архиве была цифровая подпись. И конфига ядра. И примененные патчи. И дата/вермя/хост собравший это. И чтобы loader.conf проверяло на совместимость с этой сборкой.
А то как ядро не GENERIC так freebsd-update и не обновляет. А мне хочется чтобы обновлялась. На 4-х 5-и машинах. Само.
>>Можно ли считать, что FreeBSD превращается в GNU/Linux? Наверно скоро можно будет заменить и ядро, чего уж мелочиться. :))
> Я бы, кстате, был бы не против. Я настолько был бы не
> против что возможно на коленке это запилю.
> Ну очень мне хочется на сервере пересобирать не GENERIC ядро со своими
> патчами при получении изменений через csup.cd /usr/src/ & svn update & make kernel -DKERNFAST?
> А потом АВТОМАТОМ отдавать это ядро на пяток машин.
rsync? scp? nfs?
> И чтобы кроме бинарника ядра и модулей в архиве была цифровая подпись.
gpg?
> И конфига ядра. И примененные патчи. И дата/вермя/хост собравший это. И чтобы loader.conf проверяло на совместимость с этой сборкой.
> А то как ядро не GENERIC так freebsd-update и не обновляет. А
> мне хочется чтобы обновлялась. На 4-х 5-и машинах. Само.И пожевать.
> rsync? scp? nfs?Ага. Одно дело когда костыли за тебя построили, а другое - это когда тебе надо самому костыльный заводик сперва построить :). Я конечно понимаю что у пакетных менеджеров есть тот самый фатальный недостаток. Но ведь он и у любой операционки есть. Поэтому труЪ джедай должен, очевидно, написать себе операционку с нуля для начала. А то как-то нечестно ограничиваться только самопальным аналогом пакетного манагера, а операционку готовую вдуплить.
>> rsync? scp? nfs?
> Ага. Одно дело когда костыли за тебя построилиС каких пор написание простейших скриптов в 10 строк является проблемой?
Может, все таки надо прочитать что-то типа "Программирования на shell" и "Использование утилит Unix"?Конечно, есть альтернатива - наймите себе по контракту человека, и он вам их напишет.
> С каких пор написание простейших скриптов в 10 строк является проблемой?Ну вон в соседней новости как раз в тему - "Руководство по созданию простой UNIX-подобной ОС". Перефразируя, "а с каких пор написание своего юниксподобного клона является проблемой"? ;)
И кстати функциональный аналог dpkg нифига не уложится в 10 строк. Там один только хелпарь больше.
> Может, все таки надо прочитать что-то типа "Программирования на shell" и "Использование
> утилит Unix"?Ну тогда уж и соседнюю новость про свою юникс-подобную систему :)). А то что за полумеры? :)
> Конечно, есть альтернатива - наймите себе по контракту человека, и он вам
> их напишет.Удачи в продаже таких услуг. Она вам понадобится: в лине пакетные манагеры _уже_ есть, при том готовые. Бесплатно. Сегодня. А потом вы еще и удивляетесь когда ынтырпрайзы считают что ваша ось дороже в поддержании, лол :)
>> С каких пор написание простейших скриптов в 10 строк является проблемой?
> Ну вон в соседней новости как раз в тему - "Руководство по
> созданию простой UNIX-подобной ОС". Перефразируя, "а с каких пор написание своего
> юниксподобного клона является проблемой"? ;)
> И кстати функциональный аналог dpkg нифига не уложится в 10 строк. Там
> один только хелпарь больше.И? У меня скрипт обновляющий мир и ядро на всех моих машинах уложился в 18-ть строк.
> И? У меня скрипт обновляющий мир и ядро на всех моих машинах уложился в 18-ть строк.Вот только до возможностей dpkg/apt ему как раком до китая.
Example: пусть инфраструктура географически распределенная и коммуницирует через общедоступные сети типа интернета. Как делается защита от вдувания хаксорами (MITM, DNS hijack, ...) от вдувания какого попало фуфла на ровном месте? В дебиянском пакетном манагере подписи есть - там такое не пройдет. А что вы с вашим скриптом будете делать? Еще докостыливать? И вот так - куда ни ткни?
VPN, друг мой
или Вы всю сеть в Инет открываете?
> VPN, друг мойVPN не гарантирует целостности файлов сам по себе. Ты еще предложи мне сгородить скрипт который с одной стороны подписывает файлики до передачи, а с другой проверяет, чего уж там. Ну в общем да, продолжаем наворачивать костыли.
> или Вы всю сеть в Инет открываете?
Не догоняю, это что, такая недопакетная система будет мне еще и диктовать как мне инфраструктуру дизайнить и с ножом к горлу требовать подъем между всеми хостами впнов? Волшебно, бэть.
>[оверквотинг удален]
> Я бы, кстате, был бы не против. Я настолько был бы не
> против что возможно на коленке это запилю.
> Ну очень мне хочется на сервере пересобирать не GENERIC ядро со своими
> патчами при получении изменений через csup. А потом АВТОМАТОМ отдавать это
> ядро на пяток машин. И чтобы кроме бинарника ядра и модулей
> в архиве была цифровая подпись. И конфига ядра. И примененные патчи.
> И дата/вермя/хост собравший это. И чтобы loader.conf проверяло на совместимость с
> этой сборкой.
> А то как ядро не GENERIC так freebsd-update и не обновляет. А
> мне хочется чтобы обновлялась. На 4-х 5-и машинах. Само."Само" не бывает. исходники freebsd-update сервера в паблике 100500 лет, ставишь себе сервер, на нем строишь что нужно, клиентским тачкам говоришь откуда обновлться. профит.
OT: такое чувство, что слонек вышел из domene на опеннет и уже тут жжот.
> "Само" не бывает. исходники freebsd-update сервера в паблике 100500 лет, ставишь себе
> сервер, на нем строишь что нужно, клиентским тачкам говоришь откуда обновлться.
> профит.Мне только ядро интересно. Мир собирать и хранить не интересно.
Неужели идея update_kernel/install_kernel [kernel][host] настолько порочна?
>> "Само" не бывает. исходники freebsd-update сервера в паблике 100500 лет, ставишь себе
>> сервер, на нем строишь что нужно, клиентским тачкам говоришь откуда обновлться.
>> профит.
> Мне только ядро интересно. Мир собирать и хранить не интересно.
> Неужели идея update_kernel/install_kernel [kernel][host] настолько порочна?А неужели написать скрипт для себя из 10 строк - настолько сложно?
>>> "Само" не бывает. исходники freebsd-update сервера в паблике 100500 лет, ставишь себе
>>> сервер, на нем строишь что нужно, клиентским тачкам говоришь откуда обновлться.
>>> профит.
>> Мне только ядро интересно. Мир собирать и хранить не интересно.
>> Неужели идея update_kernel/install_kernel [kernel][host] настолько порочна?
> А неужели написать скрипт для себя из 10 строк - настолько сложно?Та нет, не сложно, поверьте. Просто хотелось не скрипт на 10 строчек, а что- то более... гм... универсальное наверное. Может кому и пригодится. А то каждый рожает свои скрипты на 10-100 строчек. Каждый раз.
>>>> "Само" не бывает. исходники freebsd-update сервера в паблике 100500 лет, ставишь себе
>>>> сервер, на нем строишь что нужно, клиентским тачкам говоришь откуда обновлться.
>>>> профит.
>>> Мне только ядро интересно. Мир собирать и хранить не интересно.
>>> Неужели идея update_kernel/install_kernel [kernel][host] настолько порочна?
>> А неужели написать скрипт для себя из 10 строк - настолько сложно?
> Та нет, не сложно, поверьте. Просто хотелось не скрипт на 10 строчек,
> а что- то более... гм... универсальное наверное. Может кому и пригодится.
> А то каждый рожает свои скрипты на 10-100 строчек. Каждый раз.Потребности у каждого свои, кнопку: "сделать хорошо", только в мс придумывают.
> Потребности у каждого свои, кнопку: "сделать хорошо", только в мс придумывают.Да. Остальные придумали по этому поводу более-менее универсальные манагеры пакетов.
> Та нет, не сложно, поверьте. Просто хотелось не скрипт на 10 строчек,
> а что- то более... гм... универсальное наверное. Может кому и пригодится.
> А то каждый рожает свои скрипты на 10-100 строчек. Каждый раз.Наверное поэтому я и пользуюсь дебианообразными. Приятный такой пакетный манагер. Умеет наверное практически все мыслимые загибоны которые от него мне могут потребоваться. Просто работает. И чтобы реализовать весь его функционал, мне потребуется очень долго впахивать и еще не факт что получится качественнее.
> Мне только ядро интересно. Мир собирать и хранить не интересно.
> Неужели идея update_kernel/install_kernel [kernel][host] настолько порочна?а между тем когда-то (пару лет назад, или даже больше чем пару) в яндексовой анкетке был вопрос на тему "как вы N машин под fbsd обновите". т.о. решение есть давно. намек ясен?;)
> в яндексовой анкетке был вопрос на тему "как вы N машин
> под fbsd обновите". т.о. решение есть давно. намек ясен?;)Не, ну конечно, если есть задача "хочу забить в стену гвоздь" и для нее нам по зависимостям оказался нужен молоток, в принципе можно сбегать на пару шахт за рудой и углем, отлить сталь, кой-как соорудить к нему ручку, и вот уже у нас готовый молоток, не прошло и года! Можно забивать гвоздь. Правда проблема в том что мы потратили на задачу "хочу забить в стену гвоздь" несоразмерно больше времени чем тот кто просто взял готовый молоток с полочки. Обычная цена для NIH.
>> "Само" не бывает. исходники freebsd-update сервера в паблике 100500 лет, ставишь себе
>> сервер, на нем строишь что нужно, клиентским тачкам говоришь откуда обновлться.
>> профит.
> Мне только ядро интересно. Мир собирать и хранить не интересно.
> Неужели идея update_kernel/install_kernel [kernel][host] настолько порочна?Вообще-то во фре мир должен быть синхронизирован с ядром. Делать отдельно - чревато граблями.
>>> "Само" не бывает. исходники freebsd-update сервера в паблике 100500 лет, ставишь себе
>>> сервер, на нем строишь что нужно, клиентским тачкам говоришь откуда обновлться.
>>> профит.
>> Мне только ядро интересно. Мир собирать и хранить не интересно.
>> Неужели идея update_kernel/install_kernel [kernel][host] настолько порочна?
> Вообще-то во фре мир должен быть синхронизирован с ядром. Делать отдельно -
> чревато граблями.Ну, не так все строго, например для небольших патчей, но в общем - да, прежде всего в части sbin утилит и некоторых библиотек.
>>> "Само" не бывает. исходники freebsd-update сервера в паблике 100500 лет, ставишь себе
>>> сервер, на нем строишь что нужно, клиентским тачкам говоришь откуда обновлться.
>>> профит.
>> Мне только ядро интересно. Мир собирать и хранить не интересно.
>> Неужели идея update_kernel/install_kernel [kernel][host] настолько порочна?
> Вообще-то во фре мир должен быть синхронизирован с ядром. Делать отдельно -
> чревато граблями.Так не вопрос в синхронизации. Они (мир и ядро) должны быть синхронизированы в пределах релиза. Кто мешает в архив с ядром положить его версию и при установке проверять uname?
>>>> "Само" не бывает. исходники freebsd-update сервера в паблике 100500 лет, ставишь себе
>>>> сервер, на нем строишь что нужно, клиентским тачкам говоришь откуда обновлться.
>>>> профит.
>>> Мне только ядро интересно. Мир собирать и хранить не интересно.
>>> Неужели идея update_kernel/install_kernel [kernel][host] настолько порочна?
>> Вообще-то во фре мир должен быть синхронизирован с ядром. Делать отдельно -
>> чревато граблями.
> Так не вопрос в синхронизации. Они (мир и ядро) должны быть синхронизированы
> в пределах релиза. Кто мешает в архив с ядром положить его
> версию и при установке проверять uname?Вообще-то исходная задача ни разу непонятна. Скажите, зачем может понадобиться деплоить на сервера отдельно ядро, в 2012-то году? Я понимаю, 10 лет назад на каждый чих перекомпилять надо было, но сейчас-то модулями доступно почти всё, это уже давно исключение, а не правило. Соответственно, городить специальный штатный механизм для ситуаций "возникла ошибка" - смысла мало.
Но если вам действительно нужно, в freebsd-update.conf(5) описывается опция:
Components The parameters following this keyword are the com-
ponents or sub-components of FreeBSD which will be
updated. The components are ``src'' (source code),
``world'' (non-kernel binaries), and ``kernel'';
the sub-components are the individual distribution
sets generated as part of the release process
(e.g., ``src/base'', ``src/sys'', ``world/base'',
``world/catpages'', ``kernel/smp''). Note that
prior to FreeBSD 6.1, the ``kernel'' component was
distributed as part of ``world/base''.
То есть можно сделать свой сервер freebsd-update, и вперёд.
> А то как ядро не GENERIC так freebsd-update и не обновляет. А
> мне хочется чтобы обновлялась. На 4-х 5-и машинах. Само.можно же свой сервер freebsd-update поставить и распостранять свои ядра. с цифровыми подписями, все дела.
> Можно ли считать, что FreeBSD превращается в GNU/Linux? Наверно скоро можно будет
> заменить и ядро, чего уж мелочиться. :))Можно ли считать, что поставив на автомобиль 12-цилиндровый дизельный двигатель , он автоматически превращается в тягач Скания?
> Можно ли считать, что FreeBSD превращается в GNU/Linux? Наверно скоро можно будет
> заменить и ядро, чего уж мелочиться. :))Для единообразия и о легкости обновления jail-ов базовую систему необходимо дополнить оперативно обновляемыми пакетами, вместо набора исходников для джентльменов удачи, согласен?
> Можно ли считать, что FreeBSD превращается в GNU/Linux? Наверно скоро можно будет заменить и ядро, чего уж мелочиться. :))Debian GNU/kFreeBSD уже есть и работает. О ситуации с Gentoo/FreeBSD и Arch GNU/KFreeBSD мне не известно. Но и там какой-то прогресс есть...
рамблер им уже не вернуть...
> рамблер им уже не вернуть...И яндекс...
а к версии pkgng они догадаются что и пакеты было бы неплохо подписывать ключиками
> а к версии pkgng они догадаются что и пакеты было бы неплохо
> подписывать ключикамиИнтересно, а то что они называют словом мир они допрут отпакетировать как это делают все вменяемые люди? Или по прежнему будут сватать монолитную болванку которая непонятно кому и зачем нужна?
>> а к версии pkgng они догадаются что и пакеты было бы неплохо
>> подписывать ключиками
> Интересно, а то что они называют словом мир они допрут отпакетировать как
> это делают все вменяемые люди? Или по прежнему будут сватать монолитную
> болванку которая непонятно кому и зачем нужна?Это называется исходный текст _операционной_системы_.
Начальные сведения, что такое операционная система, вы можете почитать по следующей ссылке
http://en.wikipedia.org/wiki/Operating_system
К сожалению, текст на английском более полный, чем на русском.Неплохой материал вы можете почитать
http://citforum.ru/operating_systems/unix/contents.shtmlОперационных систем много, десятки - VxWorks, HP-UX, Aix, Solaris, RTOS, Chorus, ... всех и не упомню
Родословная Unix OS
http://www.levenez.com/unix/
> Интересно, а то что они называют словом мир они допрут отпакетировать как
> это делают все вменяемые люди? Или по прежнему будут сватать монолитную
> болванку которая непонятно кому и зачем нужна?Нет, не допрут, потому что как раз вменяемые люди. Потому что свежеустановленную FreeBSD можно полноценно использовать, а в лялихе надо ещё неделю вспоминать что ещё нужно доставить и в какой идиотский пакет положили базовые утилиты.
> Нет, не допрут, потому что как раз вменяемые люди. Потому что свежеустановленную
> FreeBSD можно полноценно использовать, а в лялихе надо ещё неделю вспоминать
> что ещё нужно доставить и в какой идиотский пакет положили базовые утилиты.Тут еще не хватает упоминания о том что 640 кило хватит всем. А вас, собственно, кто делегировал за ALL решать что и для кого полноценно и в каком объеме?
>> Нет, не допрут, потому что как раз вменяемые люди. Потому что свежеустановленную
>> FreeBSD можно полноценно использовать, а в лялихе надо ещё неделю вспоминать
>> что ещё нужно доставить и в какой идиотский пакет положили базовые утилиты.
> Тут еще не хватает упоминания о том что 640 кило хватит всем.
> А вас, собственно, кто делегировал за ALL решать что и для кого полноценно и в каком объеме?А кто делегировал вас решать по общественному проекту? Вы заключили контракт, внесли аванс и контракт не выполнен?
Подключайтесь в разработчики проекта. Имейте свой голос.
> Подключайтесь в разработчики проекта. Имейте свой голос.No way! Меня в принципе не устраивает монолитная болванка вместо модульной системы. Как подход вообще, а не то что именно в него входит в частности.
>> Подключайтесь в разработчики проекта. Имейте свой голос.
> No way! Меня в принципе не устраивает монолитная болванка вместо модульной системы.
> Как подход вообще, а не то что именно в него входит
> в частности.$ ls -l /usr/src/bin
total 160
-rw-r--r-- 1 root wheel 589 2 Jan 23:41 Makefile
-rw-r--r-- 1 root wheel 157 21 Jan 2010 Makefile.inc
drwxr-xr-x 2 root wheel 512 2 Jan 23:41 cat
drwxr-xr-x 2 root wheel 512 2 Jan 23:41 chflags
drwxr-xr-x 2 root wheel 512 17 Oct 14:05 chio
drwxr-xr-x 2 root wheel 512 2 Jan 23:41 chmod
drwxr-xr-x 2 root wheel 512 2 Jan 23:41 cp
drwxr-xr-x 2 root wheel 512 2 Jan 23:41 csh
drwxr-xr-x 2 root wheel 512 2 Jan 23:41 date
drwxr-xr-x 2 root wheel 512 17 Oct 14:05 dd
drwxr-xr-x 2 root wheel 512 17 Oct 18:13 df
drwxr-xr-x 2 root wheel 512 17 Oct 14:05 domainname
drwxr-xr-x 2 root wheel 512 17 Oct 14:05 echo
drwxr-xr-x 3 root wheel 512 2 Jan 23:41 ed
drwxr-xr-x 2 root wheel 512 2 Jan 23:41 expr
drwxr-xr-x 2 root wheel 512 2 Jan 23:41 getfacl
drwxr-xr-x 2 root wheel 512 17 Oct 14:05 hostname
drwxr-xr-x 2 root wheel 512 2 Jan 23:41 kenv
drwxr-xr-x 2 root wheel 512 2 Jan 23:41 kill
drwxr-xr-x 2 root wheel 512 2 Jan 23:41 ln
drwxr-xr-x 2 root wheel 512 2 Jan 23:41 ls
drwxr-xr-x 2 root wheel 512 17 Oct 14:05 mkdir
drwxr-xr-x 2 root wheel 512 17 Oct 14:05 mv
drwxr-xr-x 2 root wheel 1024 2 Jan 23:41 pax
drwxr-xr-x 2 root wheel 512 2 Jan 23:41 pkill
drwxr-xr-x 2 root wheel 512 31 Jan 15:44 ps
drwxr-xr-x 2 root wheel 512 17 Oct 14:05 pwait
drwxr-xr-x 2 root wheel 512 17 Oct 14:05 pwd
drwxr-xr-x 2 root wheel 512 2 Jan 23:41 rcp
drwxr-xr-x 2 root wheel 512 2 Jan 23:41 realpath
drwxr-xr-x 2 root wheel 512 2 Jan 23:41 rm
drwxr-xr-x 2 root wheel 512 2 Jan 23:41 rmail
drwxr-xr-x 2 root wheel 512 17 Oct 14:05 rmdir
drwxr-xr-x 2 root wheel 512 2 Jan 23:41 setfacl
drwxr-xr-x 4 root wheel 1536 31 Jan 15:44 sh
drwxr-xr-x 2 root wheel 512 17 Oct 14:05 sleep
drwxr-xr-x 2 root wheel 512 2 Jan 23:41 stty
drwxr-xr-x 2 root wheel 512 17 Oct 14:05 sync
drwxr-xr-x 2 root wheel 512 2 Jan 23:41 test
drwxr-xr-x 2 root wheel 512 2 Jan 23:41 uuidgenИ так далее, включая различные WITHOUT_*
Извините за грубую формулировку, но по моему, монолит у вас в голове.
PS
И я буду среди первых в очереди на отрывание яиц тому, кто, к примеру, отделит /usr/src/sbin/ipfw от /usr/src/sys/netinet*.
>> Подключайтесь в разработчики проекта. Имейте свой голос.
> No way!В разработчики не хотите. Контракт на разработку не заключаете. Но требования есть.
Сделайте свой форк проекта. Закатайте в пакеты все в /usr/src до grep.pkg
Тоже не путь?
> Тоже не путь?Абсолютно. При наличии пингвинов где все эти проблемы десять раз как решены - это всего лишь ничем не оправданный геморрой от неуемного фанатизма. Не вижу смысла принципиально вскрывать 5 замков в железной двери если она стоит в чистом поле - можно просто взять и обойти. А вы дуйте за болгаркой и упирайтесь, если такой принципиальный.
>> При наличии пингвинов где все эти проблемы...В чём проблема?
> В чём проблема?В отсутствии внятного пакетного манагера и какой либо модуляризации у здорового куса системы.
> Зато в "лялихе" можно не ставить то, что тебе не нужно. А не ныть годами в интерентах когда-же-уже-наконец-выпилят-шлимыло-оно-мне-нафиг-не-нужно.$ du -sch /bin /sbin /lib /usr/lib /usr/bin/ /usr/sbin /usr/share/
680k /bin
5.0M /sbin
7.3M /lib
25M /usr/lib
66M /usr/bin/
26M /usr/sbin
35M /usr/share/
167M total$ uname -rs
FreeBSD 9.0-STABLEВот и вся операционная система. Вы отличаете понятие "operational system" от понятия "user application"?
К тому же операционная система кастомизирована
$ grep ^WITHOUT /etc/make.conf
WITHOUT_AMD = yes
WITHOUT_APM = yes
WITHOUT_CVS=yes
WITHOUT_EXAMPLES = yes
WITHOUT_FLOPPY=yes
WITHOUT_FREEBSD_UPDATE=yes
WITHOUT_GSSAPI=yes
WITHOUT_HTML = yes
WITHOUT_ICONV = yes
WITHOUT_IPX = yes
WITHOUT_KERBEROS = yes
WITHOUT_LPR=yes
WITHOUT_NCP=yes
WITHOUT_PROFILE = yes
WITHOUT_RCMDS = yes
WITHOUT_RESCUE = yes
WITHOUT_SHAREDOCS = yes
WITHOUT_TCSH=yes
>FreeBSD 9.0-STABLE
>Вот и вся операционная система.Спасибо, кэп.(с)
> Вы отличаете понятие "operational system" от понятия "user application"?
Желаете подискутировать, где кончается первое, а где начинается второе?:)
> К тому же операционная система кастомизирована
А где же
WITHOUT_BLUETOOTH="yes"
WITHOUT_GAMES="yes"
WITHOUT_TELNET="yes"
и прочие некошерности? :)
Анойним, расскажи нам почему тебя это беспокит
> А где же
> WITHOUT_BLUETOOTH="yes"
> WITHOUT_GAMES="yes"
> WITHOUT_TELNET="yes"
> и прочие некошерности? :)это вы настроить предлагаете или только напоминаете, что оно есть?
> это вы настроить предлагаете или только напоминаете, что оно есть?Я удивляюсь, что его нет в конфиге собеседника. Какбэ люди, знакомые с фряхой не первый год, обычно предпочитают обходиться без этих нужных и полезных вещей, помимо означенных в приведенном uniman конфиге.
>> это вы настроить предлагаете или только напоминаете, что оно есть?
> Я удивляюсь, что его нет в конфиге собеседника. Какбэ люди, знакомые с
> фряхой не первый год, обычно предпочитают обходиться без этих нужных и
> полезных вещей, помимо означенных в приведенном uniman конфиге.Чего? 8) Какие-такие люди? :)
Без telnet? А как поуправлять какой-нить приблудой от zyxel, cronyx or hp? У которой либо дебильная веб-морда, или и той нет, telnet и кнопка вкл?
Или на сокет с просто с демоноческой программой протокольно поговорить по душам...Чего-то рано телнет хороните.
И про блюпуп вообще как-то странно слышать. Особенно учитывая, что сдернул make.conf из под носа в нетбуке.
Не, не до чего докопаться, так за блюпуп докопались, уважаемый. Нехорошо.
> Чего? 8) Какие-такие люди? :)Давно подозревал, что одмины не люди, но надеялся на лучшее.:)
> Чего-то рано телнет хороните.
Рано так рано. Просто сам сто лет как им не пользовался.
> Не, не до чего докопаться, так за блюпуп докопались, уважаемый. Нехорошо.
Да што ж такое. То одно вам не так, то другое не эдак.:)
>> Чего? 8) Какие-такие люди? :)
> Давно подозревал, что одмины не люди, но надеялся на лучшее.:)Не админ, но тоже не надейтесь.
>> Давно подозревал, что одмины не люди, но надеялся на лучшее.:)
> Не админ, но тоже не надейтесь.Нормальное признание :)
> Без telnet? А как поуправлять какой-нить приблудой от zyxel, cronyx or hp?/usr/bin/nc же..
>> Без telnet? А как поуправлять какой-нить приблудой от zyxel, cronyx or hp?
> /usr/bin/nc же..Рекомендую изучить матчасть telnet/telnetd.
Между сокетом и вами в телнет еще есть кудрявая терминально-протокольная логика.
Согласование режимов, возможностей, и так далее.
Ее по вашему от нефик делать придумали?
>>> Без telnet? А как поуправлять какой-нить приблудой от zyxel, cronyx or hp?
>> /usr/bin/nc же..
> Рекомендую изучить матчасть telnet/telnetd.
> Между сокетом и вами в телнет еще есть кудрявая терминально-протокольная логика.
> Согласование режимов, возможностей, и так далее.
> Ее по вашему от нефик делать придумали?Это ни разу не отвечает на вопрос, "зачем это в базовой системе"... С таким же успехом туда можно засовывать все что может понадобиться хоть кому-нибудь.
>>>> Без telnet? А как поуправлять какой-нить приблудой от zyxel, cronyx or hp?
>>> /usr/bin/nc же..
>> Рекомендую изучить матчасть telnet/telnetd.
>> Между сокетом и вами в телнет еще есть кудрявая терминально-протокольная логика.
>> Согласование режимов, возможностей, и так далее.
>> Ее по вашему от нефик делать придумали?
> Это ни разу не отвечает на вопрос, "зачем это в базовой системе"...
> С таким же успехом туда можно засовывать все что может понадобиться
> хоть кому-нибудь.Telnet/telnetd - одна из базовых утилит и реализаций системы удаленного доступа к системе, портативные и реализованные во множестве систем.
В комплекте систем BSD и Unix находятся с ~1980 года (можно уточнить). Утилиты пережили несколько ревизий состава операционной системы.
Протокол telnet и утилиты входят в описание стандартов POSIX/IEEE/ISO.Мне и далее писать банальные фразы?
> Telnet/telnetd - одна из базовых утилит и реализаций системы удаленного доступа к
> системе, портативные и реализованные во множестве систем.Нужная менее чем десятой части пользователей.
> В комплекте систем BSD и Unix находятся с ~1980 года (можно уточнить).
> Утилиты пережили несколько ревизий состава операционной системы.
> Протокол telnet и утилиты входят в описание стандартов POSIX/IEEE/ISO.IPX тех же годов, тоже вполне себе стандарт. Его тоже есть смысл засовывать в базовую систему?
>> Telnet/telnetd - одна из базовых утилит и реализаций системы удаленного доступа к
>> системе, портативные и реализованные во множестве систем.
> Нужная менее чем десятой части пользователей.Покупатели, которые заключили контракт на покупку обновленной копии операционной системы?
Или вы о ком?
Не знаю, о каких пользователях вы пишете, но видимо разработчики операционной системы считают что данный комплект реализации логики сетевого терминала поверх сокетов необходимым в составе операционной системы.
Можете написать им свое личное мнение.
>> В комплекте систем BSD и Unix находятся с ~1980 года (можно уточнить).
>> Утилиты пережили несколько ревизий состава операционной системы.
>> Протокол telnet и утилиты входят в описание стандартов POSIX/IEEE/ISO.
> IPX тех же годов, тоже вполне себе стандарт. Его тоже есть смысл
> засовывать в базовую систему?POSIX семафоры тех же годов. Есть смысл их засовывать базовую систему?
И компиляторами пользуються менее 1/10 пользователей. И маке. И m4.
Про yacc и lex - вобще молчу. Вынести немедленно из системы.Оставить две программы. /kernel и /sbin/quake.
Становитесь разработчиком системы, подключайтесь в рабочую группу, и выносите на голосование.
В чем вопрос-то?У вас, впрочем, есть еще возможность обсудить еще минимум
$ ls /usr/*bin | wc -l
703
утилиты из состава операционной системы.Да, и еще сделать свой личный дистрибутив. Без этого ненужного telnet.
И наконец, просто сделать мужественный шаг:
# rm /usr/bin/telnet
>>FreeBSD 9.0-STABLE
>>Вот и вся операционная система.
> Спасибо, кэп.(с)Да пожалуйста.
>> Вы отличаете понятие "operational system" от понятия "user application"?
> Желаете подискутировать, где кончается первое, а где начинается второе?:)Нет. Границы условны, но уже устоялись.
# du -sh /*bin /lib* /usr/*bin /usr/lib*
680k /bin
5.0M /sbin
7.3M /lib
472k /libexec
66M /usr/bin
26M /usr/sbin
25M /usr/lib
116k /usr/libdata
12M /usr/libexec# du -sh /usr/local/
4.7G /usr/local/На моей памяти была горячая дискуссия о переносе perl4 из комплекта системы в /usr/local
>> К тому же операционная система кастомизирована
> А где же
> WITHOUT_BLUETOOTH="yes"
> WITHOUT_GAMES="yes"
> WITHOUT_TELNET="yes"
> и прочие некошерности? :)Таки пользуюсь. А games... да фик с ними, пущай будут, их то и оставляют в комплекте как раритеты :)
> Нет. Границы условны, но уже устоялись.Какие прикольные взаимоисключающие параграфы :)
>> Вы отличаете понятие "operational system" от понятия "user application"?
> Желаете подискутировать, где кончается первое, а где начинается второе?:)В линхе одна большая свалка в /bin /sbin /usr/bin /usr/sbin, в которую ставится все и как попало, по-этому границ там не видно, априори, че тут дискутировать?
> В линхе одна большая свалка в /bin /sbin /usr/bin /usr/sbin, в которую
> ставится все и как попало, по-этому границ там не видно, априори,
> че тут дискутировать?Вот за это я ненавижу линукс. Просто бесит. Зачем блин так всё перемешивать? Да еще всю систему перемешать символическими ссылками.
А на фряшечке я могу просто взять и rm -rf /usr/local и получу кристально чистую ОС, как только что поставленную, без единого лишнего файла.
На этом фоне лялих - куча сваленного в одну директорию го*на, любезно поделенного на "пакеты". Ставьте всё в один корневой раздел прямо в корень все файлы валите, зачем такие сложности как у бздунов?
> А на фряшечке я могу просто взять и rm -rf /usr/local и
> получу кристально чистую ОС, как только что поставленную, без единого лишнего
> файла.еще /var/db/pkg/ нужно убить.
>> А на фряшечке я могу просто взять и rm -rf /usr/local и
>> получу кристально чистую ОС, как только что поставленную, без единого лишнего
>> файла.
> еще /var/db/pkg/ нужно убить.и почистить rc.conf[.d], раз уж о кристальной чистоте речь
>>> А на фряшечке я могу просто взять и rm -rf /usr/local и
>>> получу кристально чистую ОС, как только что поставленную, без единого лишнего
>>> файла.
>> еще /var/db/pkg/ нужно убить.
> и почистить rc.conf[.d], раз уж о кристальной чистоте речьАга, и /etc/shells. И еще до кучи всякого.
> Ага, и /etc/shells. И еще до кучи всякого.Да. Потому что велосипедисты хреновы. А вот пакетный манагер склерозом как правило не страдает (иначе это как бы баг).
> А на фряшечке я могу просто взять и rm -rf /usr/local и
> получу кристально чистую ОС, как только что поставленную, без единого лишнего
> файла.А в лине можно просто взять и уе... доустановленные пакеты. Гораздо более цивилизованно, с возможностью сохранить конфиги на память или тоже убить и их, etc. Гранулярное управление софтом в системе независимо от того какие диры он использует - это хорошо. Понимаешь, мне теперь вообще не надо особо факать мозг куда именно софт свои файлы кладет и самолично стопать сервисы и вытирать файлы. На возможность цивильно выпнуть софтину это вообще не влияет.
> WITHOUT_TELNET="yes"
> и прочие некошерности? :)это тебе в линакс/виндуз7
можно конечно и netcat юзать, хотя с другой стороны и гвозди можно забивать микроскопом.
Я даже под в-ндой пользуюсь ssh. У telnet есть какие-то преимущества, о которых я не знаю?
> Я даже под в-ндой пользуюсь ssh. У telnet есть какие-то преимущества, о
> которых я не знаю?для тебя - нет. если ты вообще не знаешь для чего можно применять телнет, а для чего ssh. Кстати, у тебя убунту в дуалбуте? мне для статистики
> для тебя - нет. если ты вообще не знаешь для чего можно применять телнет, а для чего ssh.Hint: ежели не будешь ерничать, и приведешь убедительный пример, я соглашусь, что был неправ.
> Кстати, у тебя убунту в дуалбуте? мне для статистики
Нет, убунты нет. Это плохо?:)
> Нет, убунты нет. Это плохо?:)Тигра наверное просто хотел намекнуть что в убунте в отличие от фрибзды не надо хардкорно бодаться с системой, можно просто пользоваться :)
> Я даже под в-ндой пользуюсь ssh. У telnet есть какие-то преимущества, о
> которых я не знаю?telnet нужен в том числе для отладки и разработки сетевых сервисов,
работающих по tcp. smtp/nntp/http/dict etc.
> telnet нужен в том числе для отладки и разработки сетевых сервисов,
> работающих по tcp. smtp/nntp/http/dict etc.Ну значит, я еще не сталкивался с такими ситуациями, где он был бы жизненно необходим.
100 лет как есть неткат
> Я даже под в-ндой пользуюсь ssh. У telnet есть какие-то преимущества, о
> которых я не знаю?например, VXWorks в контроллере LSI Engenio (оно же IBM DS Series, оно же NetApp E-Series, оно же Sun StorageTek) удаленно не отладишь по ssh. только по telnet
> Вот и вся операционная система. Вы отличаете понятие "operational system" от понятия
> "user application"?176 метров - далеко не рекордный результат, не понятно в чем тут предмет гордости.
>> Вот и вся операционная система. Вы отличаете понятие "operational system" от понятия
>> "user application"?
> 176 метров - далеко не рекордный результат, не понятно в чем тут
> предмет гордости.Вы в состоянии прочитать сообщение целиком и понять контекст диалога?
если no написать, эффект будет тем же самым. Вообще, здесь главное присутствие строки
WITHOUT_TCSH=
а далее yes или no ничего не меняет.
Или я не прав?
> если no написать, эффект будет тем же самым. Вообще, здесь главное присутствие
> строки
> WITHOUT_TCSH=
> а далее yes или no ничего не меняет.
> Или я не прав?$ grep MK_ /usr/src/Makefile.inc1 | head
.if ${MK_GAMES} != "no"
.if ${MK_CDDL} != "no"
.if ${MK_KERBEROS} != "no"
.if ${MK_RESCUE} != "no"
.if ${MK_CRYPT} != "no"
.if ${MK_OFED} != "no"
.if ${MK_GROFF} != "no"
.if ${MK_CDDL} == "no"
.if ${MK_GROFF} != "no"
.if ${MK_BIND_LIBS} != "no"$ grep MK_ /usr/share/mk/bsd.own.mk | head -20
# Define MK_* variables (which are either "yes" or "no") for users
# Supported NO_* options (if defined, MK_* will be forced to "no",
# MK_* options which default to "yes".
.if defined(MK_${var})
.error MK_${var} can't be set by a user.
MK_${var}:= no
MK_${var}:= yes
# MK_* options which default to "no".
.if defined(MK_${var})
.error MK_${var} can't be set by a user.
MK_${var}:= yes
MK_${var}:= no
.if ${MK_LIBPTHREAD} == "no"
MK_LIBTHR:= no
.if ${MK_LIBTHR} == "no"
MK_BIND:= no
.if ${MK_BIND} == "no"
MK_BIND_DNSSEC:= no
MK_BIND_ETC:= no
MK_BIND_LIBS:= no
> Зато в "лялихе" можно не ставить то, что тебе не нужно. А
> не ныть годами в интерентах когда-же-уже-наконец-выпилят-шлимыло-оно-мне-нафиг-не-нужно.man 5 src.conf
>> Зато в "лялихе" можно не ставить то, что тебе не нужно. А
>> не ныть годами в интерентах когда-же-уже-наконец-выпилят-шлимыло-оно-мне-нафиг-не-нужно.
> man 5 src.confТак он систему в глаза не видел.
> Так он систему в глаза не видел.Таки не далее, чем дней десять назад, обновлял 8.2-STABLE до 9-RELEASE. Навидался так, что на следующий день все дразнились красноглазиком. Почему-то.:)
>> Так он систему в глаза не видел.
> Таки не далее, чем дней десять назад, обновлял 8.2-STABLE до 9-RELEASE. Навидался
> так, что на следующий день все дразнились красноглазиком. Почему-то.:)Вот вы и узнали что такое "управление изменениями" :)
Тоды, едрит его в корень, man 5 src.conf :)
> Вот вы и узнали что такое "управление изменениями" :)А еще я узнал, что иллюзия того, что я знаю фряху, была не более чем иллюзией.:)
> Тоды, едрит его в корень, man 5 src.conf :)
Курил, ибо дообновлялся до того, что пришлось снести и ставить наново. И переписывать все конфиги.
На утро подруга жизни заявила, что нормальные мужуки во сне бубнят про баб, а не про какое-то ядро. Удар дуплетом по ЧСВ.:)
Поменяйте последовательность обновлять -> читать на читать -> обновлять. А то так угробить систему недолго, да. /me обновлял с 7.x до 8.0 до 8.2, и ничо, ни писка. При этом даже (тогда) маны не сильно вкуривал. Вопрос напрашивается...
> Поменяйте последовательность обновлять -> читать на читать -> обновлять. А то так
> угробить систему недолго, да. /me обновлял с 7.x до 8.0 до
> 8.2, и ничо, ни писка. При этом даже (тогда) маны не
> сильно вкуривал. Вопрос напрашивается...Видимо, сказались последствия моих нездоровых экспериментов. 8.0->8.2 помнится, прошло без эксцессов в свое время. Ну хоть посмотрел на новый инсталлятор.:) Бедный sysinstall, я знал его, дружище анонимус...
>> Поменяйте последовательность обновлять -> читать на читать -> обновлять. А то так
>> угробить систему недолго, да. /me обновлял с 7.x до 8.0 до
>> 8.2, и ничо, ни писка. При этом даже (тогда) маны не
>> сильно вкуривал. Вопрос напрашивается...
> Видимо, сказались последствия моих нездоровых экспериментов. 8.0->8.2 помнится, прошло
> без эксцессов в свое время. Ну хоть посмотрел на новый инсталлятор.:)
> Бедный sysinstall, я знал его, дружище анонимус...Не так давно интереса ради ремотно обновил 6.4 -> 9.0 без промежутоных релизов. Полет ок.
> Не так давно интереса ради ремотно обновил 6.4 -> 9.0 без промежутоных
> релизов. Полет ок.+1, удаленно по ssh.
make installkernel; make installworld; reboot; mergemaster и далее по списку.
Главное стандартные грабли по согласно внутреннему регламенту вдумчиво переступить и все ок.
Удивительно, а у меня прошло все гладко, вот уж с 5-й ветки.Вы не пробовали поменять руки?
А при инсталляции системы можно не ставить ненужное?
> А при инсталляции системы можно не ставить ненужное?А что вам не нужно?
> А что вам не нужно?Таки вы не ответили на вопрос. В "лялихе" - можно, не во всяком разве что. Ну дак "не всякие" мне и нафиг не сдались. Про то, что можно после установки пересобрать, как нужно, я какбэ в курсе.
>> А что вам не нужно?
> Таки вы не ответили на вопрос.Отвечаю. Можно. Более того, можно вообще систему не ставить.
PS
Я че-то не понял. Вся система - около 180-200Mb, половина утилит для управления, чего там лишнее? Bind? Sendmail? Таки и они есть не просят.Усли уж совсем приспичило, то после установки
# cd /usr/src/
# make delete-old RM_I='' WITHOUT_BLABLA=yes
> # cd /usr/src/
> # make delete-old RM_I='' WITHOUT_BLABLA=yesСпасибо, не знал. Вот когда не ерничаете с вами таки очень приятственно общаться.
> Нет, не допрут, потому что как раз вменяемые люди. Потому что свежеустановленную FreeBSD можно полноценно использовать, а в лялихе надо ещё неделю вспоминать что ещё нужно доставить и в какой идиотский пакет положили базовые утилиты."Полноценно использовать" -- это как? sendmail.cf компилировать или пинги слать налево/направо?
>"Полноценно использовать" -- это как? sendmail.cf компилировать или пинги слать налево/направо?Ну а чего от линуксоида ждать то :) Сходи да посмотри что у фряхи в базовой системе - дел то.
>>"Полноценно использовать" -- это как? sendmail.cf компилировать или пинги слать налево/направо?
> Ну а чего от линуксоида ждать то :) Сходи да посмотри что
> у фряхи в базовой системе - дел то.Согласен. Я gcc, clang и bind забыл.
>>>"Полноценно использовать" -- это как? sendmail.cf компилировать или пинги слать налево/направо?
>> Ну а чего от линуксоида ждать то :) Сходи да посмотри что
>> у фряхи в базовой системе - дел то.
> Согласен. Я gcc, clang и bind забыл.админу локалхоста редко нужны dig/host, например, потому забыть легко можно, ага.
> админу локалхоста редко нужны dig/host, например, потому забыть легко можно, ага.А если они не нужны - на кой перец их вгружать в систему тогда?
>> админу локалхоста редко нужны dig/host, например, потому забыть легко можно, ага.
> А если они не нужны - на кой перец их вгружать в
> систему тогда?не нужны - не юзай. или удали. в чем проблема?
уже около 100500 раз обсуждалось, но до некоторых до сих пор никак не может дойти тот факт, что проще когда что-то УЖЕ установлено чем этого НЕТ и нет интернетиков, например, откуда можно поставить.
но ты дальше можешь продолжать рассуждать об овощах и, если хочешь, о фруктах.
> не нужны - не юзай. или удали. в чем проблема?
> уже около 100500 раз обсуждалось, но до некоторых до сих пор никак
> не может дойти тот факт, что проще когда что-то УЖЕ установлено
> чем этого НЕТ и нет интернетиков, например, откуда можно поставить.
> но ты дальше можешь продолжать рассуждать об овощах и, если хочешь, о
> фруктах.А не проще ли при установке выбрать, что именно тебе нужно? Например: http://main.makeuseoflimited.netdna-cdn.com/wp-content/uploa...
Это устроило бы обе спорящие стороны, кмк.
> не нужны - не юзай. или удали. в чем проблема?Какая-то виндовая логика. Вот вам тут сервисов на два экрана в списке задач, а вы их выключайте, если хотите. Некоторые даже как бы можно удалить.
> чем этого НЕТ и нет интернетиков, например, откуда можно поставить.
А в результате адаптабельность системы к различным применениям получается не фонтан. Ну да, можно и как в винде - почти монолитная бнопень вываленная в системные диры. Возможностей культурно вынести большую часть совершенно ненужных сервисов - нет.
> но ты дальше можешь продолжать рассуждать об овощах и, если хочешь, о фруктах.
Не, на фруктов это не тянет. Овощи, не более.
Я чуть выше постил сцылку на скриншот установки Арча. Посмотри, а? Вот так оно делается по-уму. Кто точно знает, что ему нужно, а что - нет, может выбрать, кто не знает - поставит как выбрано by default. Все довольны.
>> не нужны - не юзай. или удали. в чем проблема?
> Какая-то виндовая логика. Вот вам тут сервисов на два экрана в списке
> задач, а вы их выключайте, если хотите. Некоторые даже как бы
> можно удалить.$ grep -v ^# /etc/inetd.conf
ftp stream tcp nowait root /usr/libexec/ftpd ftpd -l -S -h
telnet stream tcp nowait root /usr/libexec/telnetd telnetd -u0 -a none
tftp dgram udp wait root /usr/libexec/tftpd tftpd -u ftp -l -s /var/tftp -w /$ ls -lh /usr/libexec/telnetd
-r-xr-xr-x 1 root wheel 66k 18 Feb 15:50 /usr/libexec/telnetd$ ls -lh /usr/libexec/ftpd
-r-xr-xr-x 1 root wheel 88k 18 Feb 15:50 /usr/libexec/ftpdВы о каких двух экранах? Вы вообще систему в глаза видели?
>>> админу локалхоста редко нужны dig/host, например, потому забыть легко можно, ага.
>> А если они не нужны - на кой перец их вгружать в
>> систему тогда?
> не нужны - не юзай. или удали. в чем проблема?
> уже около 100500 раз обсуждалось, но до некоторых до сих пор никак
> не может дойти тот факт, что проще когда что-то УЖЕ установлено
> чем этого НЕТ и нет интернетиков, например, откуда можно поставить.Зачем мне dig/host если нет интернета? Да, и если следовать такой логике, то в базовую систему нужно еще засунуть java, apache (и первый и второй), tomcat, весь комплект SQL серверов и т.д. Ну и игрушек каких поиграть на всякий случай.. С иксами, естественно. А вдруг не будет интернета?
> но ты дальше можешь продолжать рассуждать об овощах и, если хочешь, о
> фруктах.Ты пытаешься перепутать причины. При этом назвал их две:
1. Минимально необходимый набор бинарей для того чтобы что-то починить
2. Вдруг небудет интернета поставить чего-то нужного.
Первая причина понятна.. И в любом дистрибутиве есть какой-то набор базовых вещей. Вопрос только в том, что туда включать, а что нет. Вполне разумно предположить, что ни один сервис (кроме вещей, которые действительно нужны ядру) туда не должен попадать (либо должна быть возможность их отключить/заменить на этапе установки). sendmail, bind, telnet и прочий хлам явно на такие жизненно необходимые сервисы не тянет. Компилятор C/C++ в принципе тоже может быть не нужен (кроме source-based дистрибутивов, у которых попросту не поставить софт иначе).
Вторая проблема решается зеркалом в локалке. Либо болванками.
>Компилятор C/C++ в принципе тоже может быть не нуженНе нужен. Это вообще зло для пользователя. Если встретите, то сразу удаляйте.
Кстати, как вы относитесь к opensource?
> И яндекс...Яндекс не переходит на linux. А в рамблере перешёл один отдел с пустоголовым руководством.
Нашу компанию вот линуксу уже не вернуть.
> Яндекс не переходит на linux.Ага, то-то они плевались что в бсде с виртуализацией - совсем ахтунг.
> А в рамблере перешёл один отдел с пустоголовым руководством.
Этому руководству, которое никуда не собиралось - чувак из яндекса и вправил мозг, между прочим.
> Нашу компанию вот линуксу уже не вернуть.
Вы так говорите как будто от этого будет кому-то хуже кроме вас :))
>> Яндекс не переходит на linux.
> Ага, то-то они плевались что в бсде с виртуализацией - совсем ахтунг.С каких пор "виртуализация" - панацея для всех решений? Может дело не в бобине?
> С каких пор "виртуализация" - панацея для всех решений? Может дело не в бобине?С таких как
1) позволяет неплохой уровень изоляции сервисов друг от друга без затрат на отдельные железки,
2) дележ ресурсов,
3) возможность довольно оперативного перераспределения ресурсов путем сдвигания виртуалки на соседний хост
4) снапшоты там всякие.
5) бывают еще фишки типа живой миграции. Очень прикольная штука - полный нон-стоп. Никто и не заметит что допустим у сервака вентиль сдох и его отключали для починки. Поди плохо придумано, да?
>[оверквотинг удален]
> С таких как
> 1) позволяет неплохой уровень изоляции сервисов друг от друга без затрат на
> отдельные железки,
> 2) дележ ресурсов,
> 3) возможность довольно оперативного перераспределения ресурсов путем сдвигания виртуалки
> на соседний хост
> 4) снапшоты там всякие.
> 5) бывают еще фишки типа живой миграции. Очень прикольная штука - полный
> нон-стоп. Никто и не заметит что допустим у сервака вентиль сдох
> и его отключали для починки. Поди плохо придумано, да?Спасибо. Вы умница. Снапшоты там всякие, и прочие такие прикольные штуки.
К сожалению, на вопрос вы так и не ответили.
>> С каких пор "виртуализация" - панацея для всех решений? Может дело не в бобине?Но справедливости ради - у нас на фряхе с этим не густо пока.
>Поди плохо придумано, да?
Придумано просто отлично, только вот ведь всё что ты описал - это vmWare ... А при чём тут линукс тогда? Там можно опенВЗ-ой VPS-ов настрогать - это да, но к тому что ты описал это тоже сбоку ...
> Придумано просто отлично, только вот ведь всё что ты описал - это
> vmWare ... А при чём тут линукс тогда?Как бы все это умеет отнюдь не только вмвара.
> Там можно опенВЗ-ой VPS-ов настрогать - это да, но к тому что ты описал
> это тоже сбоку ...Вы там что, в каменном веке застряли с этой вашей вмварой, чтоли? Перечисленное так или иначе умеет не только вмвара, с разморозкой вас.
Оно то конечно - умеет, да вот только к примеру опенВЗ кое что из этого умеет _только_ в коммерческом варианте. И так по всему мясокомбинату - есть ньюансы :)
> И так по всему мясокомбинату - есть ньюансы :)А у вас один нюанс, зато какой: нет фичи -> нет проблем. Не вижу чем это лучше. А так то да, нюансы можно и у вмвари найти и у всех остальных. Вообще, как-то так получается что в любой программе сложнее хелловорлда можно обнаружить несколькo "нюансов" :)
> ньюансы :)Кстати ты помнится на меня наезжал по поводу что русская языка такая сложная, да? На, просветись, грамотей фигов, пусть тебе будет стыдно за свой апломб: http://www.gramota.ru/slovari/dic/?word=%ED%FC...
> нон-стоп. Никто и не заметит что допустим у сервака вентиль сдох
> и его отключали для починки. Поди плохо придумано, да?а живую миграцию же научились делать не на общем хранилище ("вентиле")?
>> С каких пор "виртуализация" - панацея для всех решений? Может дело не в бобине?
> С таких как
> 1) позволяет неплохой уровень изоляции сервисов друг от друга без затрат на
> отдельные железки,погугли что такое jail и как он работает.
> 2) дележ ресурсов,
в процессе (для jail)
> 3) возможность довольно оперативного перераспределения ресурсов путем сдвигания виртуалки
> на соседний хостесли брать в аренду 2 дедика типа c2q/8Gb ram и найти 100500 лохов которые купят у тебя там 'vps' то да, фича нужная.
> 4) снапшоты там всякие.снапшоты vm ? ну клево, только для чего оно в жизни нужно?:)
> 5) бывают еще фишки типа живой миграции. Очень прикольная штука - полный
> нон-стоп. Никто и не заметит что допустим у сервака вентиль сдох
> и его отключали для починки. Поди плохо придумано, да?расстрою: если сдох "вертиль" в серваке то live migration тебе по помощет, ибо сдохшая хранилка она дохнет для всех нод где крутятся твои виртуалочки.
> погугли что такое jail и как он работает.Погугли что такое KVM и чем это отличается, например. Да и LXC помощнее будет на данный момент. Времена когда "этих лузеров с чрутом" можно было "взять на понт" jail'ами - давно прошли. Эти ваши джайлы отстали в развитии и давно уже не эталон. А аналога гипервизора у вас вообще пока толком нет.
>> 2) дележ ресурсов,
> в процессе (для jail)А KVM благородный дон вообще не придумал чем заменить, да? :)
[del]
> если брать в аренду 2 дедика типа c2q/8Gb ram и найти 100500
> лохов которые купят у тебя там 'vps' то да, фича нужная.Это что, технично замаскированное "это не нyжно!!!111"? Знаешь, вот то что ты упомянул может это и не реализовывать. А вот тем кому критична непрерывность процесса - очень даже оценивают такие плюшки. Хотя, конечно, можно прикрывать голый зад газетой и делать вид что отсутствие щтанов - не баг а фича.
> снапшоты vm ? ну клево, только для чего оно в жизни нужно?:)
1) Для тестирования и экспериментов. Можно безнаказанно разъе.... систему напрочь и ... вернуть в вид как было. За 1 минуту. С железякой так быстро не получится, как минимум в ряде случаев. А попробуй за минуту как-то еще откатить что-то типа echo ololo > /dev/<your_disk_device> а я посмотрю как это выйдет :)
2) Для возможности быстро вернуть "как было" в случае если что-то пошло не так.
3) Для возможности заснять какую-то ситуацию (например, взлом) для ее дальнейшего изучения без жесткого лимита по времени.Хотя конечно дикарь глядя на микроволновку и плиту искренне недоумевает: зачем оно нужно? Можно же сырое мясо сожрать?!
> расстрою: если сдох "вертиль" в серваке то live migration тебе по помощет,
> ибо сдохшая хранилка она дохнет для всех нод где крутятся твои виртуалочки.Во первых, хранилка может и не жить на этом же серваке а быть отдельной сетевой сущностью, например, и совершенно не обязана отвалиться вместе с серваком. Во вторых, если хранилка была на том же серваке - есть варианты когда диск виртуалки сперва льется на ремотный хост а когда это готово и все засинхрено - на него перекидывается и выполнение. Да и вообще, нормальный сервак как-то не умирает от отказа 1 вентиля, но произвести шатдаун и заменить то - надо. Аналогично если SMART начал предвещать скорый капец и прочая.
Нет, я не спорю, можно и сырое мясо жрать. Но с плитами и микроволновками как-то жить несколько лучше.
>расстрою: если сдох "вертиль" в серваке то live migration тебе по помощет, ибо сдохшая >хранилка она дохнет для всех нод где крутятся твои виртуалочки.щито?
с какой радости, спрашивается, если помер сервер, у меня должна сдохнуть внешняя дисковая полка? правда LiveMigration тут действительно не в кассу.
>> С каких пор "виртуализация" - панацея для всех решений? Может дело не в бобине?
> С таких как
> 1) позволяет неплохой уровень изоляции сервисов друг от друга без затрат на
> отдельные железки,Это могут системы изоляции окружений типа jail без затрат процессорного времени на оверхед.
> 2) дележ ресурсов,
Аналогично.
> 3) возможность довольно оперативного перераспределения ресурсов путем сдвигания виртуалки
> на соседний хостГасишь jail. Запускаешь на другом хосте.
> 4) снапшоты там всякие.
В jail только снапшоты на уровне ФС возможны, а не виртуальной памяти, поэтому нужно гасить изолированные процессы перед перемещением окружения.
> 5) бывают еще фишки типа живой миграции. Очень прикольная штука - полный
> нон-стоп. Никто и не заметит что допустим у сервака вентиль сдох
> и его отключали для починки. Поди плохо придумано, да?Придумано неплохо, только на всё это нужно резервировать ресурсы CPU и RAM в режиме "24x7", что в случае "оффлайновых" систем изоляции окружений не нужно.
> Это могут системы изоляции окружений типа jail без затрат процессорного времени на оверхед.LXC забористее, кукуй. Впрочем это вообще не виртуализатор а контейнеры. В каком-то роде виртуализация, но совсем иная чем KVM например. В KVM можно бутануть и совсем иную операционку с напрочь иным ядром, например. В отличие от контейнеров где ядро одно на всех (==изоляция друг от друга послабее).
>> 2) дележ ресурсов,
> Аналогично.Ыгы, только LXC и то больше умеет, не говоря уж о openvz.
> Гасишь jail. Запускаешь на другом хосте.
Прерывание сервиса и заметные юзерам последствия. А можно и без этого обойтись уже. Хотя кому-то и кляча - средство передвижения, конечно.
> В jail только снапшоты на уровне ФС возможны, а не виртуальной памяти,
> поэтому нужно гасить изолированные процессы перед перемещением окружения.Это несколько не то. Понимаешь, виртуалка в XEN или KVM является полноценным виртуальным компьютером со своей периферией и независимой копией операционки. От хоста этому надо только ресурсы. В остальном это вообще вполне независимая сущность.
> Придумано неплохо, только на всё это нужно резервировать ресурсы CPU и RAM
> в режиме "24x7", что в случае "оффлайновых" систем изоляции окружений не нужно.Да но если например есть 10 серавков то держать запасной 11-й не выглядит чем-то таким уж совершенно нереальным. Более того, если его нет а кто-то сломается - обнаружится что ресурсов не хватает и ... пусть весь мир подождет, да? :))
> LXC забористее, кукуй. Впрочем это вообще не виртуализатор а контейнеры. В каком-то
> роде виртуализация, но совсем иная чем KVM например. В KVM можно
> бутануть и совсем иную операционку с напрочь иным ядром, например. В
> отличие от контейнеров где ядро одно на всех (==изоляция друг от
> друга послабее).OpenVZ - ладно. Но LXC-то чем забористее? Ну что там есть, чего нет в джейлах?
> OpenVZ - ладно. Но LXC-то чем забористее? Ну что там есть, чего
> нет в джейлах?Полисовка/лимитирование ресурсов, виртуализация сетевого стека. У джайлов с этим помнится было как-то совсем небогато.
>> OpenVZ - ладно. Но LXC-то чем забористее? Ну что там есть, чего
>> нет в джейлах?
> Полисовка/лимитирование ресурсов, виртуализация сетевого стека. У джайлов с этим помнится
> было как-то совсем небогато.Крайне лол. RCTL и VIMAGE в FreeBSD 9. Единственное, что есть в OpenVZ, чего нет в джейлах (ну мб не единственное, но единственное существенное) - это Live Migration. И то, я считаю, что для контейнеров уровня jail/OpenVZ/LXC это излишне, так как для её осуществления необходимо, чтобы на всех машинах был одинаковый CPU и система. Это достаточно серьёзные ограничения.
В случае KVM'о образных гипервизоров требуется, чтобы использовалась одна версия гипервизора на всех машинах - это вполне адекватное требование.
Отсутствие в FreeBSD виртуализации уровня KVM - недостаток. Но говорить, что нет виртуализации уровня OpenVZ считаю некорректным.
>> 1) позволяет неплохой уровень изоляции сервисов друг от друга без затрат на
>> отдельные железки,
> Это могут системы изоляции окружений типа jail без затрат процессорного времени на
> оверхед.Винду мне запусти в этой твой клетке.
>>> 1) позволяет неплохой уровень изоляции сервисов друг от друга без затрат на
>>> отдельные железки,
>> Это могут системы изоляции окружений типа jail без затрат процессорного времени на
>> оверхед.
> Винду мне запусти в этой твой клетке.НЕ НУЖНО. Как не нужно запускать 100500 линуксов в клетках (хотя это и возможно), так есть нативное ПО!
Все системы виртуализации направлены на продление жизненного цикла унаследованного ПО, которое невозможно переписать для современных ОС, либо исходники программ закрыты, либо адаптация такого ПО будет сопоставима с разработкой с нулевого цикла.
Смыл виртуализации нивелируется огромным оверхедом на преобразование бинарного кода в выполняемый современным процессором код, но посчитали, что переписать всё гораздо дороже.Системы изоляции окружений гораздо прогрессивнее и экономически выгоднее систем виртуализации, если используемое ПО новое и поддерживается на должном уровне.
> НЕ НУЖНО. Как не нужно запускать 100500 линуксов в клетках (хотя это и возможно), так есть нативное ПО!Админам локалхоста это безусловно не нужно.
> Все системы виртуализации направлены на продление жизненного цикла унаследованного ПО, которое невозможно переписать для современных ОС, либо исходники программ закрыты, либо адаптация такого ПО будет сопоставима с разработкой с нулевого цикла.
Все системы виртуализации направлены на упрощение развёртывания, обслуживания а также сокращение затрат на помещение, питание, охлаждение. Хватит в лужу то садится. Занимает десяток юнитов шасси. А там всё - и домен виндовый с ексченджем и линксом, и плюшки в виде сццм и линуховая мелочёвка для спецсофта. И никакой фряхой там не пахнет.
>> НЕ НУЖНО. Как не нужно запускать 100500 линуксов в клетках (хотя это и возможно), так есть нативное ПО!
> Админам локалхоста это безусловно не нужно.Как и всем прочим админам, не привыкшим развлекаться.
>> Все системы виртуализации направлены на продление жизненного цикла унаследованного ПО, которое невозможно переписать для современных ОС, либо исходники программ закрыты, либо адаптация такого ПО будет сопоставима с разработкой с нулевого цикла.
> Все системы виртуализации направлены на упрощение развёртывания, обслуживания а также
> сокращение затрат на помещение, питание, охлаждение. Хватит в лужу то садится.А вот не надо на "упрощение развёртывания" и сокращение затрат на охлаждение.
Нечем загрузить серваки? Так и говорите: купили всё что можно и что нельзя, чтобы на следующий год столько же выделили.> Занимает десяток юнитов шасси. А там всё - и домен виндовый
> с ексченджем и линксом, и плюшки в виде сццм и линуховая
> мелочёвка для спецсофта. И никакой фряхой там не пахнет.Милые сердцу "игрушки" админа. Процесс ради самого процесса. Имитация бурной деятельности, назвается. Вы ещё попробуйте обоснуйте запуск MS-DOS внутри Wine под Linux, который работает внутри виртуальной машины под Windows, а сама Windows запущена в VM-Ware на другом Linux. А что, старый принтер A2 с LPT-портом для бухгалтерии списывать ещё никто не собирается! :))
Тебя ещё но-даши на лоре поймал как админа локалхоста и мальчика на техподдержке. Ты это мнение подтверждаешь на 146%.> А вот не надо на "упрощение развёртывания" и сокращение затрат на охлаждение.
> Нечем загрузить серваки? Так и говорите: купили всё что можно и что нельзя, чтобы на следующий год столько же выделили.О, специалисты, такие специалисты. Под 100 серваков жрёт 3КВА. Мне очень интересно послушать специалиста, сколько это будет жрать без виртуализации. Или ты без виртуализации на одном серваке две адшки поднимешь, несколько эксченджей? А серваки грузить именно нечем. Потому что сервер, покупаемый сейчас, перекрывает запросы приложения(кроме мощных БД) как бык овцу. Он просто простаивает.
А у тебя тут какой-то бред про купили что можно и что нельзя.> Милые сердцу "игрушки" админа. Процесс ради самого процесса. Имитация бурной деятельности, назвается. Вы ещё попробуйте обоснуйте запуск MS-DOS внутри Wine под Linux, который работает внутри виртуальной машины под Windows, а сама Windows запущена в VM-Ware на другом Linux. А что, старый принтер A2 с LPT-портом для бухгалтерии списывать ещё никто не собирается! :))
Тяжело тебе там админить локалхост. Какой-то мсдос и прочее гумно. Про итил в ваших ипенях похоже и не слышали.
> Тебя ещё но-даши на лоре поймал как админа локалхоста и мальчика на
> техподдержке. Ты это мнение подтверждаешь на 146%.Еще тигар примерно в том же духе самопоймался в ЖЖшечках слоненка и анатоликса.
> грузить именно нечем. Потому что сервер, покупаемый сейчас, перекрывает запросы приложения(кроме
> мощных БД) как бык овцу. Он просто простаивает.Более того, на сервер активной директории ставить добавочные сервисы в систему будет только полный псих: взлом DC потенциально означает взлом всего домена. Поэтому без изоляции системы виртуализатором это еще и просто ссыкотное начинание.
> Еще тигар примерно в том же духе самопоймался в ЖЖшечках слоненка и анатоликса.Есть тут какая-то закономерность, явно есть. Свистеть по поводу мощных технологий и иметь под управлением только локалхост.
> Более того, на сервер активной директории ставить добавочные сервисы в систему будет только полный псих: взлом DC потенциально означает взлом всего домена. Поэтому без изоляции системы виртуализатором это еще и просто ссыкотное начинание.
Угу. Недалеко есть ексч собранный в кластер из н мейлбокс серверов и м хаб серверов. И так он бывает иногда отлично работает... Я хз что народ делал, если бы он был в одном экземпляре. А так можно подёргать на ходу разное, и народ почти не заметит.
Шоу: изя ставит на один сервер домен, ексчендж, сццм я бы с удовольствием понаблюдал.
>>>> 1) позволяет неплохой уровень изоляции сервисов друг от друга без затрат на
>>>> отдельные железки,
>>> Это могут системы изоляции окружений типа jail без затрат процессорного времени на
>>> оверхед.
>> Винду мне запусти в этой твой клетке.
> НЕ НУЖНО. Как не нужно запускать 100500 линуксов в клетках (хотя это
> и возможно), так есть нативное ПО!тебе не нужно? а другим нужно.
> Все системы виртуализации направлены на продление жизненного цикла унаследованного ПО,
> которое невозможно переписать для современных ОС, либо исходники программ закрыты, либо
> адаптация такого ПО будет сопоставима с разработкой с нулевого цикла.
> Смыл виртуализации нивелируется огромным оверхедом на преобразование бинарного кода в
> выполняемый современным процессором код, но посчитали, что переписать всё гораздо дороже.хотелось бы поглядеть цифровые выкладки по дикому оверхеду, к примеру, в PowerVM...
> Системы изоляции окружений гораздо прогрессивнее и экономически выгоднее систем виртуализации,
> если используемое ПО новое и поддерживается на должном уровне.в чем экономическая выгода?
> НЕ НУЖНО. Как не нужно запускать 100500 линуксов в клетках (хотя это
> и возможно), так есть нативное ПО!Linux в клетке ты нормально не запустишь, только юзермод от оного, не более. Ну вот смотри, в KVM можно пробросить USB или PCI девайс в виртуалку и с ним дальше будет работать драйвер там. Сделай так в jail, умник? Особенно с учетом того что под твое бсдуновое счастье с драйверами вечно какая-то SOPA.
> Все системы виртуализации направлены на продление жизненного цикла унаследованного ПО,
> которое невозможно переписать для современных ОС, либо исходники программ закрыты, либо
> адаптация такого ПО будет сопоставима с разработкой с нулевого цикла.Угу, а о изоляции, дележке ресурсов, вохможности проще балансировать нагрузку на сервера и прочие мелочи мы конечно же забудем, как "неудобные" причины на которые нам нечего возразить. Изен такой изен :).
> Смыл виртуализации нивелируется огромным оверхедом на преобразование бинарного кода в
> выполняемый современным процессором код,Чувак, большая часть кода в KVM _напрямую_ молотится процом. Гипервизор вступает в игру лишь когда нужны привилегированные операции доступные только из ring0. Поэтому чисто вычислительные дела в KVM спокойно достигают по скорости 95..99% от голого проца без виртуализатора. А какая разница кто именно один и тот же код в юзермоде выполнит? Вот с I/O похуже, требуется гейтовка привилегированных операций через гипервизор, что стандартной эмуляцией путем перехвата в гипервизоре "неправильных" обращений в ring0 делается медленно. Поэтому придумали паравиртуальные драйвера, которые предоставляют гуестовой операционке доступ к более быстрым методам выполнения I/O через гипервизор. В таком виде скорость I/O получается уже вполне себе культурной и может достигать 70-95% от голого железа. Из недостатков - в системе должен быть спецдрайвер, знающий о данном гипервизоре и как с ним работать и вывешивающий в систему виртуальный девайс.
> но посчитали, что переписать всё гораздо дороже.
Посчитали что iZEN - пещерный человек который слащe qemu без kvm в жизни ничего не видел, который к тому же еще и бредит.
> Системы изоляции окружений гораздо прогрессивнее и экономически выгоднее систем виртуализации,
> если используемое ПО новое и поддерживается на должном уровне.Ну да, ну да. Выше смотри.
>[оверквотинг удален]
> С таких как
> 1) позволяет неплохой уровень изоляции сервисов друг от друга без затрат на
> отдельные железки,
> 2) дележ ресурсов,
> 3) возможность довольно оперативного перераспределения ресурсов путем сдвигания виртуалки
> на соседний хост
> 4) снапшоты там всякие.
> 5) бывают еще фишки типа живой миграции. Очень прикольная штука - полный
> нон-стоп. Никто и не заметит что допустим у сервака вентиль сдох
> и его отключали для починки. Поди плохо придумано, да?уровень изоляции как ШИНДОВС
>>> Яндекс не переходит на linux.
>> Ага, то-то они плевались что в бсде с виртуализацией - совсем ахтунг.
> С каких пор "виртуализация" - панацея для всех решений? Может дело не
> в бобине?а где написано, что для всех? нет конечно. а вот там, где нужно эффективно использовать ресурсы железяки, при необходимости экономить электричество и физическое пространство - вполне себе. несколько десятков/сотен виртуалок разделяющих единый процессорный пул, да еще при наличии таких плюшек, как дедупликация памяти - очень себе ничего. да плюс добавить сюда живую миграцию, да всяческие NPIV'ы... в общем - там где надо, там надо. тут ведь как - одни дорвались и орут "панацея", а другие - в глаза не видели и орут "не нужно". ширше надо быть. и гибче.
Ну так в фряхе этого нет - значит никому не нужно.
> Ну так в фряхе этого нет - значит никому не нужно.Ага. Никому не нужно реализовывать это во фряхе, потому что в линухе уже есть. Можно просто взять и не париться.
>> рамблер им уже не вернуть...
> И яндекс...да, и лето 2008 также не вернуть
> рамблер им уже не вернуть...ты про это раскажи noc ихним:-)и яндексовым заодно, а то они не в курсе.
> ты про это раскажи noc ихним:-)и яндексовым заодно, а то они не в курсе.Wait and see ;)
Лучше б запилили что-то навроде гентушного portage для портов.
А чем оно сейчас не так?
> А чем оно сейчас не так?Несистемностью. В одном случае - продуманная система, а в другом - куча присобаченных костылей. Напоминает разницу между домом профессионально спроектированным и построенным по этому плану, и старой халупой, к которой годами присобачивались с одной стороны крыльцо, с другого - сараюшка, с третьей - верандочка.:)
Когда фря и гента стоят на одной машине, контраст уж больно в глаза бросается. Делаешь make config-recursive, а сам думаешь - черт, как же нормальных, кошерных use-flags не хватает!:)
>> А чем оно сейчас не так?
> Несистемностью. В одном случае - продуманная система, а в другом - куча
> присобаченных костылей. Напоминает разницу между домом профессионально спроектированным
> и построенным по этому плану, и старой халупой, к которой годами
> присобачивались с одной стороны крыльцо, с другого - сараюшка, с третьей
> - верандочка.:)
> Когда фря и гента стоят на одной машине, контраст уж больно в
> глаза бросается. Делаешь make config-recursive, а сам думаешь - черт, как
> же нормальных, кошерных use-flags не хватает!:)А мне вот наоборот фряшные порты удобнее, чем портедж. Портедж - нагромождение костылей, непонятно как работающих. Видно, что пытались всё упростить, а в итоге получился монстр. Порты же просты и понятны. Ну а для любителей монстров есть portupgrade, portmaster и portbuilder.
> Видно, что пытались всё упростить, а в
> итоге получился монстр. Порты же просты и понятны.Нууу... если конфигурирование каждого порта вместо унифицированной системы use-флагов - это "просто и понятно"...
>> Видно, что пытались всё упростить, а в
>> итоге получился монстр. Порты же просты и понятны.
> Нууу... если конфигурирование каждого порта вместо унифицированной системы use-флагов
> - это "просто и понятно"...Что-то я не пойму, как use-флаги избавляют от необходимости конфигурировать каждый порт в отдельности ?
> Что-то я не пойму, как use-флаги избавляют от необходимости конфигурировать каждый порт
> в отдельности ?Те, что прописаны в /etc/make.conf - глобальные, т.е. имеют силу для каждого порта. Ну а ежели надо для чего-то дополнительные опции, не покрываемые глобальными флагами, или наоборот - отменить действие глобального флага, то пишешь в /etc/portage/package.use, тогда флаг называется локальным и имеет над глобальным приоритет. Хендбук-то читали?
Во фряхе это тоже есть, WITHOUT_X в make.conf, например. Но нету в этом системности, видно, что опции прикручивались постепенно, по мере надобности. В portage же все изначально задумывалось так, поэтому все более логично и упорядоченно.Так что я надеюсь, что и для портов новый пакетный манагер напишут.
>[оверквотинг удален]
> Те, что прописаны в /etc/make.conf - глобальные, т.е. имеют силу для каждого
> порта. Ну а ежели надо для чего-то дополнительные опции, не покрываемые
> глобальными флагами, или наоборот - отменить действие глобального флага, то пишешь
> в /etc/portage/package.use, тогда флаг называется локальным и имеет над глобальным приоритет.
> Хендбук-то читали?
> Во фряхе это тоже есть, WITHOUT_X в make.conf, например. Но нету в
> этом системности, видно, что опции прикручивались постепенно, по мере надобности. В
> portage же все изначально задумывалось так, поэтому все более логично и
> упорядоченно.
> Так что я надеюсь, что и для портов новый пакетный манагер напишут.Если честно, то проблема "несистемности" мне кажется мягко говоря надуманной. Есть возможность установить глобальные флаги, есть возможность сконфигурировать нужный порт индивидуально. Когда вы в /etc/portage/package.use прописываете руками флаги это разве не та же самая "конфигурация вручную" ?
В данный момент это прямо скажем не самая большая проблема во FreeBSD, есть куда как более важные.
>[оверквотинг удален]
>> в отдельности ?
> Те, что прописаны в /etc/make.conf - глобальные, т.е. имеют силу для каждого
> порта. Ну а ежели надо для чего-то дополнительные опции, не покрываемые
> глобальными флагами, или наоборот - отменить действие глобального флага, то пишешь
> в /etc/portage/package.use, тогда флаг называется локальным и имеет над глобальным приоритет.
> Хендбук-то читали?
> Во фряхе это тоже есть, WITHOUT_X в make.conf, например. Но нету в
> этом системности, видно, что опции прикручивались постепенно, по мере надобности. В
> portage же все изначально задумывалось так, поэтому все более логично и
> упорядоченно.Ну почему никто не пытается интересоваться вопросом, перед тем как насмердить в лужу?
http://www.freshports.org/sysutils/portconf/
To set port-specific make variables, create the
/usr/local/etc/ports.conf configuration file
with the following syntax:---------------------------------------------------------
# this is a comment
*: NOPORTDOCS
editors/openoffice.org-2: WITH_CCACHE|LOCALIZED_LANG=it
print/ghostscript-* print/lpr-wrapper: A4
sysutils/fusefs-kmod*: !KERNCONF | !NOPORTDOCS
www/firefox-i18n: WITHOUT_SWITCHER | FIREFOX_I18N=fr it
x11/fakeport: CONFIGURE_ARGS=--with-modules="aaa bbb ccc"
---------------------------------------------------------Чем не оно? Ну и плюс в make.conf можно указать параметры ПЕРСОНАЛЬНО для каждого порта. А-ля:
.if ${.CURDIR} == ${PORTSDIR}/graphics/gimp
WITHOUT_PYTHON=true
WITH_HELP=true
.endifПризнайтесь, вы ведь скорее всего и не пытались разобраться, как можно выполнить это в FreeBSD? И скорее всего, порты вам не нравятся, просто потому, что они не портеджи, в которых вы уже *вероятно* разбираетесь.
> Так что я надеюсь, что и для портов новый пакетный манагер напишут.
Их уже три, как минимум: portupgrade, portmaster и porttbuilder. Ещё есть portshaker - что-то типо оверлеев портеджевых вроде (сам не пользовал ибо не требуется). Куда же ещё-то?
> http://www.freshports.org/sysutils/portconf/
Вы не поверите, но во Фряхе всё именно так и сделано. Вот, к примеру, выдержка из моего make.conf:# Глобальные флаги
DISTDIR= /arc/dist
PACKAGES= /arc/pkg
WRKDIRPREFIX= /tmp
NOPORTDOCS= true
NOPORTEXAMPLES= true# Флаги для отдельных портов
.if ${.CURDIR:M*/ports/graphics/php5-gd}
WITHOUT_X11=yes
.endif.if ${.CURDIR:M*/ports/www/webalizer}
WEBALIZER_LANG=russian
.endifСами порты собираются в выделенном jail с помощью portmaster и потом устанавливаются на десяток серверов в трёх разных странах через pkg_add -r ...
Я понимаю, что можно придумать систему и поудобнее, но и та, что есть, при некотором навыке, способна удовлетворить 99% потребностей.
> Я понимаю, что можно придумать систему и поудобнееЗдесь большой вопрос - что есть удобнее. Если кто-то считает, что удобнее мейк.конфа - это графинтерфейс с кучей чекбоксов, то ему лучше все-таки юзать линух. Или этот, как его... прости господи...
>> Что-то я не пойму, как use-флаги избавляют от необходимости конфигурировать каждый порт
>> в отдельности ?
> Те, что прописаны в /etc/make.conf - глобальные, т.е. имеют силу для каждого
> порта.# print/hplip without Qt GUI
.if ${.CURDIR} == ${PORTSDIR}/print/hplip
WITHOUT_GUI=true
WITHOUT_DBUS=true
WITHOUT_XSANE=true
WITH_SNMP=true
.endif> Ну а ежели надо для чего-то дополнительные опции, не покрываемые
> глобальными флагами, или наоборот - отменить действие глобального флага, то пишешь
> в /etc/portage/package.use, тогда флаг называется локальным и имеет над глобальным приоритет.% cat /var/db/ports/hplip/options
# This file is auto-generated by 'make config'.
# No user-servicable parts inside!
# Options for hplip-3.11.10
_OPTIONS_READ=hplip-3.11.10
WITHOUT_QT=true
WITHOUT_FAX=true
WITH_SNMP=true
WITHOUT_SCAN=true
WITHOUT_XSANE=true> Хендбук-то читали?
Читали. А вы?
> Во фряхе это тоже есть, WITHOUT_X в make.conf, например. Но нету в
> этом системности, видно, что опции прикручивались постепенно, по мере надобности.Чего?
> В
> portage же все изначально задумывалось так, поэтому все более логично и
> упорядоченно.Хм.
> Так что я надеюсь, что и для портов новый пакетный манагер напишут.
Для портов пакетный менеджер? Но зачем?
.if ${.CURDIR} == ${PORTSDIR}/databases/mysql51-server
.endif
Откройте для себя pkgtools.conf
Для частных случает приведите примеры негодности - вместе посмеёмся над вами.
> Когда фря и гента стоят на одной машине, контраст уж больно в
> глаза бросается. Делаешь make config-recursive, а сам думаешь - черт, как
> же нормальных, кошерных use-flags не хватает!:)аналог use флагов в опенке - flavours (вроде правильно написал)
во фре можно в make.conf захреначить какой-нить WITH[OUT]_SOMETHING, собирать с batch, проблема (да, она есть) в том, что эти KNOBS не стандартизированы и каждый ментейнер порта сам выбирает как ему обозвать эту переменную
> проблема (да, она есть) в том, что эти KNOBS не стандартизированы и каждый ментейнер порта сам выбирает как ему обозвать эту переменнуюА я про что тут и толкую. Разумеется, все не предусмотришь и не стандартизируешь, и для каких-то портов могут понадобиться свои специфичные флаги, но основную часть можно и нужно привести к единообразию и систематизировать. И это должно идти сверху, не от майнтейнеров портов, а от разрабов, и вообще вся система сборки что системы, что портов д.б. перестроена и выстроена в единую продуманную систему, а не как сейчас. Гентушный portage я привел только как пример - как оно может быть сделано.
И это реально актуально, конечно, не так, чтобы все бросить и срочно делать, но ИМХО одна из первоочередных задач, если конечно мы хотим, чтобы фри развивалась, а не зарастала мхом. Лепить костыли вроде portmaster и portupgrage поверх несовершенной в своей основе системы сборки бесконечно нельзя. Рано или поздно, придется переделывать и основу, как бы это ни было неприятно консерваторам. Слава богам, уже потихоньку начинает и до некоторых разработчиков доходить, так что можно ожидать наконец какого-то движения в этом направлении.
> И это должно идти сверху, не от майнтейнеров портов, а от
> разрабов, и вообще вся система сборки что системы, что портов д.б.никто же не запрещает сделать правильно и заслать патч?:) или Вы предлагаете кому-то из коммитеров сесть и прошерстить все 20+к портов? уже только одна мысль о таком геморе делает -100500 к желанию этим заняться
> или Вы предлагаете
> кому-то из коммитеров сесть и прошерстить все 20+к портов? уже только
> одна мысль о таком геморе делает -100500 к желанию этим занятьсяЗачем??? Достаточно выработать стандарты, и обязать коммиттеров их придерживаться. Вы прям чисто по-русски все это воспринимаете, типа высокое начальство сказало "шоб було", и прям к завтрему надо все переделать. Нормальные люди так не делают. Вы так привыкли к костылям, что не можете мыслить в ином ключе.
Это задача для Core Team. Нужно, черт возьми, принять наконец решение. Сформировать рабочую группу, которая будет заниматься разработкой. Сформулировать требования к новой системе. Потом, когда все будет написано и протестировано, обеспечить переход с очередным мажорным релизом со старого на новое. Внести изменения в porter's handbook. В общем, сделать, как делают серьезные люди, а не как школьники.
Оно понятно, что никому неохота за работу такого масштаба браться. Но оно надо, понимаешь - надо. Нельзя до бесконечности использовать решение из прошлого века, надстраивая его все новыми и новыми костылями.
>> или Вы предлагаете
>> кому-то из коммитеров сесть и прошерстить все 20+к портов? уже только
>> одна мысль о таком геморе делает -100500 к желанию этим заняться
> Зачем??? Достаточно выработать стандарты, и обязать коммиттеров их придерживаться. Вы
> прям чисто по-русски все это воспринимаете, типа высокое начальство сказало "шоб
> було", и прям к завтрему надо все переделать. Нормальные люди так
> не делают. Вы так привыкли к костылям, что не можете мыслить
> в ином ключе.окей, предположим, что выработали. кто будет старые порты приводить к стандарту?
> Это задача для Core Team. Нужно, черт возьми, принять наконец решение. Сформировать
core team занимается совершенно другими делами.
> Оно понятно, что никому неохота за работу такого масштаба браться. Но оно
> надо, понимаешь - надо. Нельзя до бесконечности использовать решение из прошлого
> века, надстраивая его все новыми и новыми костылями.вот эти наши коменты к новости о том, что работы ведутся в данном направлении.
> окей, предположим, что выработали. кто будет старые порты приводить к стандарту?У каждого порта есть коммиттер, который за него отвечает. И что значит "старые порты"? По-любому придется переделывать ВСЕ, задача - установить четкие правила и стандарты, которых надо будет придерживаться. Еще раз повторю - это не локальная задача по привинчиванию очередного костыля, это глобальное изменение, которое затронет всю ОС сверху донизу. Только в таком виде оно имеет смысл. Иначе лучше оставить как есть.
> вот эти наши коменты к новости о том, что работы ведутся в
> данном направлении.Я и написал в одном из комментов, что внушает надежду, что кто-то все же понимает необходимость изменений. Единственно, что боюсь - что все опять сведется к локальным решениям, которые суть напрасная трата ресурсов. Последнее время разговоры о том, что фри нужны глобальные изменения стали чуть ли не табу, что очень беспокоит. Кстати, просветите, если не Core Team, то кто этим должен заниматься?
>> окей, предположим, что выработали. кто будет старые порты приводить к стандарту?
> У каждого порта есть коммиттер, который за него отвечает. И что значитну, свои порты я предположим поправлю, т.к. читаю рассылки/пользуюсь системой. есть масса портов у которых ментейнер - "виртуал" (ports@), есть порты, ментейнеры которых уже не пользуются системой и т.д. сдается мне что это добрых несколько тысяч. понятно что не все из 20+к придется патчить, но всеже.
> "старые порты"? По-любому придется переделывать ВСЕ, задача - установить четкие правила
> и стандарты, которых надо будет придерживаться. Еще раз повторю - это
> не локальная задача по привинчиванию очередного костыля, это глобальное изменение, которое
> затронет всю ОС сверху донизу. Только в таком виде оно имеет
> смысл. Иначе лучше оставить как есть.именно это _пока_ и происходит.
> Я и написал в одном из комментов, что внушает надежду, что кто-то
> все же понимает необходимость изменений. Единственно, что боюсь - что всену вас, анонимов, отличать сложно. разве что user294 палится своей ограниченностью постоянно.
> опять сведется к локальным решениям, которые суть напрасная трата ресурсов. Последнее
> время разговоры о том, что фри нужны глобальные изменения стали чуть
> ли не табу, что очень беспокоит. Кстати, просветите, если не Core
> Team, то кто этим должен заниматься?portmgr.
> Лепить костыли вроде portmaster
> и portupgrage поверх несовершенной в своей основе системы сборки бесконечно нельзя.Почему это они костыли? Как раз напротив - просто ПО для автоматизации действий, которые можно сделать и руками. Хочешь - делай руками или пиши свои скрипты. Не хочешь - пользуйся портапгрейдом и т.д. Костыль как раз - это попытка полностью скрыть управление портами (которое по-сути представляет собой компиляцию и копирование файлов) за обёртками, скрывающими суть происходящего и убивающих гибкость.
Проблема портов явно не в этом. То, что опции не стандартизированы - не хорошо, то, что зависимости иногда вызывают дрожь и трепет (привет мэйнтейнеры) - тоже проблема.
Но говорить, что нет нормальных средств управления портами (когда их как минимум три, не считая работу с портами в чистом виде) - маразм.
Да системно всё и там и там, просто системы разные :) мне и то и то нравится. даже distfiles шарил между фрями и гентой :) единственное что - git >> cvs, тут уж не попрёшь. cvs -> svn конечно явное улучшение, но... ладно, главное лёд тронулся.
> Лучше б запилили что-то навроде гентушного portage для портов.Ждут вас. Подключайтесь в команду разработчиков.
> Ждут вас. Подключайтесь в команду разработчиков.Если б умел программировать - давно б уже. Забросить работу, семью и засеть за изучение С?
>> Ждут вас. Подключайтесь в команду разработчиков.
> Если б умел программировать - давно б уже. Забросить работу, семью и
> засеть за изучение С?Ну вот, началось...
> Ну вот, началось...Что? Где? Когда?
А что portage уже не работает с фряшным ядром и базовой системой? Берешь Gentoo/FreeBSD и юзаешь!
> А что portage уже не работает с фряшным ядром и базовой системой?
> Берешь Gentoo/FreeBSD и юзаешь!Если б оно было еще живое...
Нафиг это убожище.. идея может и хорошая - реализация го..но. за один только xml убил бы.
Дык реализацию по любому будет своя, не байт-в-байт же передирать. Главное-то - в систематизации, в единой системе конфигурации для всех портов, а если желательно - и для системы. Чтобы не было - тут у нас один велосипед, тут другой, и все привинчено тяп-ляп, лишь бы ехало. Врде как летом даже кто-то из core team высказывался в подобном духе, видать даже до них стало доходить...
Не прошло и ста лет.. Ну лучше поздно чем никогда.
Портанули бы portage из gentoo, проблем бы не было.
Хотя он под GPL-2...
Мдэ :-/ За вычетом sqlite3 40 килотон кода.Никогда не понимал людей, которые пишут такие вещи на С,
и потом мудохаются годами, вылавливая ошибки и критические уязвимости
вместо того, чтобы хотя бы часть функционала перенести на sh/awk/lua.
К тому же с этой штукой пропадает разделение на два уровня:
низкоуровневое управление пакетами и высокоуровневое
(a la rpm / yum|apt или dpkg / apt|aptitude).
> Никогда не понимал людей, которые пишут такие вещи на С,А почему бы и не на си? Пакетный манагер пишется на века. Некузяво если он много ресурсов жрет. А yum извините вообще кладет виртуалку с 256М памяти на лопатки, потому что какашка на питоне.
>> Никогда не понимал людей, которые пишут такие вещи на С,
> А почему бы и не на си?Потому что это небезопасно, медленно, чревато бесконечными ошибками
на протяжении десятилетия.> Пакетный манагер пишется на века.
С таким подходом гемор здесь обретается на века.
> Некузяво если он много ресурсов жрет. А yum извините вообще кладет
> виртуалку с 256М памяти на лопатки, потому что какашка на питоне.yum - это другая крайность, хотя, если не считать совсем уж экзотические условия
эксплуатации, он просто работает.
> Потому что это небезопасно, медленно, чревато бесконечными ошибками
> на протяжении десятилетия.Скорее, эта участь постигает рапидно налабаный г-нокод, где зачем-то попу рвали скорее-быстрее, в попыхах наворотили невесть что без продумывания архитектуры даже по минимуму, с кучей багов и прочая. В нормально поставленном процессе разработки кодинг вообще может не занимать львиную долю времени, но конечно же гребаным рапидчикам это не понять. Вот только пакетный манагер - немного не то место где следует рапидно девелопать, блюэээээ. Иначе получится еще один горбатый и тормозной урод типа yum, являющий собой одну большую проблему, куда ни ткни.
>> Пакетный манагер пишется на века.
> С таким подходом гемор здесь обретается на века.Не, знаете, поюзав yum - я пожалуй сишный dpkg поюзаю. Так, по итогам сравнения. Сами пользуйте ваши новомодные какашки на супермодном и безопасном языке. Потому что когда у меня при попытке инсталла пакета на виртуалке кончается память и я остаюсь даже без ssh потому что пакетный менеджер все сожрал - а шла бы такая безопасность нахрен? Этой машине 256 мегов с запасом. Мне что, ради пакетного манагера выделять виртуалке в 5 раз больше ресурсов чем надо установленным там программам? Во счастья то!
> yum - это другая крайность, хотя, если не считать совсем уж экзотические условия
> эксплуатации, он просто работает.Не вижу ничего экзотичного в пачке виртуалок, на которые для изоляции частей системы попилен хост.
p.s. честно говоря я не припоминаю каких-то особых дыр в dpkg за столько лет. А всякая распаковка файлов и криптография всяко будет делаться сишными либами и утилями, потому что если это на супердуперпетоне написать - вы все-таки задолбаетесь ждать до послезавтра пока архив распакуется.
> Никогда не понимал людей, которые пишут такие вещи на Снасколько я понимаю, pkgng - не надстройка, а полная замена всех pkg_* утилей, причем на уровне базовой системы. На чем это может быть написано кроме С - не представляю.
> и потом мудохаются годами, вылавливая ошибки и критические уязвимости
> вместо того, чтобы хотя бы часть функционала перенести на sh/awk/lua.все pkg_* исторически были всегда на C. Хорошо это или плохо - трудно сказать, но полностью на скриптовых языках это написать не очень айс.
> К тому же с этой штукой пропадает разделение на два уровня:
> низкоуровневое управление пакетами и высокоуровневое
> (a la rpm / yum|apt или dpkg / apt|aptitude).Гммм... что Вы понимаете под словами "низко" и "высоко"-уровневое управление пакетами? Разделение на подсистемы сборки и дистрибуции? Так вот, последняя как раз и появляется. Не ущемляя первую, которая уже давно была.
>> Никогда не понимал людей, которые пишут такие вещи на С
> насколько я понимаю, pkgng - не надстройка, а полная замена всех pkg_*
> утилей, причем на уровне базовой системы. На чем это может быть
> написано кроме С - не представляю.Судя по ману это не столько замена pkg_install, сколько претензия на yum/apt.
В одном флаконе так сказать.
В pkgsrc pkg_install написан на С и кода примерно 14000 строк,
то есть в 3 раза меньше, это если не считать совершенно неуместного
здесь sqlite3. Если с ним, то получается в 13(!!!) раз меньше кода.
pkgsrc-ый pkg_install -- это примерный аналог dpkg/rpm, (только лучше :-) )
Этой базы достаточно для написания поверх нормального high-level менеджера пакетов.
Свой NIH я написал на шеле, это примерно 4000 строк, функций больше, чем в pkgng
и pkgin (тоже для pkgsrc, но написан на С).
http://github.com/cheusov/pkgnih
Такой подход мне кажется более правильным, при условии, конечно,
что обновление самого себя не является проблемой.
База -- на С, обертка -- на шеле. По-моему так правильнее.>> К тому же с этой штукой пропадает разделение на два уровня:
>> низкоуровневое управление пакетами и высокоуровневое
>> (a la rpm / yum|apt или dpkg / apt|aptitude).
> Гммм... что Вы понимаете под словами "низко" и "высоко"-уровневое управление пакетами?
> Разделение на подсистемы сборки и дистрибуции? Так вот, последняя как раз
> и появляется. Не ущемляя первую, которая уже давно была.Нет. Сборку я вообще не трогаю, это отдельная песня.
Высокоуровневый -- это когда одной командой
обеспечивается согласованность установленных пакетов.
К dpkg/rpm/pkg_{add,delete} это не относится, и не должно относится.
>это если не считать совершенно неуместного здесь sqlite3Это действительно не понятно. Его запихают в базовую систему?
>База -- на С, обертка -- на шеле. По-моему так правильнее.
Но есть и не менее правильная альтернатива: база на С + достаточно функциональная библиотека на С (libpkg) + обертка на чем угодно, хоть на пистоне.
Ну и 40 000 строк кода на Си не так и много.
> Судя по ману это не столько замена pkg_install, сколько претензия на yum/apt.
> В одном флаконе так сказать.Явно не без этого.
> если не считать совершенно неуместного здесь sqlite3
по моему мнению, как раз здесь sqlite более чем уместен. Если посмотреть
в код, авторы много SQL-ных фишек используют, отсутствующих в bdb1.85 из
libc : join-ы, выборки с регэкспами, distinct-ы, сортировки и т.д. Или
Вы считаете, что этот функционал нужно обязательно заново создавать?
solaris тоже вовсю использует sqlite для хранения внутренних баз> Свой NIH я написал на шеле, это примерно 4000 строк, функций больше, чем в pkgng
> и pkgin (тоже для pkgsrc, но написан на С).
> Такой подход мне кажется более правильным, при условии, конечно,
> что обновление самого себя не является проблемой.
> База -- на С, обертка -- на шеле. По-моему так правильнее.Да, так правильнее, если наблюдение NIH-а в черном окошке терминала
является основным и главным рекомендуемым способом обновления софта.
Но как только к консольной програмке захочется приделать графическую
или веб морду, вариант с большой С-библиотекой, умеющей все функции
и маленькими фронтэндами к ней, вызывающими эти функции и представляющими
их на устройство вывода в удобоваримой форме предпочтительнее.> Высокоуровневый -- это когда одной командой
> обеспечивается согласованность установленных пакетов.
> К dpkg/rpm/pkg_{add,delete} это не относится, и не должно относится.В freebsd этим традиционно занимались portupgrade и portmaster. Думаю,
нужно ждать когда в них сделают полноценную поддержку pkgng а не просто
заменят pkg_* на pkg *. В самом pkgng в этом направлении явно еще и
конь не валялся.
>по моему мнению, как раз здесь sqlite более чем уместен. Если посмотреть
>в код, авторы много SQL-ных фишек используют, отсутствующих в bdb1.85 из
>libc : join-ы, выборки с регэкспами, distinct-ы, сортировки и т.д.Это все было бы прекрасно, если б привело к упрощению и ускорению
разработки, но пока этого не видно. Я начал писать NIH в ноябре прошлого года
и уже, в общем то, давно закончил. Код стабилен, и он работает уже сегодня,
и будет работать и дальше, никуда не денется.
pkgng же пока то ли в альфе то ли в бете.
pkgsrc-ый pkgin начал разрабатываться на год, кажется, раньше, а то и больше,
но nih уже давно предоставляет больше функций. Это не самопиар,
я говорю о выборе подходящего инструмента для данной конкретной задачи.> Или Вы считаете, что этот функционал нужно обязательно заново создавать?
Нет, я считаю, что данный функционал просто не нужен, ни в каком виде.
Кстати, почитай ман nih на предмет возможностей поиска.
Нет там никакого sqlite, не нужен он там.
Для остального -- тем более.>solaris тоже вовсю использует sqlite для хранения внутренних баз
Да ради бога, было бы это релевантно. "Модно" -- меня не убеждает.
>> База -- на С, обертка -- на шеле. По-моему так правильнее.
> Да, так правильнее, если наблюдение NIH-а в черном окошке терминала
> является основным и главным рекомендуемым способом обновления софта.Построение update plan для установки порядка 800 (восьмисот!!!) пакетов
с нуля на атоме-330 занимает порядка минуты. Да, это много, но вполне приемлимо
для запуска один раз за всю жизнь на "десктопе". Типичные же "тормоза"
на серверах или при апдейтах не превышают пяти секунд.
Встанет РЕАЛЬНАЯ проблема в этом месте,
перепишется один(один!) скрипт на С, но пока я проблемы здесь не вижу.> Но как только к консольной програмке захочется приделать графическую
> или веб морду, вариант с большой С-библиотекой, умеющей все функции
> и маленькими фронтэндами к ней, вызывающими эти функции и представляющими
> их на устройство вывода в удобоваримой форме предпочтительнее.Ну, конкретно nih написан вполне себе в духе традиционного UNIX way,
и гуй к нему лепится на счет раз. Библиотеки здесь ни при чем.>> Высокоуровневый -- это когда одной командой
>> обеспечивается согласованность установленных пакетов.
>> К dpkg/rpm/pkg_{add,delete} это не относится, и не должно относится.
> В freebsd этим традиционно занимались portupgrade и portmaster. Думаю,
> нужно ждать когда в них сделают полноценную поддержку pkgng а не просто
> заменят pkg_* на pkg *. В самом pkgng в этом направлении явно еще и
> конь не валялся.Вот именно, "нужно ждать" и "еще конь не валялся". О чем я и говорю.
> Это все было бы прекрасно, если б привело к упрощению и ускорению
> разработки, но пока этого не видно.sql - язык более высокого уровня, нежели shell или C, при правильном применении
только сокращает время разработки. честно-честно.> Я начал писать NIH в ноябре
> прошлого года
> и уже, в общем то, давно закончил. Код стабилен, и он работает
> уже сегодня,
> и будет работать и дальше, никуда не денется.
> pkgng же пока то ли в альфе то ли в бете.
> pkgsrc-ый pkgin начал разрабатываться на год, кажется, раньше, а то и больше,
> но nih уже давно предоставляет больше функций. Это не самопиар,
> я говорю о выборе подходящего инструмента для данной конкретной задачи.pkgng - не эквивалент nih
>> Или Вы считаете, что этот функционал нужно обязательно заново создавать?
> Нет, я считаю, что данный функционал просто не нужен, ни в каком
> виде.
> Кстати, почитай ман nih на предмет возможностей поиска.nih - обертка, а не пакетная система, как его можно сравнивать? nih
не хранит данные о установленных пакетах, ему это не надо. В отличие от...> Нет там никакого sqlite, не нужен он там.
> Для остального -- тем более.bdb тогда тоже не нужен. Все (почти) данные и так есть в /etc/passwd,
/etc/login.conf и т.д. Да и в линупсе/соляре без него прекрасно обходятся>>solaris тоже вовсю использует sqlite для хранения внутренних баз
> Да ради бога, было бы это релевантно. "Модно" -- меня не убеждает.отважусь процитировать себя: "join-ы, выборки с регэкспами, distinct-ы,
сортировки и т.д." - это все из кода pkgng. Конечно эту функциональность
можно реализовать и на shell, но "Код стабилен, и он работает уже сегодня,
и будет работать и дальше, никуда не денется" и занимает раз в 10 меньше
места (сами SQL statements, а не обертка их вызовов на C), нежели shell-ный
с теми-же функциями> Ну, конкретно nih написан вполне себе в духе традиционного UNIX way,
> и гуй к нему лепится на счет раз. Библиотеки здесь ни при
> чем.надеюсь, unix-way - не самоцель? Не хочу огорчать, но задача прикручивания
гуя к nih-у в процессе разработки последнего явно не ставилась. Мало того,
что с внешним миром он умеет общаться только по stdin/stdout, так и для того
чтобы получить список обновляемых пакетов надо выполнять что-то из разряда
"echo n | nih update". Разве не так?> Вот именно, "нужно ждать" и "еще конь не валялся". О чем я
> и говорю.Я почти не сомневаюсь, что port* быстро поправят. :)
>> Ну, конкретно nih написан вполне себе в духе традиционного UNIX way,
>> и гуй к нему лепится на счет раз. Библиотеки здесь ни при
>> чем.
> надеюсь, unix-way - не самоцель?Нет. Естественный ход разработки для данной задачи.
> Не хочу огорчать, но задача прикручивания
> гуя к nih-у в процессе разработки последнего явно не ставилась. Мало того,
> что с внешним миром он умеет общаться только по stdin/stdout, так и
> для того
> чтобы получить список обновляемых пакетов надо выполнять что-то из разряда
> "echo n | nih update". Разве не так?Нет, не так. См. pkg_update_plan.
>> Вот именно, "нужно ждать" и "еще конь не валялся". О чем я
>> и говорю.
> Я почти не сомневаюсь, что port* быстро поправят. :)Не то, чтобы я сомневался, но посмотрим.
> Это все было бы прекрасно, если б привело к упрощению и ускорению
> разработки, но пока этого не видно.Учтя что они обходились без нормального пакетного манагера столько лет, довольно странно и не умно теперь пытаться сэкономить на спичках, да еще при том что пакетный манагер - штука делаемая на века. Можно конечно сэкономить несколько дней разработчику. А все остальные - помучаются с кривой какашкой пару десятилетий, да? :)
>>> Никогда не понимал людей, которые пишут такие вещи на С
>> насколько я понимаю, pkgng - не надстройка, а полная замена всех pkg_*
>> утилей, причем на уровне базовой системы. На чем это может быть
>> написано кроме С - не представляю.
> Судя по ману это не столько замена pkg_install, сколько претензия на yum/apt.Судя по ману это как раз два-в-одном. Без существенной переделки pkg_install было бы невозможно сделать подобие apt-a/yum-a/zypper-a.
> В одном флаконе так сказать.
> В pkgsrc pkg_install написан на С и кода примерно 14000 строк,
> то есть в 3 раза меньше,Вы внутрь заглядывали? там костыль на костыле. Вплоть до запуска утилит из под сишного кода. Очевидно писалось наспех.. Как говорится.. нет ничего более постоянного..
> это если не считать совершенно неуместного
> здесь sqlite3. Если с ним, то получается в 13(!!!) раз меньше кода.очень даже уместного. При распухании базы хотя бы до пятисот пакетов pkg_install начинает заметно тормозить. sqlite3 мне кажется оптимальным вариантом. В 3.7 версии даже запилили WOL.
> pkgsrc-ый pkg_install -- это примерный аналог dpkg/rpm, (только лучше :-) )Не лучше. через pkg_install невозможно обновить пакет не развалив пакетную базу. Тупо не хватает нормальных зависимостей на библиотеки/ориджины. Отсутствие инфы о том с какими KNOB-ами собран пакет. Приходилось костылить. Собсно portupgrade - попытка вылечить зубы через опу(и ему это даже удается). остальные менеджеры еще менее удачны.
> Этой базы достаточно для написания поверх нормального high-level менеджера пакетов.
Если и так всё переделывать, то какая разница. При нормальной архитектуре затраты на написание на Си менеджера-обертки примерно одинаковые по сравнению с шеллом. Если не меньше.
> Нет. Сборку я вообще не трогаю, это отдельная песня.
> Высокоуровневый -- это когда одной командой
> обеспечивается согласованность установленных пакетов.
> К dpkg/rpm/pkg_{add,delete} это не относится, и не должно относится.Нет смысла. т.к. pkg_* нужно было выкинуть целиком.
>> В одном флаконе так сказать.
>> В pkgsrc pkg_install написан на С и кода примерно 14000 строк,
>> то есть в 3 раза меньше,
> Вы внутрь заглядывали? там костыль на костыле. Вплоть до запуска
> утилит из под сишного кода.Бред сивой кобылы.
> Очевидно писалось наспех.. Как говорится.. нет ничего более постоянного..
Нет.
>> это если не считать совершенно неуместного
>> здесь sqlite3. Если с ним, то получается в 13(!!!) раз меньше кода.
> очень даже уместного. При распухании базы хотя бы до пятисот пакетов pkg_install
> начинает заметно тормозить.Нет. Не начинает.
>> pkgsrc-ый pkg_install -- это примерный аналог dpkg/rpm, (только лучше :-) )
> Не лучше. через pkg_install невозможно обновить пакет не развалив пакетную базу.Нет. RTFM.
> Тупо не хватает нормальных зависимостей на библиотеки/ориджины. Отсутствие инфы о
> том с какими KNOB-ами собран пакет.С чем собран пает? Какой инфы не хватает?
> Приходилось костылить. Собсно portupgrade - попытка вылечить
> зубы через опу(и ему это даже удается). остальные менеджеры еще менее
> удачны.portupgrade к pkgsrc отношения не имеет. Иди читай документацию.
>> Этой базы достаточно для написания поверх нормального high-level менеджера пакетов.
> Если и так всё переделывать, то какая разница.Не нужно ничего переделывать, и pkgin и nih написаны поверх pkgsrc-ного pkg_install.
> При нормальной архитектуре затраты
> на написание на Си менеджера-обертки примерно одинаковые по сравнению с шеллом.
> Если не меньше.Нет.
>> Нет. Сборку я вообще не трогаю, это отдельная песня.
>> Высокоуровневый -- это когда одной командой
>> обеспечивается согласованность установленных пакетов.
>> К dpkg/rpm/pkg_{add,delete} это не относится, и не должно относится.
> Нет смысла. т.к. pkg_* нужно было выкинуть целиком.Если фришники развели бардак, пусть выкидывают и переделывают.
>>> В pkgsrc pkg_install написан на С и кода примерно 14000 строк,
>>> то есть в 3 раза меньше,
>> Вы внутрь заглядывали? там костыль на костыле. Вплоть до запуска
>> утилит из под сишного кода.
> Бред сивой кобылы.Please look into the <srcdir>/usr.sbin/pkg_install/lib/
file.c:
copy_file
move_file
copy_hierarchy
unpackpen.c:
leave_playpenНу и как бы текущий формат пакета и его возможности говорят сами за себя. Ощущение, что это прилепка сбоку к портовой системе не покидает ни на минуту вот уже лет десять. При всей моей любви к фрюше.
>>> pkgsrc-ый pkg_install -- это примерный аналог dpkg/rpm, (только лучше :-) )
>> Не лучше. через pkg_install невозможно обновить пакет не развалив пакетную базу.
> Нет. RTFM.Кругом смешались люди.. кони.. Тут моя ошибка. Вы всё время говорили о NetBSD-шном пакетном менеджере. Я же здесь и далее говорил о фрюшном.
> Приходилось костылить. Собсно portupgrade - попытка вылечить
> зубы через опу(и ему это даже удается). остальные менеджеры еще менее
> удачны.
> portupgrade к pkgsrc отношения не имеет.Равно как и pkgsrc не имеет отношения к fbsd.
> Иди читай документацию.
Еще раз прошу прощения.
Сейчас сижу на FOSDEM и слушаю доклад создателя pkgng.
Очень интересная вещь и это появится в 9.1 и 10.0
То что он сделал не идеально, но намного лучше того что есть.
Кстати, он работает с ребятами из NetBSD, OpenBSD и Minix - есть шанс что это станет частью дистрибутива в будущем. И вообще, этот парень очень даже вменяемый, думаю что всё получится.
Там будет ещё и тонкая настройка опций сборки пакетов и автоматическая минимизация зависимостей с пересборкой того что нужно.
Вообще они хотят заменить portmaster/portupgrade :)
> Кстати, он работает с ребятами из NetBSD.С кем конкретно?
>>> Кстати, он работает с ребятами из NetBSD.
>> С кем конкретно?
>Догнать и спросить? :)Неплохо было бы, потому как на мой взгляд pkgng NetBSD/pkgsrc не нужен даром.
Есть НОРМАЛЬНЫЙ (в отличие от) pkg_install, есть pkgin, есть nih.
Более чем достаточно.
Надо ему теперь писать емэйл тогда чтобы узнать про NetBSD...Про pkgin кто-то делал доклад вчера после обеда, но я в то время был в другой devroom.
Кажется этот pkgin только бинарные пакеты умеет, нет?
Про nih не слышал, ничего не скажу, надо посмотреть.На мой взгляд, если собрать все здравые идеи вместе, то можно сделать хороший менеджер пакетов/портов.
Из того что ещё мне запомнилось про pkgng - он умеет делать in-place upgrade, т.е. обсчитывает какие файлы заменяются и делает самый минимум телодвижений.
Батист (автор-докладчик) говорит что использует его (уже скоро год как) у себя на рабочих серверах, говорит что всё очень шустро работает и готово уже к более массовому тестированию.Мне лично не нравится наличие SQLite в этой связке, и не только мне.
Его спросили зачем ему эта зависимость - говорит что сильно упрощается логика.
> Надо ему теперь писать емэйл тогда чтобы узнать про NetBSD...Я не припомню ни людей ни обсуждений замены pkg_install в NetBSD.
К нему нет претензий.> Про pkgin кто-то делал доклад вчера после обеда, но я в то
> время был в другой devroom.Наверняка автор же и читал (iMil).
> Кажется этот pkgin только бинарные пакеты умеет, нет?
Да, только бинарные. nih (пока) тоже работает только с бинарными.
> Про nih не слышал, ничего не скажу, надо посмотреть.
http://mova.org/~cheusov/pub/pkgnih/nih.txt
http://github.com/cheusov/pkgnih> Из того что ещё мне запомнилось про pkgng - он умеет делать
> in-place upgrade, т.е. обсчитывает какие файлы заменяются и делает самый минимум
> телодвижений.Мелкая фича, вполне реализуемая в pkg_add.
> Мне лично не нравится наличие SQLite в этой связке, и не только
> мне.
> Его спросили зачем ему эта зависимость - говорит что сильно упрощается логика.Как и автор pkgin он засунул sqlite3 внутрь.
Ман для сравнения и README по ссылкам выше.
О, так ты и есть автор nih :)
Почитал readme, интересно.
Есть вопрос - оно на FreeBSD заведётся?
> О, так ты и есть автор nih :)Есть грешок :-) Если б еще и я приперля на FOSDEM (в это году меня не было),
был бы полный набор конкурентов :-)> Почитал readme, интересно.
Ман интереснее ;-)
> Есть вопрос - оно на FreeBSD заведётся?
Поверх freebsd-шных пакетов, конечно, нет. Кое-какие вещи надо унифицировать для начала,
но неразрешимых проблем не вижу.
На FreeBSD/pkgsrc конечно будет работать.
> Вообще они хотят заменить portmaster/portupgrade :)ха-а-а-а. цитирую страницу проекта с вики:
pkgng is not:
...
a replacement for portupgrade/portmaster
>> Вообще они хотят заменить portmaster/portupgrade :)
> ха-а-а-а. цитирую страницу проекта с вики:Мне кажется что то, что говорит сам разработчик авторитетнее чем вики проекта
> pkgng is not:
> ...
> a replacement for portupgrade/portmasterПока что это не замена, всё правильно.
Но на прямой вопрос о планах проекта ответ был -
да, пора навести в этом зоопарке порядок,
всё должно делаться штатными средствами.
Можно поподробнее про минимизацию зависимостей?
