Анонсирован (https://www.scientificlinux.org/news/sl61) релиз дистрибутива Scientific Linux 6.1, построенного на пакетной базе Red Hat Enterprise Linux 6.1 (http://www.opennet.me/opennews/art.shtml?num=30607) и дополненного средствами, ориентированными на использование в научных учреждениях. Дистрибутив поставляется для архитектур i386 (http://ftp.scientificlinux.org/linux/scientific/6.1/i386/iso/) и x86_64 (http://ftp.scientificlinux.org/linux/scientific/6.1/x86_64/iso/), для загрузки доступно несколько сборок: установочный DVD (3.5 Гб), полный комплект из двух DVD (4.2 Гб + 400 Мб), LiveCD (GNOME, 699 Мб), LiveMiniCD (IceWM, 389 Мб), LiveDVD (GNOME/KDE/IceWM, 2.2 Гб) и сокращенный образ для установки по сети (163 Мб).
Кроме изменений добавленных в RHEL 6.1 (http://www.opennet.me/opennews/art.shtml?num=30607), из специфичных отличий (http://www.scientificlinux.org/distributions/6x/61/differences) новой версии от Scientific Linux 6.0 можно отметить реализацию полностью переработанн...URL: https://www.scientificlinux.org/news/sl61
Новость: http://www.opennet.me/opennews/art.shtml?num=31335
Без лишней пыли, в отличие от уже мёртвого CentOS.
CentOS сначала выпускает 4.x и 5.x, потом уже 6.x, а SL наоборот. CentOS 5.6 вышел раньше, чем SL 5.6.
Потому что у SL rolling release, у него сразу после выхода RHEL5.6 критические фиксы и обновления из 5.6 были доступны для SL5. Да, они не сделали инсталляшку "SL 5.6", но везде на серверах нужные обновления ставились.
А потом, когда работа над 6.0 была завершена, они доделали инсталляшку/live cd/etc для 5.6.В то же время, когда все пользователи SL5 имели фиксы, выпускаемые редхатом для 5.6, центос со своей концепцией "обновления для 5.6 не выпустить, пока не выйдет сам centos 5.6" сел в лужу, и пользователи центос 5 три месяца сидели без обновлений вообще, пока не вышел centos 5.6, а потом обновления для него.
Так что, вам шашечки (версия "5.6" на сайте для скачивания с огромной задержкой, как центос) или ехать (постоянные и актуальные обновления, как в SL, независимо от статуса выпуска)?
так трудно понять чтоли что задача центос максимально идентичная пересборка а сайнтифики просто собирают устраивающим их тулчейном?
> так трудно понять чтоли что задача центос максимально идентичная пересборка а сайнтифики
> просто собирают устраивающим их тулчейном?Ну и на что это влияет? Бинарная совместимость есть же, утилиты от серверов для редхата ставятся? больше ничего не надо
Нет, понять не трудно. Но три месяца без обновлений для пользователей Centos 5 - это реальность. Выпуск 6.0 на 8 месяцев позже редхата и устаревшим и без обновлений на момент выхода - т.к. обновления редхат выпускает уже для 6.1, а аналогичного центоса нет - это тоже реальность.Мне кажется, что >90% серверов, где используется центос, проблема сидеть 3 месяца без обновлений безопасности куда более критичная, чем "максимальная идентичность с редхатом"; тем более что практических случаев, когда центос будет более совместим с редхатом, чем SL не известно. Мне, во всяком случае. Вам такие случаи известны, чтобы не такая "максимальная идентичность с редхатом" SL'а приводила к каким-либо проблемам, которых не было в Centos?
>Вам такие случаи известны, чтобы не такая "максимальная идентичность с редхатом" SL'а
>приводила к каким-либо проблемам, которых не было в Centos?да известны. не лазил особо глубоко, потому что SL был "на попробовать", но что то они делают такое с ядром, что все багфискы с time drift под kvm пропадают, и гостевая машина с SL скачет как ненормальная, там где RHEL (а значит и центос) не теряют ни единого тика.
других примеров пока не видел, но уверен что раз они ковыряют ядро, найдутся и другие дыры.
Так отрепортите баг!У меня SL 6.0 и 6.1 под kvm не дрифтят, кстати.
> Так отрепортите баг!сообщил мейнтейнерам! открыли баг или нет - не знаю!
> У меня SL 6.0 и 6.1 под kvm не дрифтят, кстати.
какой kvm, какие версии, какие процессоры и модули, что на хосте... мне все факторы перечислить?
Stax, ценная инфа. Возьму на заметку.
Кстати, я установил SL 6.1 немним ранее и сразу наступил на сегфолт в mdadm (особенно неприятно при загрузке). Проверил багзилы, к RHEL уже был патч (не знаю, вышел ли апдейт), но вобщем не все пока еще оттестировано. А казалось бы, тестируют аж со времен Fedora 12.
Ну, все бывает. Например nfs-utils в текущем 6.1 RHEL бажный :) С самого момента выхода. При использовании kerberos авторизации в nfs4, на сервере возникают проблемы с новыми линукс-клиентами и все "мистически глючит". Я смог решить только откатом на nfs-utils-1.2.3-4 из 6.1 beta и блокировкой обновления. Тоже, вроде, много лет тестируют?.. ан нет, апдейтом для лучшей поддержки active directory в kerberos (bz 671474) они замечательно все поломали аккурат между бетой и релизом.Если нужный вам апдейт появится в RH, то чтобы получить его в SL, не забудьте поставить yum-conf-sl-other и включить sl-fastbugs, а то можете пропустить - многие обновления, исправляющие только какой-то редкий баг появляются только там.
> Ну, все бывает. Например nfs-utils в текущем 6.1 RHEL бажный :) С
> самого момента выхода.А еще они не поправили "ужасно сложную" багу в init-скрипте autofs. Поэтому еще со времен RHEL5 приходится делать /etc/init.d/autofs stop а затем и start, вместо простого restart.
> CentOS сначала выпускает 4.x и 5.x, потом уже 6.x, а SL наоборот.
> CentOS 5.6 вышел раньше, чем SL 5.6.Дядя шутит? Когда php53 появился в SL, а когда в CO?
> Без лишней пыли, в отличие от уже мёртвого CentOS.Живее всех живых.
Тише едешь, дальше будешь.
Согласен. Уже ставлю саентифик, центос труп - на помойку с такими скоростями. И по pxe когда ставил 6.0 центос - в инстоляторе косяк, а саентифик ставится без проблем.
А багрепорт запилить слабо было?
> А багрепорт запилить слабо было?Лень, мне сервер поднимать надо было быстро, а не с багами разбираться и ждать пока вофиксят.
>Лень, мне сервер поднимать надо было быстро, а не с багами разбираться и ждать пока вофиксят.Если нужно быстро - то есть резон купить таки RHEL.
> Если нужно быстро - то есть резон купить таки RHEL.Ну как вариант, попрошу денег, но есть вероятность, что не надут. Если бы один раз платить - стряс бы денег, а т.к. апдейты платные - могу развернуть
sl 6 обновляется на 6,1? Репы на новые поменять или с диска как-то?
Поставьте yum-conf-sl6x, чтобы мигрировать между релизами автоматически, как в centos.
Без этого пакета считается, что вас интересуют замороженные релизы.
А что собственно осталость scientific?
Если раньше это был дистрибутив, заточенный на выполнение научных задач, то теперь еще один редхат.
Он более scientific, чем остальное - этого мало?"еще один редхат" - вы так говорите, будто в этом что-то плохое. Живых из этих "редхатов" можно пересчитать пальцами одной руки, а бесплатных из них всего два, при этом актуальной версии только один - как раз scientific.
Я это к тому, что в scientific linux наметилась устойчивая тендения вывода "научного" софта за пределы дистрибутива, т.е. его нужно докачивать из интернета, что не всегда возможно (в нашем вузе ограничения, например, 4Мб на файл установлены, по своему опыту знаю, что yum-система проста только для хорошего админа, но не для математика-химика-биолога-и т.п. (про профессуру вообще умолчу)). Вот и получается, что пилится не "линукс для научных целей", а еще одна серверная платформа на базе редхата. В общем, ничего плохого в этом нет, однако "соль проекта" теряется.Предлагаю составить список "действительно нужных научных проектов" и сравнить с тем, что есть в scientific linux, что было выкинуто, а что можно рекомендовать разрабам добавить.
Для меня, например, важно наличие пакетов символьной и численной математики, текстовый и табличный процессоры, инструментарий программирования (C/C++, Pascal, Basic, Fortran, assembler, prolog, lisp и т.п.) с IDE, инструментарий создания UML-диаграмм, хороший просмотрщик графической и мультимедийной информации, система подготовки презентаций и отчетов о НИР, система виртуализации для запуска win32 программ, браузер для доступа в интранет университета, в интернет, антивирусное ПО, хороший математический словарь (русско-русский, буржуйско-русский, русско-буржуйский) да и просто словарик с удобной оболочкой, не лезущий за каждым словом в интернет не помешает.
Всяческие исходники ядра, экзотические языки шелл-программирования, сквиды, средства разграничения доступа и прочие "админские" программы, на мой взгляд, в "линуксе для ученых" не нужны.
Оно выводится, чтобы быть доступным извне. Если это возможно без ухудшения доступности, почему бы и нет? Ничего же не выкидывается.4 Мб на файл - это вообще не относится к проблемам дистрибутива.. А крупные обновления в SL вы как ставите? А переход на новую ветку? Если вы держите одну rsync'нутую копию репозитория на весь институт - ничего необычного в этом нет, это нормальная практика. Просто добавьте мирроринг epel, atrpms и что вам требуется туде же.
Насчет математика.. разве математик-химик-биолог будет два часа лазить по списку программ в инсталляторе, выбирая нужные ему?
Мне кажется, скорее поставит по умолчанию и потом доставит то, что нужно. А это делается сейчас ровно так же, как и сейчас. Обратите внимание, в сам SL входят пакеты, подключающие epel, atrpms, elrepo и тд. Вам не нужно куда-то лезть, искать, ставить.. Они выносят пакеты в эти дистрибутивы потому, что подключить и воспользоваться ими можно в рамках самого SL, готовые .repo идут в комплекте. Включаете их и используете.
Наконец, "Для меня, например, важно наличие пакетов символьной и численной математики ...". Вообще-то SL поддерживает замечательный инструмент revisor, который сделан для решения вашей задачи - причем очень удобен. Он создаст дистрибутив для вас или для вашей целевой аудитории - в котором вы можете выкинуть лишнее, включить нужное (в том числе из других репозиториев) и сделать на основе этого свой диск или даже live-cd (тут нужны еще другие инструменты, но все в комплекте). Разработчики SL вполне поддерживают эти механизмы и рекомендуют всем, кому требуется свой дистрибутив на базе SL им пользоваться и создавать свой срез. Руководство есть, например, тут http://www.scientificlinux.org/distributions/6x/build/sites - ну и погуглите на тему revisor.
Наконец, есть готовый http://www.naulinux.ru/ . Может, вам больше подойдет?
А насчет сквида, админских програм - а почему выкидывать, разве плохо на серверы этого же самого университета ставить тот же самый SL? Удобнее управлять, единообразие, совместимость, опять же экономия трафика, о которой вы печетесь :) И сквид пригодится, и разграничения доступа. В общем, мыслите шире! А SL сейчас все позволяет :) И нам, и вам, как говорится. Ну а то, что под вашу специфическую задачу нужно немного руки приложить - что в этом странного. Да и под такую задачу, как дистрибутив для университета, наверное, не жалко. Тем более, что работу проделать нужно один раз, а дальше только изредка корректировать для новых версий раз в несколько лет.
Спасибо за развернутый ответ. Буду разбираться с revisor'ом. Похоже это именно то, что требуется.