Начиная с 8 июня, поддерживаемый сообществом пользователей дистрибутива Arch Linux репозиторий AUR (https://wiki.archlinux.org/index.php/Arch_User_Repository#AUR_4) (Arch User Repository) будет переведён (https://lists.archlinux.org/pipermail/aur-general/2015-June/...) на новую платформу, основанную на Git. Пакеты будет формироваться из Git-репозиториев, что подразумевает полное изменение процесса добавления пакетов.
Сопровождающим рекомендуется перенести свои пакеты в aur4.archlinux.org до 8 июня, так как в этот день будет отключено резервирование имён пакетов в новом репозитории и любой желающий сможет разместить пакет с именем, пересекающимся со старым репозиторием. 8 августа aur4.archlinux.org будет переименован в aur.archlinux.org и станет предложен по умолчанию.
URL: https://lists.archlinux.org/pipermail/aur-general/2015-June/...
Новость: https://www.opennet.ru/opennews/art.shtml?num=42341
надеюсь добавление через WEB оставят, иначе AUR капут будет, большинство не захочет с гитом пыкаться.
Если человек до сих пор не умеет git, то и пакеты делать ему доверять нелья. Так что наоборот, качество поднимется, неадекватов станет меньше.
это AUR, а не официальный репозитарий
если не будет заливки через WEB , то качество точно не поднимется, а вот количество редких пэкиджбилдов резко сократится, что в итоге в целом негативно повлияет на арчвопрос не в знании гита, а в увеличении сложности ... если же говорить о контингенте арча и мнении, что ламерам не место в нём, то тогда и аур не нужен, ведь только ламерам нужны удобства такие, а "нормальные поцоны" и сами соберут нужный пакет без всяких ауров.
> это AUR, а не официальный репозитарийКакая разница?
> если не будет заливки через WEB , то качество точно не поднимется,
> а вот количество редких пэкиджбилдов резко сократится, что в итоге в
> целом негативно повлияет на арчБрехня.
>> это AUR, а не официальный репозитарий
> Какая разница?Это должен был сказать я.
не ссорьтесь, всё едино.
"качество точно не поднимется, а вот количество редких пэкиджбилдов резко сократится"Правда 100%. Сам несколько пакетов в aur добавлял, т.к. это недолго. Если процедура с git геморройнее, то в следующий раз забью.
Вообще, сила ARCH в kiss. Шо-то они его начали нарушать в последнее время. Жалко альтернативы полноценной пока нет (безсистемГшной).
> Вообще, сила ARCH в kissarch давно уже не kiss, и начало положило этому интеграция systemd.
> Вообще, сила ARCH в kiss
>
> arch давно уже не kiss, и начало положило этому интеграция systemd.arch уже kiss my ass
Ну по сравнению с тем что было, например в Генте, вместо системы инициализации, systemd таки торт - всё что нужно запускает, юниты мелкие, а не стены текста на баше.
вы мне хотите доказать что systemd kiss, а bsd init не kiss ?
Уважаемый, эта тема не раз уже была затёрта до дыр.Грубо говоря, есть проблема несокращаемой сложности.
То есть для полноценной инициализации демона вам нужно проделать такие-то и такие-то приседания в такой-то и такой-то последовательности, а так же отловить и обработать все ошибки, которые могут в ходе этого процесса возникнуть.
Затем вам понадобится следить за этим демоном: уметь находить его запущенную копию и корректно убивать её.
(Современные реалии (дешёвая виртуализация в каждом колхозе) также таковы, что нужно полноценно следить за группами процессов: то есть если я запустил демон, и останавливаю его, в подавляющем большинстве случаев я имею в виду также останов всего, что он назапускал.)Дык вот, всё это -- сложные вещи. Если вы берёте очень простой init, то вся эта сложность оказывается на плечах клиентов этого init. То есть по умолчанию каждый (программист или сопровождающий пакета или админ) лепит сложный, а зачастую очень сложный, скрипт инициализации. Проблема эта хорошо известна много лет, из-за чего везде наизобретали велосипедов вокруг SYSV init: библиотеки shell-функций для скриптов, запускалки демонов типа дебиановской start-stop-daemon. Это закономерно приводит к тому, что 99% скриптов инициализации используют очень простой инит и все эти дистрибутиво-специфичные велосипеды.
Получается простой инит со сложными скриптами.Это ещё не всё. Если Вы пробовали писать демон для системы, основанной на Linux, то Вы неизбежно приходили к мыслям типа "а какого хрена нужно отдельно приседать для отладочной работы без отсоединения от управляющего терминала и для работы в режиме демона?", "на кой хрен нужен двойной форк и setsid() в правильной последовательности?", "почему нужно писат разный код для протоколирования на stderr и в сислог?", "что делать, если демон упал из-за внутренней ошибки?" и т.п. Ясно, что этими вопросами задавались многие умные люди, и потому появились runit, daemontools, хелпер daemon и прочие. А также отдельные узконаправленные решения для хостинга, например, HTTP-демонов, написанных на питоне.
А ещё попробуйте сами сделать активацию по сокетам? Говорите, "использовать inetd"? А как быть с зависимостями?
А легковесные контейнеры (да, XXI век уже здесь)? Напишем для них отдельный инит?
В итоге:
* Поскольку есть несокращаемая сложность, нужно где-то провести линию между инитом и его клиентами. В systemd эту линию провели ближе к иниту, чем в SYSV init.
* Systemd позволяет делать простые вещи просто, а сложные -- при необходимости -- всё же делать; не сложнее, чем раньше.
* Он позволяет делать демоны проще и логичнее. В частности, их можно легко писать на чём-нибудь, отличном от Си, без специальных приседаний.
* Он умеет всё или почти всё из того, что делают спец. приблуды вроде runit.
* Он умеет помогать легковесной виртуализации.TL;DR
Можно написать инит ещё проще, чем SYSV init (посмотрите, например, на ss6), но тогда скрипты инициализации и жизнь разработчиков станет ещё сложнее.
> Грубо говоря, есть проблема несокращаемой сложности.Про инструментальный подход слышали хотя бы что-нибудь? Или только продуктовый на слуху?
>> Грубо говоря, есть проблема несокращаемой сложности.
> Про инструментальный подход слышали хотя бы что-нибудь? Или только продуктовый на
> слуху?Нет, не слышал.
Но послушаю с большим интересом!Правда, сразу замечу, что я бы предпочёл прочесть о конкретном решение тех проблем, которые в данный момент решает systemd при помощи указанного подхода, а не, скажем, отсылку к абстрактной документации по "инструментальному подходу". Другими словами, "talk is cheap, show me the code".
Впрочем, меня вполне устроит просто изложение Ваших мыслей о применении этого подхода к данной ситуации. Но -- по возможности подробное.
> Про инструментальный подход слышали хотя бы что-нибудь? Или только продуктовый на слуху?Знаете, пример из жизни: вкатил я тут на ARMовскую платку кардинально более новое ядро.
...юзермод умер. Настолько, что ни сериально консоли не осталось, ни сети. И вообще ни-хре-на. Ядро живет где-то там внутри. Мигает LEDом по heartbeat-у. Но снаружи к системе доступиться - никак и ничем. Диагностики - ноль. Сообщений - ноль. Понять где вышла лажа - нереал.
Ну тут я взял на себя init=/bin/bash и пошло-поехало. Детальное изучение показало что околели некие башевые скрипты, в том числе правильно монтирующие нормально rootfs и прочая. Нет, никаких сбоев никуда не было залоггено. Ни в консоли, ни в логи, ни в dmesg-овый буфер. Глухо. Конечно, если ФС redonly - в нее сложно логгить. Но как мне тогда понять что отвалилось то? Системдец вон умеет немного логгить в ядерный буфер. Из скирптов же сие - гемор и грабли. Мне пришлось по ним попрыгать, чтобы понять что не так. Знаете, /dev/kmsg - не совсем обычный файл. И шелл с ним работает - "не очень", скажем так. А т.к. все остальное в readonly, на консоль рисуется только вывод кернела (остальное затыкается и не взлетает) и проч. Getty не стартуют (старт как бы прописан, но их нет). Круто, да? :)
Особенно издевательски выглядит вот что: ремаунтнув себе файлуху в RW я таки нормально запустил getty. Прописав его как юнит апстарта. Апстарт, в отличие от, может сносно работать даже в таких неудобных условиях. И даже пискнет немного в dmesg, если запуск обломался. Как впрочем и systemd.
И шли бы вы на...й с вашими теориями. Практика показала что реально трублешутить систему в состоянии тяжелого факапа (на самом деле кастомной рекомпоновки) из системд или апстарта - зело проще. Скриптошитец кладет на все ошибки, логгинга - ноль, так что оно просто тихо издыхает без каких либо сообщений куда либо. Вот сидишь ты так перед системой, locked out из нее напрочь. И не понимаешь - как оно умерло настолько, что даже getty на сериальном порту нету?! И если б не апстарт которым удалось быстренько запустить getty на сериальную консоль чтобы посмотреть на п..ц "в прогрессе" (init=/bin/bash в этом плане малоинформативен) - я бы долбался с этим не полдня а неделю и потребовался бы чуть ли не jtag.
неужто вы не шутите и говорите на полном серьезе? Давайте разовьем вашу мысль.
SYSV init -> Systemd, config file -> registry. А как пример постоянного расширения функционала можно посмотреть на X11. По факту я хочу забивать гвозди молотком, а смотреть на микробы через молоток, вы мне предлагаете супер удобный микроскоп-молоток, им и гвозди забить удобно, и на микробов посмотреть.
> неужто вы не шутите и говорите на полном серьезе? Давайте разовьем вашу
> мысль.
> SYSV init -> Systemd, config file -> registry.Вы только что применили https://ru.wikipedia.org/wiki/%D0%A7%D1%...
Никакой связи между переходами "SYSV init -> Systemd" и "config file -> registry" в реальном мире не существует. Это лично Ваша аналогия, и Вы имеете на неё право, но утверждать её истинность можно только доказательно, а Вы её привели будто это нечто само собой разумеющееся.
Что касается конкретно systemd, то типичный unit-файл для него на мой взгляд читабельнее типичного init-скрипта.
> А как пример постоянного расширения функционала можно посмотреть на X11.
Вы опять подменяете понятия: в принципе, можно было и не расширять функциональность X11, но тогда Вы не могли бы смотреть в нём видео с аппаратным ускорением, и сглаживание шрифтов у Вас бы тоже не работало. А также были бы проблемы с современными устройствами ввода. Другими словами, текущее состояние X11 определяется не её развитием, а проблемами, которые были в неё заложены при создании. Именно поэтому сейчас те же люди из X.org активно пилят Wayland. О причинах начала работ над Wayland написано много (самими разработчиками).
> По факту я хочу забивать
> гвозди молотком, а смотреть на микробы через молоток, вы мне предлагаете
> супер удобный микроскоп-молоток, им и гвозди забить удобно, и на микробов
> посмотреть.Метафора великолепна, но только всё это, к сожалению, обыкновенная софистика.
Выше по треду я уже приводил известную максиму "talk is cheap, show me the code":
диванных философов, пинающих systemd, существует огромное количество. При этом юмор ситуации в том, что решать *реальные* проблемы методом написания работающего кода, решающего *эти* проблемы, а не просто реимплементирующим SYSV init (привет ребятам из openrc!), никто не берётся, но притом все эти философы поголовно знают, что systemd делает это неправильно.Мне смешно это слушать. Причина в том, что я вполне себе практикующий программист
с достаточным опытом разработки, и я хорошо научился понимать, что неидеальное, но
уже работающее решение всегда лучше идеального, существующего на бумаге.
systemd реально существует, и развивается. У него есть людские ресурсы. Это значит, что те проблемы, которые он решает, *он уже решает.* По-моему, это хорошо.Кстати, я, например, ненавижу XML, и не люблю d-bus, и тем не менее в Linux невозможно сделать, скажем, нормальный multi-seat без всех этих фиговин. То есть можно, но чисто теоретически, и никто другими -- "правильными" -- способами это не сделал.
(Та же примерно, кстати, ситуация и с Wayland. Пинать X11 очень любят. Пинать Wayland любят ещё больше. Только вот пишущих аналог Wayland, решающий проблемы X11, не видно.)
Ну и, наконец, можно же перейти от диванной философии к активным действиям: если нет возможности написать ту самую "правильную" (с отдельными микроскопом и молотком) систему, то можно, наконец, помочь ребятам из Devuan ;-)
Разговор начинался про kiss, но мы куда то в другую сторону уехали
> Жалко альтернативы полноценной пока нет (безсистемГшной)CRUX же
>>Жалко альтернативы полноценной пока нет (безсистемГшной).Gentoo\Funtoo? На худой конец Slackware - без systemd но с древними пакетами.
_Ящитаю_, загрузка пакетов через гит и хранение их в нём — куда более KISS, чем через веб.
дело не в или или, а в и и
Нормальные пацаны как раз собирают для себя и делятся с другими.
> надеюсь добавление через WEB оставят, иначе AUR капут будет, большинство не захочет
> с гитом пыкаться.Я вот не разбираюсь, а пользователи смогут оставлять свои комменарии, как сейчас ?
Да ладно, будешь херачить комменты здесь и на лорчике. Какая тебе разница?
да ладно, неужели для человека, осилившего сборку пакета, гит будет препятствием?
> да ладно, неужели для человека, осилившего сборку пакета, гит будет препятствием?Это я, к примеру. hg использую без проблем, а с Git не срослось - инопланетянский dvcs же.
не смог или не понравилось/не захотел?
> Это я, к примеру. hg использую без проблем, а с Git не срослось - инопланетянский dvcs же.Да скажи ты как есть: "Я не смог разобрался, поленился, ниасилил". А я вот осилил.
Юзал оба. Научиться одному, если знаешь другой, не сложно.
Считаю, что "добавление через WEB" надо убрать. Пусть люди привыкают к гиту со школьной скамьи!
> Считаю, что "добавление через WEB" надо убрать. Пусть люди привыкают к гиту
> со школьной скамьи!К линуксу и git невозможно привыкнуть в принципе. Это Боль и Страдание постоянные.
> К линуксу и git невозможно привыкнуть в принципе.
> Это Боль и Страдание постоянные.Так зачем же ими натираться-то?
> К линуксу и git невозможно привыкнуть в принципе. Это Боль и Страдание постоянные.Да, они ужасны. Есть только одна проблема: все остальное - ЕЩЕ ХУЖЕ!
> К линуксу и git невозможно привыкнуть в принципе. Это Боль и Страдание постоянные.Бедный, тяжело наверное тебе рядом со мной находиться, ибо я осилил как git (использование и развертывание сервисов), так и linux-ядро. Да-да, у меня есть собственные патчи на linux-ядро и сделал я их лишь разобравшись в сопряженном коде ядра.
arch как всегда, херак, и тушите помидоры.
тут как с прокладкой в авто
Дык никто не неволит, бубунта ждет!
арч не для пользователей, пользователи для арча.
Арч в своем репетруаре, только сервак собрался ставить на арче, теперь будем посмотреть
арч то причём?
> арч то причём?При том, что его кошмарит периодически, за ним надо следить, а на сервачке неохота.
Что не исключает возможности челу выше успешно юзать его на серверах и для фирмы, а не только на своих.
>> арч то причём?
>
> При том, что его кошмарит периодически, за ним надо следитьЛучше я буду следить за своей ОС, чем ОС за мной
Дык ставьте Debian и не парьте мозги всем.
Как бы, совсем не идеал. Хотя, идеала и нет. Но арч для своих пк - лучший дистр, что я видел.
> Как бы, совсем не идеал. Хотя, идеала и нет.Угу.
> Но арч для своих пк - лучший дистр, что я видел.
"Огласите весь список!" (ц) :)
Поставить и не следить - это про RHEL / CentOS, а Debian через год обновлять, да и вообще.
> через год обновлять, да и вообще.Ваши данные немного протухли - у дебиана нынче сроки поддержки зело поболее.
>сервак собрался ставить на арчеКрасавчик чо
> Арч в своем репетруаре, только сервак собрался ставить на арче, теперь будем
> посмотретьЕсли поставишь, то тебя ТОЧНО не уволят :)
Ну или уволят, примут нового, тот потрахается, и примут обратно тебя за двойную зарплату.
Такое ощущение, что вы сами не пробовали Арч в работе. Он наоборот, простой, как две копейки, и поддерживать его проще некуда. Для сервера он не годится не из-за сложности, а из-за особенностей реализации rolling release-модели.По поводу "обфускации" системы я видел реальный пример из жизни - один мой бывший коллега брал FreeBSD, собирал софт не из портов (качал с официальных источников) и поселял этот софт в случайных местах в системе. Выглядело это... довольно любопытно.
> По поводу "обфускации" системы я видел реальный пример из жизни - один
> мой бывший коллега брал FreeBSD, собирал софт не из портов (качал
> с официальных источников) и поселял этот софт в случайных местах в
> системе. Выглядело это... довольно любопытно.Фрю специально упомянул, мол она виновата? В любом дистрибутиве посеять софт в случайных местах - будет то же самое. И, кстати, "официальным источником" может быть только репозиторий вашего дистрибутива, но никак не апстрим который как пакетировать софт не имеет ни малейшего понятия.
> Фрю специально упомянул, мол она виновата? В любом дистрибутиве посеять софт в
> случайных местах - будет то же самое.Факт.
> И, кстати, "официальным источником" может быть только репозиторий вашего дистрибутива,
> но никак не апстрим который как пакетировать софт не имеет ни малейшего понятия.Не факт -- словосочетание применительно к софту-в-дистрибутиве можно трактовать, как Вы пишете, а к софту-вообще -- как #39. Поэтому лучше выражаться однозначно сразу.
Ну и "знавал я такие апстримы" (ц), которые не только отлично пакетят, а ещё и участвуют в дистрибутивах :)
> Фрю специально упомянул, мол она виновата?Нет, просто специалистов по BSD меньше.
> И, кстати, "официальным источником" может быть только репозиторий вашего дистрибутива, > но никак не апстрим который как пакетировать софт не имеет ни малейшего понятия.
А вот это одна из причин, поэтому Арч - отличный дистрибутив. Тамошние мейнтейнеры не считают себя умнее апстрима, и после чтения документации к тому или иному сервису не нужно лезть в вики дистрибутива, чтобы ознакомиться со своим, оригинальным взглядом мейнтейнеров на то, сколько вложенных includ'ов будет в конфигах сервиса, и по каким новым, неизведанным директориям системы они решили распихать эти ссылающиеся друг на друга конфиги.
> Такое ощущение, что вы сами не пробовали Арч в работе. Он наоборот, простой, как две копейки, и поддерживать его проще некуда. Для сервера он не годится не из-за сложности, а из-за особенностей реализации rolling release-модели.Арч примитивен и в нем хорошо обучаться и решать примитивные задачи. Подойдет студентам начальных курсов и старшеклассникам для знакомства с linux, но не более. Решать более сложные задачи комплексного характера и выдерживать определенный уровень обновления - эти и подобные задачи превращают обслуживание системы в унылую рутину и тем самым просто отнимают ваше время. Арч - это как игрушечный молоток. И если наступит время когда вам нужно будет забить гвоздь - вам придется отложить игрушки и взять в руки настоящий молоток. По началу Debian будет казаться тяжелым и непривычным, но чем больше вы работаете с молотком - тем реже вы ударяете по своим пальцам. Я знаю о чем говорю, уж поверьте мне.
Хорошая попытка. Нет, правда хорошая.Но, во-первых, я сам написал, что Арч не подходит для серверов из-за особенностей реализации rolling release-модели. Арч идеален в качестве рабочей станции, поскольку позволяет работать с самыми свежими версиями ПО, при этом не заставляя пользователя работать в постоянно сбоящей testing/unstable системе (покашливаю, глядя в сторону Debian/Fedora).
А во-вторых, вы же никакого понятия не имеете тех о рабочих задачах, которые я решаю, и при этом высокомерно рассуждаете о примитивизме дистрибутивов.
Скажу так - на серверах у нас либо Gentoo, либо FreeBSD. Debian недостаточно гибок и не обладает теми функциями, которые нами востребованы, или плохо их реализует.
> Арч идеален в качестве рабочей станции, поскольку позволяет работать с самыми свежими
> версиями ПО, при этом не заставляя пользователя работать в постоянно сбоящей
> testing/unstable системе (покашливаю, глядя в сторону Debian/Fedora).Идеального под Луною и впрямь не бывает, разве что кажется. Задолго до арча уже был сизиф, где, помимо свежих версий, ещё и взрослые люди не перевелись -- так что обходится без прыжков в ширину вроде "проснулись все на systemd".
>> Арч идеален в качестве рабочей станции, поскольку позволяет работать с самыми свежими
>> версиями ПО, при этом не заставляя пользователя работать в постоянно сбоящей
>> testing/unstable системе (покашливаю, глядя в сторону Debian/Fedora).
> Идеального под Луною и впрямь не бывает, разве что кажется. Задолго
> до арча уже был сизиф, где, помимо свежих версий, ещё и
> взрослые люди не перевелись -- так что обходится без прыжков в
> ширину вроде "проснулись все на systemd".Но системд имеет свои плюсы. Я с комфортом пользуюсь как OpenRC, так и systemd, и то, и другое довольно удобно.
>> ширину вроде "проснулись все на systemd".
> Но системд имеет свои плюсы. Я с комфортом пользуюсь как OpenRC, так
> и systemd, и то, и другое довольно удобно."Я каждое утро просыпаюсь -- или с OpenRC, или с system. И то, и другое довольно удобно."
--Free is love, my contribution --Hail the sexual revolution
Все дистрибутивы, которые я использую в работе, должны использовать одну систему инициализации?
сизиф это что? Кроме разработчиков альта кто нибудь в курсе еще?
> Хорошая попытка. Нет, правда хорошая.Это не попытка, а что-то вроде итога работы с Арчем. Пользовался примерно год, надоел его примивизм.
> Но, во-первых, я сам написал, что Арч не подходит для серверов из-за особенностей реализации rolling release-модели. Арч идеален в качестве рабочей станции, поскольку позволяет работать с самыми свежими версиями ПО, при этом не заставляя пользователя работать в постоянно сбоящей testing/unstable системе (покашливаю, глядя в сторону Debian/Fedora).
Арч не только не подходит для серверов, он вообще не подходит. Свержие версии ПО очень легко собираются на том же Debian на базе существующей версии, если разобраться, было бы желание. Мне в Арче кроме примитивизма еще и надоели проблемы которые появляются из-за "самых свежих версии ПО". Мало приятно сидеть и разбирать косяки новых версии вместо того чтобы сделать то что собирался. Если вы не понимаете о чем я говорю - вы видимо теоретик/фанатик, либо очень мало пользовались Арчем.
> А во-вторых, вы же никакого понятия не имеете тех о рабочих задачах, которые я решаю, и при этом высокомерно рассуждаете о примитивизме дистрибутивов.
Да меня и не интересуете ни вы, ни ваши задачи. Я пишу как есть на базе своего личного опыта использования Арча: Арч примитивен и не позволяет решать мои задачи (они комплексные, сложные). В Debian же уже были нужные мне утилиты и продуманный интерфейс взаимодействия с пользователем. Арч я заменил за недоразвитостью на Debian и все проблемы как рукой сняло.
> Скажу так - на серверах у нас либо Gentoo, либо FreeBSD. Debian недостаточно гибок и не обладает теми функциями, которые нами востребованы, или плохо их реализует.
Интересно бы узнать о тех функциях которые не реализованы или плохо реализованы в Deian. Не расскажете нам?
> Да меня и не интересуете ни вы, ни ваши задачи. Я пишу как есть на базе своего личного опыта использования Арча: Арч примитивен и не позволяет решать мои задачи (они комплексные, сложные). В Debian же уже были нужные мне утилиты и продуманный интерфейс взаимодействия с пользователем. Арч я заменил за недоразвитостью на Debian и все проблемы как рукой сняло.Так вам просто хочется высказать своё мнение, невзирая на потребности других людей?
> Интересно бы узнать о тех функциях которые не реализованы или плохо реализованы в Deian. Не расскажете нам?
Нет, потому что несколькими строчками выше вы прямо написали, что вас не интересуют мои задачи. Это значит, что теперь вы задаёте вопрос не для того, чтобы аргументированно пообщаться, а для того, чтобы утвердиться в правильности своего мнения любой ценой, и неважно, какие аргмуенты я приведу.
А просветите, в чём вообще будет разница для мантейнеров и пользователей? Это же просто смена VCS (что, кстати, было до git)?
ничего, никакой истории, только одна копия, скорее всего на диске просто лежало
Кошмар какой. Тогда тут совершенно не о чем переживать.
да оно и не нужно было особо
В AUR то ли осталась, то ли всегда и была одна школота, которая даже pkgbuild не в состоянии написать грамотно. В итоге оттуда через раз нихрена не собирается. Я в своё время перестал пользоваться командой yourt вообще. А потом и самим Арчем перестал пользоваться. Как раз в неделю выкатят новое ядро, да новый systemd - лупишся в логи и седина в волосах появляется.
4й год на арче и такого не наблюдал.
Был один момент при смене самбы с 3й на 4ю, да и тот легко решился.
> 4й год на арче и такого не наблюдал.
> Был один момент при смене самбы с 3й на 4ю, да и
> тот легко решился.Админ локалхоста ?
Кто ставит арч в продакшн, сам себе мурзилка.
> Админ локалхоста ?Arch только для локалхоста и пригоден
>> Админ локалхоста ?
> Arch только для локалхоста и пригоденИ в этой роли Арч бесподобен.
К тому же локалхостов у одного человека может быть несколько (У меня например дома, на работе. На raspberry-подобное поставлю только его).
У меня Arch тоже на рабочем и домашнем компах стоит. Но на сервак нормальный человек его не поставит, если он работой дорожит.
а ты думал, арч для того и создан, чтоб пакеты поновее и софт на свой вкус можно было подобрать
а вот представить зачем роллинг-дистрибутив на продакшене нужен, у меня фантазии не хватает
> а вот представить зачем роллинг-дистрибутив на продакшене нужен, у меня фантазии не
> хватаетСо своими штампами уже задрали. Если кто-то юзает - значит надо (свежий софт или чего-то еще) И эти ваши шаблонные "продакшены" - растяжимое понятие.
> Если кто-то юзает - значит надо…а то начальство дрючит: «чего не работаешь?!» а так и в мыле постоянно, и время от времени героически спасаешь контору от огромных неприятностей. скромно умалчивая, что являешься их источником.
Адекват, смени ник.
>Я в своё время перестал пользоваться командой yourt вообщеЛолка. AUR тем и был хорош, что ~90% pkgbuildов собиралось, остальные исправлялись тривиальными правками.
А любители собирать пакеты, не читая pkgbuildы, должны страдать в любом случаи, вам хоть патч Бармина, хоть трояны подсовывай, всё божья роса, организмы однокнопочные.
Вот сиди и правь за другими дураками пакбилды по жизни, вместо того, чтобы продуктивно работать. Это карма твоя.
если кто то не умеет гит то научиться будет оч полезно. И основная идея аура в скорости добавления пакета: залил и он сразу есть,- а не как в оф репах залил и ждешь проверки.
Качество все таки поднимется: тот кто умеет гит всяко норм пакеты создает для аура а вот наоборот - не факт
всегда сразу появлялся при добавлении в aur, непойму о какой задержке говоришь
> Сопровождающим рекомендуется перенести свои пакеты в aur4.archlinux.org до 8 июня, так как в этот день будет отключено резервирование имён пакетовИюля, а не июня. Миграция будет проходить с 8 июня по 8 июля.
>Starting from June 8th, 2015, the Arch User Repository is being migrated to a Git-based platform
>please submit them to aur4.archlinux.org before July 8th
>However, if you choose not to resubmit your package, we will cancel that reservation on July 8thА до 8-го июня посылать туда пакеты вообще бессмысленно: https://lists.archlinux.org/pipermail/aur-general/2015-June/...
Похерят 70% пакетов при "переезде", а профита никакого. Приветствую.
я использовал зеркало git для AUR несколько лет назад... ну, это было медленно и печально :)
> основанную на Git.А что эти извращенцы раньше то использовали?
Ну наверное какую-нибудь программку для репозиториев.
Теперь будут для репозитория использовать гит.
>> основанную на Git.
> А что эти извращенцы раньше то использовали?Файлы вроде =) Гит внутри пакетов юзали, кто хотел.
> Сопровождающим рекомендуется перенести свои пакеты в aur4.archlinux.org до 8 июня> Don't Panic! This site is down due to maintenance.
Замечательно. А оно вообще успеет подняться до этой даты?
Это опечатка в новости, см. https://www.opennet.ru/openforum/vsluhforumID3/102841.html#29