= Сообщение: 1565 из 10763 ===================================== RU.UNIX.BSD =
От : Stanislav Soloviov 2:5020/2323 04 Jun 14 23:17:04
Кому : Alex Korchmar 04 Jun 14 23:17:04
Тема : Безобpазие в пакетах и зависимостях
FGHI : area://RU.UNIX.BSD?msgid=2:5020/2323+538f78fd
На : area://RU.UNIX.BSD?msgid=<1187488808@ddt.demos.su>+010db4a0
= Кодировка сообщения определена как: CP866 ==================================
Ответ: area://RU.UNIX.BSD?msgid=<1187488832@ddt.demos.su>+f2faffb0
==============================================================================
Привет, Alex!
04 июн 14 23:00, Alex Korchmar -> Stanislav Soloviov:
SS>> У фряхи всегда была проблема с пакетами, портами и
SS>> зависимостями. Помню, как
AK> она всегда есть у всех, у кого есть пакеты и зависимости.
Hа Debian только один раз сталкивался, с l2tp-демоном, да и то лет 5 назад. Такого, как бывает на фряхе, там нет.
AK> Hо, уже говорил, все кому эта убогость (а не зависимости) была реально
AK> невыносима - уже трахаются с dependency hell на true only system с
AK> pre-builded пакетами.
Hу да, и еще люди трахаются с Gentoo hell. Пусть будут пакеты, как у людей, с нормальными зависимостями.
AK> но весь пар ушел в свисток "сделать как в редхат". Кто им сказал что
AK> это нужно, или с чего они нафантазировали что "как в редхат" - образец
AK> для подражания - я не в силах понять.
Да когда с нуля надо быстро поднять рабочую систему, пусть будет уж лучше
как в редхэт, чем ждать 100 лет, пока что-то нужное соберется, чего нет в пакетах. Pkg обрадовал однако; это явно лучше чем старый пакетный менеджер с его "pkg_*".
SS>> Проблема с портами и зависимостями всегда была. Это, насколько
SS>> я помню и если не ошибаюсь, основная причина того, что богом
SS>> проклятая mail.ru group
SS>> перешла на GNU/Linux.
AK> сомневаюсь.
А я нет, читал такую новость года ~три назад, помню; можно отрыть в нете.
SS>> OpenBSD же никогда ни в чем меня не подводила.
AK> выключенная и отсоединенная от розетки?
Да, и в угол поставленная, блин. Писал же уже - работала на машине с битой памятью. Потом я офигел, когда увидел, что на той машине ни один установщик (Win 2008, Debian Linux, FreeBSD) не хотел запускаться,
а memtest86 показывал ужас что.
Включенная, под высочайшей нагрузкой разве что тормозила на самых-самых пиках, но не предала. Фряха иногда подводила из-за железа
и иногда отказывалась чекать рут после внезапного выключения питания.
Hо справедливости ради стоит отметить, что аптаймы тоже нехилые, а
экономия оперативки просто удивительная.
AK> рейды ничего не ремапят. Более умные рейды уводят диск в оффлайн, не
AK> всегда удачно. Умные пользователи рейдов знают про TLER и умеют
AK> выключать.
Это WD-шный TLER, что ли? А если мне на говне надо работать, а не на дисках raid edition? Фряха ведь и славна тем, что хорошо работает и на говне. А в другом случае я и дорогой RAID-контроллер с дорогими адскими рейдовскими SAS-ками поставлю и не нужно мне никакого софт-рейда.
SS>> ограничение (N) существует, но оно "намертво" вшито в ядро?
AK> такого ограничения не существует, этим занимается диск.
Вот именно, что в некоторых случаях есть возможность появления несамоисправимой ошибки. И если диск не хочет ремапить, то такие ошибки
не исправить через int 0x13, а ремап можно делать только чудо-командами
через порты ввода-вывода, что вполне можно было бы и запилить в ядро
как опцию.
Вопрос был в этом: почему софтрейд не выкинул диск с неисправимой ошибкой из рейда, и почему подсистема работы с дисками вечно пишет/читает
"неисправляемый" битый сектор, вешая систему, вместо того, чтобы после N
попыток вывалиться с ошибкой? Короче говоря, надо писать разработчикам,
где и как что тюнить в ядре, на это было бы интересно посмотреть.
Stanislav.
---
* Origin: п╔п╬я┌я▐ п(C)п╩п╟п╫п╦я─п╬п╡п╟п╩п╟. (2:5020/2323)
|
