В рамках проекта Linuxbrew (http://brew.sh/linuxbrew/) ведётся разработка Linux-форка Homebrew (http://brew.sh/), популярного пакетного менеджера для платформы OS X. Linuxbrew позволяет устанавливать приложения в свою домашнюю директорию, не требуя для установки программ привилегий администратора. Проект написан на языке Ruby и распространяется (https://github.com/Homebrew/linuxbrew) под лицензией BSD.Пакеты формируются в универсальном представлении, не привязанном к отдельным дистрибутивам Linux, что делает Linuxbrew удобным инструментом для установки свежих версий программ в устаревших дистрибутивах, не поставляющих обновления для данных программ через штатные репозитории. Так как интерфейс и опции Linuxbrew полностью аналогичны Homebrew, пользователи получают возможность применения одного инструмента для управления программами на системах с Linux и OS X.
Более того, в Linuxbrew можно использовать пакеты, размещённые в репозиториях (http://braumeister.org/) пакетов Homebrew, так как формат пакетов (https://github.com/telemachus/homebrew-desc) подразумевает возможность пересборки из исходных текстов перед установкой (по сути пакет является простым сценарием (https://github.com/Homebrew/homebrew/tree/master/Library/For.../), показывающим где загрузить код и какую команду выполнить для сборки).
URL: http://brew.sh/linuxbrew/
Новость: http://www.opennet.ru/opennews/art.shtml?num=41213
> Linuxbrew ... распространяется под лицензией BSDстранный выбор для программы
Вот именно, надо было под GPL3 форкать. Чтобы макакам не повадно было код тырить. :)
Он изначально под Мак и выпускается, так что кто у кого тырит то
Ну так у них - можно и даже нужно, это у нас "нельзя".
Так написано же:> на языке Ruby и распространяется под лицензией BSD.
Сразу видно - макофажные хипстеры левой пяткой писали, чтобы поиграть в разработчиков немного.
минимум надо было называть Freeb{sd}rew
Дак у Homebrew ровно та же 2-clause BSD. И авторы линуксового форка, конечно же, хотят иметь возможность обмениваться кодом. А мнение кого-то из диванных аналитиков опеннета о том, что BSD плохо, а GPL хорошо, им какбе не очень роялит.
с удовольствием гляну, как это взлетит
можно будет повыбрасывать кучу прикладных программ из пакетной базы, дистрибутивы сократятся в разы!
Так же, как десяток подобных глупостей в прошлом - никак.
> с удовольствием гляну, как это взлетитЛетные качества этой фигни - на уровне "Титаника".
> с удовольствием гляну, как это взлетиткак титановая болванка: круто, но невысоко. если успеть вовремя отбежать — даже упадёт без особых разрушений.
> с удовольствием гляну, как это взлетит
> можно будет повыбрасывать кучу прикладных программ из пакетной базы, дистрибутивы сократятся
> в разы!так же как и докеры, кореосы и прочая лабуда, тaщемта.
> с удовольствием гляну, как это взлетитВ разы более жизнеспособный pkgsrc за пределами родной платформы что-то не взлетел, а кривущая поделка на ruby взлетит?
Из цикла, а теперь давайте вам ~/ засрём.
При чём каждый отдельно :)
юзкейс: для запуска rails-приложения нужен свежий ruby. в вашем дистрибутиве 1.8.7 (а то и 1.8.4) и его заменить свежим при сохранении работоспособности системы невозможно.и что, вы в такой ситуации не будете пользовать rvm/rbenv? а что взамен?
собственно, в этом контексте brew для цели "поставить непротухлый руби/питон" ничуть не хуже. хоть в хомяк, хоть в /usr/local (а на маке оно так и работает).
ещё один юзкейс. вам нужен golang crosscompile toolchain для mac, win и linux (допустим, на машине разработчика). я делаю это так: `brew install go --cross-compile-common`. вы делаете это проще?
Да хоть в /usr/local, хоть в /opt. И обязательно создавать пакет средствами самого дистрибутива, а не просто make install.
Админов с таким срачем, как программы в хомяке - расстреливать надо.
>а не просто make install.Вот вы и попались на том что совершенно не знаете как работает brew. Зато высказать свое мнение аналитега это пожалуйста.
> Вот вы и попались на том что совершенно не знаете как работает brew.А зачем ему об этом знать? У него поди нормальный пакетный менеджер в системе, или типа того. А гемор с десятком версий интерпретатора есть только у шкoлoтных рубистов и прочих питонистов.
вы не поняли вопрос. надо: ruby 2.1, в системе 1.8.7 и его трогать нельзя. система -- допустим, шестой центос.я делаю так: curl -sSL https://get.rvm.io | bash -s stable --ruby=2.1
хочу -- ставится в /usr/local, хочу -- в /home, это здесь неважно.вы делаете это проще? быстрее? эффективнее? удобнее обновления?
и это всё собирая свой RPM на коленке и поднимая собственную репу для них? вот уж не верю, извините.
> юзкейс: для запуска rails-приложения нужен свежий ruby. в вашем дистрибутиве 1.8.7 (а
> то и 1.8.4) и его заменить свежим при сохранении работоспособности системы невозможно.При том почему-то такие юзкейсы есть в основном у рубистов и питонистов. Раздать им мечи и пусть выяснят чей ЯП круче. А мы потом придем и добьем выживших.
>> юзкейс: для запуска rails-приложения нужен свежий ruby. в вашем дистрибутиве 1.8.7 (а
>> то и 1.8.4) и его заменить свежим при сохранении работоспособности системы невозможно.
> При том почему-то такие юзкейсы есть в основном у рубистов и питонистов.
> Раздать им мечи и пусть выяснят чей ЯП круче. А мы
> потом придем и добьем выживших.покажите go cross-compilation toolchain в репах вашего дистрибутива (а потом для распространённых типа ubuntu, debian и centos), раз так не нравится примеры с рантаймом.
это был юзкейс №2, который вы проглядели.
>> ещё один юзкейс. вам нужен golang crosscompile toolchain для mac, win и linux
>> (допустим, на машине разработчика). я делаю это так: `brew install go --cross-compile-common`.
>> вы делаете это проще?
Есть те, кто монтируют хомяк с правами на запуск ?
Да практически все.
noexec на /home на практике мало от чего спасает, а жизнь осложняет изрядно.
>мало от чего спасает, а жизнь осложняет изрядно.Ага, а SELinux очень неудобно и мало от чего спасает, а iptables на десктопе не нужен, а cyrptsetup на / раздел глуплсть, а права 777 это удобно, может вас еще и фольовая шапочка не спасает ?
Развелось тут понимаешь "умных программистов" , потом пол дня думааешь, почему прога не работает и на кой хрен программе запуск из хомяка нужет, а им видите ли удобно так было.
>Ага, а SELinux очень неудобноТак оно и правда неудобно: только мешается почём зря. Если проблемы со звуком — гаси Пульс, c сетью — НетворкМанагер, с чем-то ещё — АНБ-шную поделку.
>мало от чего спасает
Неудобные вещи и правда мало от чего спасают, потому как мало у кого хватает нервов ими пользоваться.
>iptables на десктопе не нужен
Отдельные человекоособи в своей дурости меры не знают, верно.
>cyrptsetup на / раздел глуплсть
На весь корень? Не скажу, что прям уж глупость, но далеко не самая умная вещь, особенно если надо надёжно зашифровать важную информацию, а не повыпендриваться.
>права 777 это удобно
В ряде случаев — да. В остальных — есть подходящие для этих случаев варианты.
Что до noexec — так где-то надо выполнять скрипты, собственные проекты и прочее. Хомяк в этом отношении ничуть не хуже любого другого каталога. Кому эти самые опции монтирования помешают? Скачанной в ~/Downloads заразе, которую сам пользователь и запустит? Не самый распространённый у nix-пользователей юзкейс, но ок, можно с noexec перемонтировать ~/Downoads. Будем считать, что с раздела с проектами ничего этакого уж точно не запустим. Из ~/Downloads точно б запустили, а тут — ни-ни. От дыры в том же браузере noexec`и на хомяке никак не защитят. Так смысл?
>Если проблемы со звуком — гаси Пульс, c сетью — НетворкМанагер, с чем-то ещё — АНБ-шную поделку.Modern Linux desktop
Можно подумать, где-то сильно лучше. Тенденции везде одинаковые, просто кое где ненужное пока ещё можно отключить.
В целом, согласен
Ты предлагаешь всем программистам вести разработку от рута, а пользователям довольствоваться мышекликаньем? Или ты просто прочитал умное правило, но мозга не хватило осилить область его применения?
Я монтирую. Во-первых, у меня в ~/bin валяется несколько скриптов/бинарей, для более приятного моего существования в системе. Во-вторых, довольно геморно запускать что-либо только что написанное/скомпилированное. Скрипт можно запустить и без chmod +x, а вот скомпилированное в elf, уже так просто не выйдет запустить.Ну и да, каюсь, со мной случается сказать configure --prefix=$HOME/local; make && make install. Иногда когда хочется дебуггером пройтись по библиотечному коду, или посмотреть как те или иные изменения кода отразятся на работе библиотеки/программы -- это наиболее удобный способ. Потому что никаких заморок с пакетными менагерами, а сносится всё это путём rm -rf ~/local. Пихать же всякую такую лабуду в /usr/local... Да ну нах. Я лучше весь этот девелоперский бардак ограничу рамками $HOME.
Приятно слышать, что я не один такой.
А у вас тоже в домашнем каталоге лежит файлик LFHS (от "Local FHS") с описанием какой каталог для чего предназначается? =)
> Приятно слышать, что я не один такой.
> А у вас тоже в домашнем каталоге лежит файлик LFHS (от "Local
> FHS") с описанием какой каталог для чего предназначается? =)Нет, не лежит. А что это за файлик, и что он даёт? Где про это почитать можно?
>> Приятно слышать, что я не один такой.
>> А у вас тоже в домашнем каталоге лежит файлик LFHS (от "Local
>> FHS") с описанием какой каталог для чего предназначается? =)
> Нет, не лежит. А что это за файлик, и что он даёт?
> Где про это почитать можно?Да нет, это я, когда понял, что в моём домашнем каталоге появляется вполне структурированное дерево, сам написал этот файлик, чтобы упорядочить содержимое и рассортировать. Я подумал, вдруг у Вас есть что-то подобное. =)
>>> Приятно слышать, что я не один такой.
>>> А у вас тоже в домашнем каталоге лежит файлик LFHS (от "Local
>>> FHS") с описанием какой каталог для чего предназначается? =)
>> Нет, не лежит. А что это за файлик, и что он даёт?
>> Где про это почитать можно?
> Да нет, это я, когда понял, что в моём домашнем каталоге появляется
> вполне структурированное дерево, сам написал этот файлик, чтобы упорядочить содержимое
> и рассортировать. Я подумал, вдруг у Вас есть что-то подобное. =)Не. find и locate мои лучшие друзья. :)
>позволяет устанавливать приложения в свою домашнюю директорию, не требуя для установки программ привилегий администратораОх, неужели настал тот день, когда на десктоп можно будет поставить CentOS и при этом не испытывать дискомфорт из-за отсутствия/тухлости софта.
Хм, а ведь дельная мысль!
Debian stable же
>>позволяет устанавливать приложения в свою домашнюю директорию, не требуя для установки программ привилегий администратора
> Ох, неужели настал тот день, когда на десктоп можно будет поставить CentOS
> и при этом не испытывать дискомфорт из-за отсутствия/тухлости софта.засрав все хоумы троянами, да
Какой вообще смысл ставить центос на десктоп? И какой смысл загаживать древний, но дубовый центос сторонним софтом?
> И какой смысл загаживать древний, но дубовый центос сторонним софтом?дадад. запустите мне gitlab на centos 5, не ставя стороннего софта. а на 6?
mysql/postgres-сервер на centos с пакетами из оф. реп centos -- тоже сомнительное удовольствие, есличо.
а nginx в оф. репах centos покажете (для тупых: EPEL/repoforge -- не оф. репы centos)?
> дадад. запустите мне gitlab на centos 5, не ставя стороннего софта. а
> на 6?Плати бабки запилю тебе rpm, сладенький одмин.
>> не ставя стороннего софта
> Плати бабкиа ты точно запустишь свежий gitlab (требует ruby 2.0+) на centos 5 (ruby 1.8.4), не ставя стороннего софта? ну, тогда расскажи, откуда в centos 5 возьмётся ruby 2.1, а то пока не верится.
> дадад. запустите мне gitlab на centos 5, не ставя стороннего софта. а на 6?А вы залезьте на фонарный столб, намазанный маслом? В ластах и противогазе. Голышом, в минус двадцать. Нафига - я и сам не знаю! Но шоу обещает быть хорошим.
> mysql/postgres-сервер на centos с пакетами из оф. реп centos -- тоже сомнительное
> удовольствие, есличо.А зачем вам вообще сдалось докостыливать древнюю как помет мамонта систему свежим софтом? Может лучше попробуете на столб, в ластах? Это по крайней мере позабавит толпу зевак. А у вас цирк какой-то мазохистичный и не зрелищный.
> а nginx в оф. репах centos покажете (для тупых: EPEL/repoforge -- не
> оф. репы centos)?Как бы сборок нжинкса под вон ту систему ниппель тоже нет. Да и не очень понятно нафиг вам авангардизм с нжинксом в системе где весь софт замшелый.
>> mysql/postgres-сервер на centos с пакетами из оф. реп centos -- тоже сомнительное
>> удовольствие, есличо.
> А зачем вам вообще сдалось докостыливать древнюю как помет мамонта систему свежим
> софтом?а надо всю систему выбросить т.к. аноним с опеннета считает это некошерным? я с red hat linux 15 лет работаю, а вас с вашими представлениями первый раз вижу, не авторитетно как-то получается.
Ага. Откроем дорогу на компьютеры пользователей зловредам типа шифровальщиков личных файлов в виндах. Они тоже очень рады, когда могут запуститься из под пользователя в его домашней папке.
Делают всякую херню лишь бы не осиливать Gentoo...
Ну вот, ещё один шаг к появлению тысяч троянов и вирусов под линукс. Осталось лишь антивирус запилить.
касперский же)) не?
Не.
Антивирус Попова
Бабушкина
> Ну вот, ещё один шаг к появлению тысяч троянов и вирусов под
> линукс. Осталось лишь антивирус запилить.так есть жи уже comodo, avira, avast, dr.web, nod32, f-port, avg, bitdefender, panda
>> Ну вот, ещё один шаг к появлению тысяч троянов и вирусов под
>> линукс. Осталось лишь антивирус запилить.
> так есть жи уже comodo, avira, avast, dr.web, nod32, f-port, avg, bitdefender,
> pandaОни не для линукса. Они для венды, просто у них есть линуксовая сборка сканера, который лишь один из компонентов. Нужно же полноценное решение, которое будет мониторить все файлы, отслеживать все сисколлы всех приложений, на каждый сисколл вызывать эвристический анализатор, который будет тщательно затормаживать работу приложения и между прочим делать вид, что он в состоянии эвристически отличить вредоносную деятельность от полезной.
>>> Ну вот, ещё один шаг к появлению тысяч троянов и вирусов под
>>> линукс. Осталось лишь антивирус запилить.
>> так есть жи уже comodo, avira, avast, dr.web, nod32, f-port, avg, bitdefender,
>> panda
> Они не для линукса. Они для венды, просто у них есть линуксовая
> сборка сканера, который лишь один из компонентов. Нужно же полноценное решение,
> которое будет мониторить все файлы, отслеживать все сисколлы всех приложений, на
> каждый сисколл вызывать эвристический анализатор, который будет тщательно затормаживать
> работу приложения и между прочим делать вид, что он в состоянии
> эвристически отличить вредоносную деятельность от полезной.Clamuko, не?
Даже под OSX не юзаю, MacPorts привычнее как то
Да и KDE4 в homebrew не было, не знаю как сейчас
если не сложно, расскажите, зачем лично вам нужен KDE под OS X.да, я в курсе, что в macports оно есть (наряду с awesome, Afterstep, FVWM 1, FVWM 2 и ещё десятком наименований), а в brew нет, но не совсем понятен юзкейс.
>не совсем понятен юзкейсАналогично. Только ssh, только хардкор.
> если не сложно, расскажите, зачем лично вам нужен KDE под OS X.оченно люблю kwrite/kate например
аналогичные редакторы под OSX либо говно либо платные
Любил kate пока не попробовал sublime - ну и что, что окошко вылетает - скорость увеличивается раз в тыщу. Есть ещё notepad++ и lime text - если уж быть тру фри
macports периодически ломается, засырает систему, и ему нужен рут для инсталла софта. brew === сухо, удобно, и практично :)
+1 Деинсталляция проще rm -rf /usr/local
А я не пойму за фигом это нужно. В любой репозиторий любого дистра можно запилить статически собранный пакет и качайте на здоровье. Но видимо до сих пор это считалось нецелесообразным. Хотя может быть кому пригодиться, да и пусть будет для разнообразия. Дураки как всегда пострадают в первую очередь, а я на них буду проверять как оно.
> А я не пойму за фигом это нужно. В любой репозиторий любого
> дистра можно запилить статически собранный пакет и качайте на здоровье. Но
> видимо до сих пор это считалось нецелесообразным. Хотя может быть кому
> пригодиться, да и пусть будет для разнообразия. Дураки как всегда пострадают
> в первую очередь, а я на них буду проверять как оно.Проблема статически собранного бинаря в основном заключена в том, что если ты пофиксил багу в библиотеке, то тебе необходимо также пересобирать и все бинари, которые с ней слинкованы. Когда-то это считалось целесообразным - так и делали до поры. Но потом бинари стали уж больно большими, и работы по пересборке всего и вся стало ну просто неописуемо много. Так и появился ELF.
А вот конкретно сия штука нужна для того, чтобы пользователь мог без прав рута кастомизировать свою систему, при этим не создавая угрозы для других пользователей. В принципе идея хорошая.
Хотя, конечно, для меня загадка, почему бы не допилить, скажем, dpkg для этих целей. В принципе делов-то: подменил корень на /home/username, флаг соответствующий для этого есть. Ну и плюс базу локально установленных пакетов где-то вести. В чём проблема - не понятно. Вот у меня сейчас машина, считай, на одного пользователя, так что я себе устроил как товарищ в сообщении 44, и это меня устраивает. Но может и правда есть какие-то скрытые камни при работе нескольких юзеров на одной машине?
Стойте, а чем это отличается от портажа и указания рута в ~/apps + добавления в PATH ~/apps/{usr/bin,bin} ?
тем что он не тянет с собой gentoo. при сборке не требует от других пакетов сборки с специальными опциями.
тогда не проще просто статиком собрать?
О господи ну нафига нужно было создавать это на руби, есть же куда более подходящие для этого языки, с++, golang? Чтобя начать пользоваться этой хренью нужно установить в систему руби, я не хочу засирать машину рубями :(
> О господи ну нафига нужно было создавать это на руби, есть же
> куда более подходящие для этого языки, с++, golang? Чтобя начать пользоваться
> этой хренью нужно установить в систему руби, я не хочу засирать
> машину рубями :(Оно изначально под мак а там руби по дефолту установлен.
Равно как и Python и Bash.
сравните манифест для brew:https://github.com/Homebrew/homebrew/blob/master/Library/For...
и для gentoo (python):
ftp://ftp.mgts.by/pub/gentoo-portage/app-admin/apg/apg-2.3.0...
если я вам после этого скажу, что brew ещё и быстрее работает, вы поверите?
вдогонку. на go/c++, конечно же, можно создать систему, которая берёт манифесты в YAML, но засада в том, что апи этих манифестов должен быть очень продуманным (на все случаи нестандартной сборки). как результат, никто этого пока не сделал.
> если я вам после этого скажу, что brew ещё и быстрее работает, вы поверите?Быстрее чем что? Чем emerge написанный на python'е? Ну так это временно, до тех пор пока этот brew не разрастётся по функциональности до уровня emerge. И до сложности ебилдов он тоже дотянется. Когда начнёт отслеживать многократные установки одного пакета с разными версиями, USE-флаги и условные депендансы, когда начнёт собирать в sandbox'е, дабы на глобальном уровне решить ряд проблем возникающих из-за кривых систем сборок пакетов, когда столкнётся с тем, что некоторые пакеты для сборки имеют довольно серьёзные требования к окружению (типа 6Гб виртуальной памяти или 4Гб свободного места на диске), и начнёт проверять систему на выполнение этих требований. ...
И вот когда и если brew научится всему этому, то он тоже превратиться в монстра, из-за которого сборка world на каком-нибудь первопне превращается в печаль-печаль, даже несмотря на то, что вся компиляция выполняется через distcc на достаточно мощной четырёхядерной машинке.
> Когда начнёт отслеживать многократные установки одного пакета с разными версиямиуже давно
> когда начнёт собирать в sandbox
аналогично
> когда столкнётся с тем, что некоторые пакеты для сборки имеют довольно серьёзные требования к окружению (типа 6Гб виртуальной памяти или 4Гб свободного места на диске), и начнёт проверять систему на выполнение этих требований.
ничто не мешает это делать, если надо, не вижу проблемы
> USE-флаги и условные депендансы
а что, portage уже научился вытаскивать pre-compiled binaries (при условии того, что нужный имеется и мы указали, что не хотим собирать этот пакет, если он уже собран в репе)?
в общем, спорная вещь -- функциональность brew и emerge, как-то сложно однозначно сказать, какой из них более функционален. впрочем, я рад, что мы сходимся, что emerge -- тормознутая система, а ебилды многословны.
> уже давно
> аналогичноРевёрс-депендансы, в т.ч и условные? @preserved-rebuild и preserved же бинари, оставшиеся от предыдущих версий пакетов, которые были обновлены? virtual пакеты? Версионирование "ебилдов" (не софта, а именно ебилдов, которые могут быть заточены под разные версии portage)?
> ничто не мешает это делать, если надо, не вижу проблемы
"Проблема" в том что это неплохо было бы производить до начала фазы мерджа после расчёта депендансов, чтобы если фейл, то он бы вылез до начала собственно установки/компиляции пары десятков пакетов, а не потом, при установке второго пакета из списка, когда пользователь уже давно ушёл пить кофе. Иначе ведь весь смысл теряется -- с тем же успехом о FAIL'е можно узнавать пост-фактум из build.log'а, когда установка пакета уже сфейлилась.
>> USE-флаги и условные депендансы
> а что, portage уже научился вытаскивать pre-compiled binaries (при условии того, что
> нужный имеется и мы указали, что не хотим собирать этот пакет,
> если он уже собран в репе)?А разве он не умеет? Я не вникал во все эти нюансы с бинарными пакетами -- мне не приходилось раскатывать генту на много однотипных машин. Точнее как-то давным-давно было дело, но я это решал при помощи rsync засунутого в /etc/init.d на каждой из машинок и, таким образом, упустил возможность ознакомиться с этой гентушной плюшкой. Поделитесь-ка опытом. Что там не так?
> в общем, спорная вещь -- функциональность brew и emerge, как-то сложно однозначно
> сказать, какой из них более функционален. впрочем, я рад, что мы
> сходимся, что emerge -- тормознутая система, а ебилды многословны.Нет, мы сходимся только в том, что емердж тормознут. А вот насчёт многословности ебилдов... точнее насчёт _неуместной_ многословности (вы ведь об этом?) -- это весьма спорный вопрос. Когда этот brew будет уметь всё, что умеет емердж, и иметь сходную базу разнообразнейших пакетов, чтобы гарантированно пройтись по всем граблям, тогда можно будет ответить на этот вопрос однозначно. То есть brew имеет в принципе иной use-case, и вряд ли столкнётся, например, с INPUT_DEVICES=, USE_PYTHON=, FEATURES=splitdebug, кросскомпиляцией (и дублированием /etc/portage/package.*, /etc/portage/profile да и вообще всей информации о системе для разных платформ), и тысячами одновременно установленных пакетов, перекомпиляцией куч *.py файлов (или *.el) в системе (без ненужной переустановки этих пакетов), при смене версии системного python'а (или соответственно emacs'а), и прочими радостями. Поэтому до сложности emerge ему нет смысла дотягиваться. Но у brew как я полагаю, ещё полезут свои специфичные проблемы, ему ещё предстоит нарастить себе мяса в плане поддержки разнообразных пакетных менагеров, дабы просчитывая депендансы и подбирая версию устанавливаемого пакета, выбрать максимальную из тех, что пойдёт в существующей системе.
> а что, portage уже научился вытаскивать pre-compiled binaries (при условии того, что
> нужный имеется и мы указали, что не хотим собирать этот пакет,
> если он уже собран в репе)?Я, хоть уже очень давно не гентушник, но замечу, что данная функциональность в нём была ещё лет эдак пять тому назад.
да, давайте сравним простой пакет для brew и сложный ebuild.
В ebuild можно просто приписать путь к архиву и остальное сделаем сам portage. И от отличии от brew сборка идет в песочнице, и никакие bumblebee не убьют систему, и перезатрут файлы других пакетов
> да, давайте сравним простой пакет для brew и сложный ebuild.это один и тот же пакет, если вы не заметили. да, унутре у ебилда больше велосипедостроения, но в результате это одно и то же приложение.
> И от отличии от brew сборка идет в песочнице
orly? build sandbox в brew есть.
Хорошее начинание
>Install Linuxbrew (tl;dr)
>Paste at a Terminal prompt:
>ruby -e "$(wget -O- https://raw.github.com/Homebrew/linuxbrew/go/install)"
>See Dependencies and Installation below for more details.запускать непойми что из инета(и потом давать ему рутовые права). Хипсторы добрались и до линукса
какие-то идиоты-маководы не смогли найти в поисковике генту и арч? ну, бывает.
Яблочники не знают, что в линуксе есть пакетные менеджеры?
допустим, я разработчик. я хочу себе на машину последние релизы go, ruby, python 2 + 3, node.js и docker. ах да, ещё emacs, git и ещё кой-чего по-мелочи.пользуясь "пакетными менеджерами linux" я либо обрекаю себя либо на тухлятину времён стабильного релиза дистрибутива, либо на бег по граблям в (т)роллинг-релизе. ну, либо смешивая кучу obs-репозитариев, что тоже сомнительное удовольствие.
а мне всего-то нужно поставить свежее development environment в стабильную систему. конкретный homebrew это легко и элегантно решает, в отличие от.
Небось еще сайты заливаешь по ftp?
Контейнерам openvz и прочим песочницам уже с десяток лет. Ставишь в них все, что тебе нужно для сборки и наслаждаешься жизнью, не трогая основную систему.Ну и отдельно восхитила уверенность в том, что глюки конкретной версии программы зависят от того, собрана ли она отдельным пакетом в стабильный релиз или являестя частью роллинг-релиза. Наверное это очень сильное колдунство, вроде переименования милиции в полицию. Стоит пакет поместить в stable релиз и баги в коде магически исправляются.
В репозиториях как раз легче поддерживать актуальность чем в интернет помойке.
> Наверное это очень сильное колдунство, вроде переименования милиции в полицию.
> Стоит пакет поместить в stable релиз и баги в коде магически исправляются.Angra ... ты не забывай кому ты это расскахываешь :)
В лучшем случае это излесимо:
>>>я хочу себе на машину последние релизы go, ruby, python 2 + 3, node.js и docker. ах да, ещё emacs, git и ещё кой-чего по-мелочи.А в худшем там вообще кисо с маком :)
> Небось еще сайты заливаешь по ftp?написал же: docker. кстати, под OS X и Win есть удобные способы его поставить и использовать, в отличие от:
> Контейнерам openvz и прочим песочницам
> Ну и отдельно восхитила уверенность в том, что глюки конкретной версии программы зависят от того, собрана ли она отдельным пакетом в стабильный релиз или являестя частью роллинг-релиза.да за десять лет на роллинг-релизах я что-то в них подразочаровался. ну, не хочу я столько времени уделять возне с операционной системе, как это там предполагается.
>> Небось еще сайты заливаешь по ftp?
> написал же: dockerда и git написал. vagrant и puppet-chef-ansible не написал, но они тоже нужны.
> Небось еще сайты заливаешь по ftp?Кстати, в этом нет ничего предосудительного. Почему бы и нет, если ты, скажем, у чёрта на рогах по модему сидишь?
> Ну и отдельно восхитила уверенность в том, что глюки конкретной версии программы
> зависят от того, собрана ли она отдельным пакетом в стабильный релиз
> или являестя частью роллинг-релиза. Наверное это очень сильное колдунство, вроде переименования
> милиции в полицию.Ну а что Вас тут так умиляет? Результат сборки действительно зависит от сборочного окружения, поэтому при создании пакетов и используются утилиты навроде pbuilder-а.
> Стоит пакет поместить в stable релиз и баги
> в коде магически исправляются.Не совсем так: просто поместить - ничего не изменится (зависимости поломаются, возможно). Надо *собрать* пакет в stable - и некоторое количество багов действительно пропадут.
Да никто не мешает собирать программы как в форточках одним пакетом, если кому понадобится то соберут. И кстати установить пакет в хомяк можно и без изобретения новых пакетных менеджеров. У меня один пакет так установлен.