Го в пакман, я создаю.

Если бы этот pacman 4.0 ещё поставился.

Он не дружит с package-query в AURе и c packagekit из extra (кто-то его не обновил вместе с пакманом).

Ничего, пройдёт.

Если бы этот pacman 4.0 ещё поставился.

pacman -Sd pacman, если совсем охота. Но смысла пока нет, базы с подписями еще не готовы.

Арч как продукция apple. «Что, у них и этого не было?»

>Теперь у нас на один комплекс меньше!

∞-1=∞

Ну и хорошо

>Теперь у нас на один комплекс меньше!

Не ври, у нас нет комплексов.

Это теперь, как в дебиане, нельзя будет основную массу пакетов установить?

у вас есть комплексы? вы хотите поговорить об этом?

Зачем пользоваться тем что порождает комплексы? Для того чтоб арч можно было ставить на сервер он еще должен:

1) Отказаться от роллинг-релизов

2) получать обновления безопастности

3) Срок поддержки одного релиза должен быть несколько лет

и нафиг это если и так полно серверных дистрибутивов?

Это теперь, как в дебиане, нельзя будет основную массу пакетов установить?

Гм, в бытность сидения на сарже с таким не сталкивался. Ты о чем?

Why so serious? :)

Это я о том, как пытался себе дома дебиан поставить, а установщик матюгнулся, что неподписанные пакеты с сервера установить не может и сдох =)

[Исправлено] Арч готов для домашнего сервера.

А раньше не был ?

Собери yaourt и package-query из git, они работают с pacman 4.0.
Обновление разрабы не выпускают до спуска нового pacman из тестинга, уж не знаю, по какой причине.

Чувствую, что наоборот надо говорить: раньше был готов, а теперь жди вооот такого геморроя!

Арч готов для сервера.

*Безудержный смех в зале*

Заголовок жёлтый. Вот когда брендовые сервера будут официально поддерживать арч, тогда и создавай новость :)

Желание взгромоздить арч на сервер - вот тот комплекс, от которого следовало бы избавляться.

Отсутствие подписи у пакета не мешает его установке.

Пусть сначала packagekit обновят.

Роллинг релиз на сервере? Арчеводы такие смешные

> Не ври, у нас нет комплексов.

Поддерживаю.

> Пусть сначала packagekit обновят.

Сегодня займусь, если не забуду.

> Роллинг релиз на сервере? Арчеводы такие смешные

Объясните мне, что плохого в RR? Нет, серьёзно?

+1

я хоть и арчевод но...ух...
В RR на тестирование отводится ВОЧЕНЬМНОГОРАЗ меньше времени, а т.к. программисты не умеют писать без ошибок, то можно сделать вывод что они как минимум не очень стабильны. А если все пакеты еще обновляются по несколько раз в месяц, то можно прикинуть какое количество новых ошибок там появляется...

Так вот, друг мой, подумай, зачем ставить на сервер макаку с гранатой?

1) Весь новый софт не может быть оттестированным
2) При обновлении ABI библиотек софт, от неё зависимый отваливается

За простой сервера из-за этих фишек RR по голове не погладят. В генте хотя бы есть стабильая ветка для пункта 1) и revdep-rebuild для пункта 2), а в арче как с этим?

> 1) Весь новый софт не может быть оттестированным

Тестирование критичного серверного софта - задача апстрима. И проблема недостатка ресурсов на тестирование в составе дистрибутива - не проблема RR.

2) При обновлении ABI библиотек софт, от неё зависимый отваливается

Да, это проблема, хоть и нетипичная для серверного софта. Но для таких случаев есть NoUpgrade.

За простой сервера из-за этих фишек RR по голове не погладят.

По голове не погладят админа, который допустил такой простой. Я много раз видел, как и на RHEL-серверах софт ставится и обновляется админами через make install, и простой в связи с этим тоже был. У RR даже преимущество, что необходимость make install отпадает.

>В RR на тестирование отводится ВОЧЕНЬМНОГОРАЗ меньше времени

Мейнтейнеры генты смотрят на тебя с непониманием.

> В RR на тестирование отводится ВОЧЕНЬМНОГОРАЗ меньше времени, а т.к. программисты не умеют писать без ошибок, то можно сделать вывод что они как минимум не очень стабильны.

Друг мой, покажи мне нестабильность того же Apache или OpenSSL в Arch.

>админами через make install
Это админы локалхоста, их нельзя к продакшену подпускать, так же как и админов, пихающих RR на сервер

1) Серверные программы вроде Apache и MySQL в том же арче являются достаточно стабильными, если использовать ветку stable. Нестабильны в основном различные динамично развивающиеся десктопные приложения и DE, но на сервере их и не должно быть.

2) При обновлении ABI библиотек программисты, пишущие софт от них зависимый обновляют его. Если какое-то приложение не заброшено разработчиками, то апдейт до новой версии ABI выйдёт вместе с появлением новой библиотеки в ветке stable. А если софт заброшен, то спасёт NoUpgrade, но пользоваться необновляемым софтом ССЗБ.

К тому же обновления между релизами одного дистрибутива как правило оказываются более болезненными, чем повседневные обновления арча, потому что в такой ситуации обновляется единовременно большое количество софта.

С последним обзацем не соглашусь: там обновляется весь софт, и не бывает, чтобы часть осталась завязана на старых библиотеках и отваливается

что полезного дадут эти подписи? Растолкуйте

Защита от подмены пакетов на сторонних зеркалах, защита от подмены пакета при скачивании (например если на одном из роутеров от вас до зеркала стоит прозрачный прокси, который модифицирует ответы сервера на некоторые запросы).

Довольно странно.
Будь я админом (наеюсь не стану :) ) я бы не стал полагатся на авось и надеятся что обновление какой-то библиотеки не уронит сервер.
И еще вопрос что использовать новую версию приложения (наверное ради новой фичи), либо сидеть на оттестированной стабильной версии.

И еще, Арч пока никто не ставит на сервера, поэтому коммьюнити там по этой теме я сомневаюсь что такое же сильное, как у дебиана. А представители последних врядли будут резво перелазить с комфортного места на треугольник с возбужденным соском...

> Это админы локалхоста

I don't care, факт есть факт.

К RR на сервере у вас просто предвзятое отношение - собственно, что-то дальше обсуждать бесполезно.

Спасибо, приятно встретить вменяемого человека в треде. :)

> Будь я админом (наеюсь не стану :) ) я бы не стал полагатся на авось и надеятся что обновление какой-то библиотеки не уронит сервер.

Если ручки растут из попки, то и без обновления библиотек можно положить любой дистрибутив. Грамотный админ должен знать, что он делает, а не «надеяться».

И еще вопрос что использовать новую версию приложения (наверное ради новой фичи), либо сидеть на оттестированной стабильной версии.

Если вы крутите сервер с Rails или J2EE, а программисты пишут под новую версию Ruby или JDK, то вы сразу поймёте, ради чего их нужно ставить.

И еще, Арч пока никто не ставит на сервера, поэтому коммьюнити там по этой теме я сомневаюсь что такое же сильное, как у дебиана.

На всякий случай - https://wiki.archlinux.org/index.php/Comprehensive_Server_Guide#Arch_Linux_as...

> часть осталась завязана на старых библиотеках и отваливается

Конкретный пример назовёте? Такое могло быть во времена Arch 0.8, но сейчас это звучит смешно.

>Конкретный пример назовёте?
Арчем не пользуюсь, поэтому врать не буду

>К RR на сервере у вас просто предвзятое отношение
Где хоть одна серьёзную контора, которая ставит arch на свои сервера, или хоть один крупный хостер, живущий на RR-ветке?
Наверное там сидят умные люди, знают что выбирать

Да он и был готов. Просто дистрибутив всё-же не для широкой аудитории, поэтому ждать вал инсталляций на сервера не стоило раньше, не стоит и теперь.

>Нестабильны в основном различные динамично развивающиеся десктопные приложения и DE
«Стабильностъ» означает нестолько невозможность софта упастъ в корку,
сколько его заморозку.
А это означает, как минимум, что при обновлении libpng(или что там у вас было)
не отвалится gd, внезапно не изменится формат конфига $dаemonname, обновление пыха
не сломает очередную поделку.
Да и, например, ffmpeg или mencoder совсем не серверный софт,
но вот угадай, чем на серваках порнуху кодируют.
И, о ужас, иногда на серваки ставят опенофис.
А eще есть закрытый софт и ин-хаус решения, которые вобще лучше не трогать.
Также, при обновлении libfoo, очень желательно перезапускать то, что от нее зависит.
А еще есть такие места, где даже обновления безопасности, ставятся только после долгого
тестирования и подписи свыше.

К тому же обновления между релизами одного дистрибутива как правило оказываются более болезненными, чем повседневные обновления арча

Нет, при смене релиза раз в N лет, поднимается тестовая площадка и дрочится неопределенное время.
И только когда все довольны, плавно мигрируется.
А обновляя арчик каждую неделю, ты можешь только скрестить пальцы.

Практика говорит о том, что позитивный эффект от «заморозки» несколько преувеличен. Реальных прецедентов того, чтобы RR приводил к массивной неработоспособности софта пока не было, в то время как у «заморозки» есть негативный эффект - на «стабильные» версии софта всё равно накладываются устраняющие ошибки (в первую очередь security направления) - а это, зачастую, backports с новых версий этого софта, и не факт, что результат в итоге будет лучше, чем просто переход на новую версию. Я навскидку не назову прецедентов, когда исправления версий было проблемнее, чем переход на новую версию, но теоретически это возможно, потому imho нельзя однозначно утверждать, что RR всегда хуже «заморозок».

Это он, это он, ленинградский почтальон:

error: key "Evangelos Foutras <foutrelis@gmail.com>" could not be imported
error: erlang: signature from "Ionut Biru <ibiru@archlinux.org>" is unknown trust
error: glib2: signature from "Ionut Biru <ibiru@archlinux.org>" is unknown trust
error: nettle: signature from "Andreas Radke <andyrtr@archlinux.org>" is unknown trust
error: gnutls: signature from "Andreas Radke <andyrtr@archlinux.org>" is unknown trust
error: gtk3: signature from "Ionut Biru <ibiru@archlinux.org>" is unknown trust
error: hyphen: signature from "Andreas Radke <andyrtr@archlinux.org>" is unknown trust
error: man-pages: signature from "Andreas Radke <andyrtr@archlinux.org>" is unknown trust
error: midori: signature from "Andreas Radke <andyrtr@archlinux.org>" is unknown trust
error: mplayer: signature from "Ionut Biru <ibiru@archlinux.org>" is unknown trust
error: failed to commit transaction (invalid or corrupted package)
Errors occurred, no packages were upgraded.