Лаборатория Fermilab, занимающаяся разработкой дистрибутива Scientific Linux, объявила (https://listserv.fnal.gov/scripts/wa.exe?A2=ind1904&L=SCIENT...) о сворачивании разработки дистрибутива и намерении в дальнейшем перейти на использование CentOS 8 вместо разработки новой ветки Scientific Linux 8, основанной на пакетной базе Red Hat Enterprise Linux 8 (https://www.opennet.dev/opennews/art.shtml?num=49613).
Вместо поддержания собственного дистрибутива разработчики из Fermilab намерены скооперироваться с CERN и другими научными организациями для усовершенствования CentOS и превращения его в более качественную платформу для вычислительных систем, используемых при организации экспериментов по физике высоких энергий. Переход на CentOS позволит унифицировать вычислительную платформу для научных применений, что упростит организацию работ в существующих и будущих совместных международных проектах, охватывающих различные лаборатории и институты.Переход с Scientific Linux на CentOS не должен вызвать проблем, так как ещё в рамках подготовки ветки Scientific Linux 6 специфичные для научного применения приложения и дополнительные драйверы были перенесены во внешние репозитории EPEL (http://fedoraproject.org/wiki/EPEL) и elrepo.org (http://elrepo.org/). Как и в случае с CentOS отличия от RHEL в основном массе сводятся к ребрендингу и чистке привязок к службам Red Hat. Ресурсы, высвободившиеся в результате делегирования в проект CentOS операций по сопровождению дистрибутива и инфраструктуры, можно будет направить на усовершенствование компонентов, специфичных для научного применения.
Сопровождение существующих веток Scientific Linux 6.x и 7.x будет продолжено без изменения, синхронно со штатным циклом поддержки (https://access.redhat.com/support/policy/updates/errata) RHEL 6.x и 7.x. Обновления для Scientific Linux 6.x продолжат выпускаться до 30 ноября 2020 года, а для ветки 7.x до 30 июня 2024 года.
URL: https://listserv.fnal.gov/scripts/wa.exe?A2=ind1904&L=SCIENT...
Новость: https://www.opennet.dev/opennews/art.shtml?num=50554
На какой дистр теперь переходить?
На CentOS, написано же.
На тот, который поддерживается CERN для _своих_ нужд. Scientific Linux был создан для долгосрочной поддержки ПО для LHC дабы не зависеть от кратковременных циклов RedHat. Видно, что Fermilab не в состоянии тянуть этот воз. В своё время возможность прислониться к ЦЕРНовской поддержки для наших локальных проектов это было спасением. С тех пор прошло много времени и в частности виртуализация позволяет легко заморозить софт и его окружение на любом этапе и легко переезжать на новое железо без необходимости что-либо меня почти от слова совсем.
> кратковременных циклов RedHat.давайте сравним eol для sl и centos:
sl:
3 2010-10-31
4 2012-02-29
5 2017-03-31
6 2020-11-30
7 2024-06-30centos:
3 31 October 2010
4 29 February 2012
5 31 March 2017
6 30 November 2020
7 30 June 2024совпадают число в число. а вот именно у redhat, т.е. rhel, есть extended lifecycle support, это на четыре года дольше:
3 30 January 2014
4 31 March 2017
5 30 November 2020
6 30 June 2024
7 TBD
Дьявол там в деталях. Да, "General User Support" для Scientific Linux CERN такой и есть, как прописан в вашем посте, но дальше идёт приписка вида "Dedicated experiment support is maintained" что продолжает поддержку как минимум до ближайшего шатдауна. Например, можно глянуть тут: http://linux.web.cern.ch/linux/scientific5/ -- этот самый "Dedicated experiment support" дал + 2 года апдейтов безопасности тем, кто прислонился к этой программе. Да, конечно, можно подписаться на RHEL, но в наших условиях это было, да и сейчас есть не особо реально.
Фиксы по безопасности для SLC5: http://linux.web.cern.ch/linux/updates/updates-slc5.shtml -- то, для чего eol для "Обычных пользователей" приключился в 2017 году.
в 5 уже была виртуализация в виде очень вылизанного xen'а.
а вот для 4-ки апдейты закончились на том же 2012 году, как и в centos: http://linux.web.cern.ch/linux/updates/updates-slc4.shtml
дьявол в деталях, да.
Ну да, потому что цель была не держать релиз максимально долго, а поддерживать то, что используется в эксперименте. 4ка пришлась на шатдаун и к началу работы её заменили 5кой. Иными словами, чтобы "получить пользу" от SLC вне CERN, нужно было подгадать с началом эксперимента.На самом деле это было особо актуально в основном до того как CERNовский дистрибутив стал называться Scientfic Linux.
Вы пользуетесь libreoffice в связке с xneur?
Но с другой стороны, CERN уже переезжал на centos, и быстро быстро вернулся ))))
> Видно, что Fermilab не в состоянии тянуть этот воз.У них ничего своего сопоставимого по объему обработки с LHC сейчас нет. Участники экспериментов LHC из FNAL не в счет.
Это-то понятно, но они позиционировали себя полноправными партнёрами и когда CERN отвалился от темы, то пытались продолжить её как ни в чём не бывало. Значит были какие-то причины так думать.
на oracle linux вестимо
Ага, и софт для физики элементарных частиц в нём есть.
Эээ. Конечно. Исходники доступны. Другое дело переезд на другую инфраструктуру -- это головняк далеко не всегда оправданный.
Смотря зачем.
Чет мне подсказывает что у тебя независимо от целей будет Альт линукс.
> Чет мне подсказывает что у тебя независимо от целей будет
> Альт линукс.У меня иначе, как-то рассказывал. Во-первых, нет смысла пихать даже хорошо обкатанную и привычную систему вообще для всего, в т.ч. туда, где объективно перевешивают более обкатанные под конкретную задачу подставки. Во-вторых -- у меня этих самых целей (потенциальных) ещё лет десять было столько, что сосредоточиться на тех, которые _мне_ удобней делать на том же альте, было наиболее естественным и логичным выбором.
И это наблюдение наверняка дистрибутивонезависимо -- кто-то будет хорошим специалистом, более-менее зная сильные и слабые стороны нескольких вариантов и имея возможность предложить наиболее подходящую в конкретном случае; кто-то будет хорошим специалистом, "закопавшись" в одну систему, но понимая границы её применимости; ну а кто-то будет... не очень, упорно пытаясь впихнуть квадратное в круглое.
PS: возможно, пора обмахнуть веничком http://wiki.opennet.ru/DistroImhoMike :-)
PPS: s/подходящую/& ОС/
Чет по моему ви таки сидите на винде...
> Чет по моему ви таки сидите на винде...Холодно, совсем холодно :] На локалхосте вместо винтела -- этакий эль-аль:
e801-1:~> lscpu
Архитектура: e2k
Порядок байт: Little Endian
CPU(s): 8
On-line CPU(s) list: 0-7
Thread(s) per core: 1
Ядер на сокет: 8
Сокетов: 1
NUMA node(s): 1
ID прроизводителя: MBE8C-PC v.2
Семейство ЦПУ: 4
Модель: 2
Имя модели: E8C
CPU MHz: 1299.914885
BogoMIPS: 2601.10
L1d cache: 64K
L1i cache: 128K
L2 cache: 512K
L3 cache: 16384K
NUMA node0 CPU(s): 0-7
e801-1:~> uname -r
4.9.170-elbrus-def-alt3.6.3
e801-1:~> cat /etc/altlinux-release
ALT Sisyphus (20180524)
...а также независимо от пригодности дистра для задачи, наличия нужного софта и человека способного это г-но потом поддерживать.
То же самое и про РХ можно сказать. Про пригодность для задачи.
Вполне возможно выяснится, что если сравнить циклы/принципы разработки в Дебиане, то он лучше господам учёным подойдёт. А РХ выбрали потому что гладиолус и просто админ его знал.
Жаль, что позно ветку прочитал... Но может кто и увидит этот комментарий.Вы серьёзно так считаете, что "просто админ его знал"?
Тогда мне интересно, и какой же конкретно из этих сотен "админов"?:
https://cern.service-now.com/service-portal/contacts.do
https://security.web.cern.ch/security/services/en/index.shtml
http://information-technology.web.cern.ch/servicesИли речь про "Connie Sieh, from Fermilab"? :
http://www.scientificlinux.org/about/why-make-scientific-linux/Так там в 2003-ем году, тоже не сразу всё происходило.
И далеко не один человек решал.Тут сравнивать надо не циклы разработки Дебиана,
а механизмы принятия стратегических решений в крупных сообществах:
http://information-technology.web.cern.ch/about/meeting/catalogА вот с качеством таких коллегиальных решений можно и поспорить...
Но... сюрприз-сюрприз... только через те же самые механизмы обсуждений.
> А вот с качеством таких коллегиальных решений можно и поспорить...
> Но... сюрприз-сюрприз... только через те же самые механизмы обсуждений.Спасибо, занятно.
вообще-то у него есть большой бонус - для _его_ задач его дистрибутив будет пригоден всегда, в нем всегда будет нужный софт, и человека, чтоб поддерживать, если понадобится и не справится сам - наймут.А вот церновскому человеку не повезло - он уже идет искать работу (вряд ли софт для экспериментов пилил и апдейты безопасности из коммерческого редтаха тырил один и тот же)
А ничего, что CERN один из крупнейших "корпоративных клиентов" RedHat?
С постоянным продлением миллионных контрактов на support?Чем красные шапки время от времени сами гордятся:
https://www.redhat.com/en/about/press-releases/red-hat-provi...Это я к тому, что "апдейты безопасности из коммерческого редтаха тырил"
не один человек, и не тырил, а сами редхатовцы регулярно их заносят куда надо:
https://security.web.cern.ch/security/services/en/index.shtmlЗа что редхату могут перепадать бонусы в виде "поучаствовать в крупном проекте":
https://geant3plus.archive.geant.net/Resources/Media_Library...Так что уж ЦЕРН'овским работу искать не придётся, им бы свою успеть в срок.
А то и сами ещё штук десять новых проектов сгенерят "Вот тут узкое место! Тормозит нам всё!".В общем-то и Scientific появился у них как раз там, где им редхата не хватило.
И убунта с дебьяном у них имеется, и даже яблоки с окнами попадаются в террариуме..
И это... Пусть генерят, иногда у них мимоходом получается:
https://home.cern/science/computing/birth-web
Со Scientific Linux? На Ubuntu, конечно же.
с Центоса на Центос :)
Правильное решение
Ибо нечего плодить одно и тоже
Куда продуктивнее объединение и развитие одной, но мощной инфраструктуры
Нежели туевой хучи шаек дистров, где каждый пестрит "вот я! вот я!"
А отличия лишь в нескучных обоях (и то не всегда), но суть и основа либо тот же debian, либо та же fedora
Не согласен. Scientific Linux был полностью независимым проектом. CentOS же развивает сам Red Hat и совсем непонятно куда может занести новое руководство после завершения сделки с IBM. Начнут урезать издержки, как это любит IBM, или какой-нибудь эффективный менеджер посчитает, что бесплатный CentOS вредит бизнесу и оттягивает клиентов. Совмесем непонятно куда ветер подует, что будет с CentOS и сможет ли он возродиться как независимый проект.
> Не согласен. Scientific Linux был полностью независимым проектом.полностью независимо выпиливал логотипы и вносил независимый вклад в глобальное потепление, пересобирая уже собранное?
Ну чо, туда и дорога.
> CentOS же развивает сам Red Hat
редхат, удивитесь, дети, развивает - redhat. А центось - это нате-на-лопате то же самое бешплатно нааляяяяааааву. Потомушта гепеле, а ковыряться неохота. А механизм выпиливания логотипчиков и пересборки тех же самых src.rpm на соседнем билдхосте - его развивать не надо, он уже лет десять назад достаточно развился.
Ничем другим ни те, ни другие, никогда не занимались - это не форки редхата, это сам редхат и есть. Теперь, хотя бы, в одном и том же месте.
> полностью независимо выпиливал логотипы и вносил независимый вклад в глобальное потепление, пересобирая уже собранное?Нет. Еще до того как centos вошел под крыло редхата, SL был приятнее во всех отношениях. Нормальные, актуальные и подписанные debuginfo (в центоси вечно отставали, обновления есть, а debuginfo нет - и ни gdb, ни perf не покажут внятных результатов; ну а подписывать пакеты они вообще ленились, т.к. им жалко трафика и ресурсов - сборочная ферма это одно, а подписывает конкретная машина, и ресурсов еле хватало на подписывание критически важных пакетов, а на всякую побочку типа debuginfo уже не оставалось). Более здоровое коммьюнити, у центоси багтрекер, в котором годами висят баги и всем по фиг и рассылки с токсичными пользователями, забивающие их общие вопросы уровня секции для чайников в ubuntu forums, либо требующие от сборщиков центоси изменений, которые они физически не могут сделать, будучи пересборщиком пакетов редхата, а у SL в рассылках таких неадекватов практически нет, а разработчики очень быстро реагировали на проблемы и чинили, если что-то где-то поломано. Т.к. в центоси "никто никому ничего не обязан", а в SL люди на зарплате от CERN/Fermilab. Небольшие поломки репы, особенно при выпуске обновлений от нового релиза до самого релиза изредка случаются и там и там, но в SL на них реагируют быстрее.
И еще было несколько случаев, когда дополнительный уровень бета-тестирования и контроля в SL позволял не допустить пакеты с багами, которые вылезали в RHEL или Centos.
Опять же, есть ли в центоси свой (не редхатовский закрытый) список errata (типа https://www.scientificlinux.org/category/author/sl-errata/) и возможность устанавливать обновления по конкретным advisory?
> Нормальные, актуальные и подписанные debuginfo (в центоси вечно отставалину так то - в центоси, чтоб денег не платить - у оригинала-то и подписанные, и вовремя.
> Более здоровое коммьюнити, у центоси багтрекер, в котором годами висят баги и всем по фиг
им не то чтобы пофиг, им нечего с ними делать - баг апстримный, сдать его нельзя, потому что платно, самим исправить - риск сломать совместимость с багами в апстриме (а то это и вообще не баг а так надо - редхату, такое вообще нельзя исправлять).
А какие еще там баги висели- неправильно логотип перерисован?
> Опять же, есть ли в центоси свой (не редхатовский закрытый) список errata
а делать-то с ним - что? Исправить-то нельзя, пока пчелы не прилетят.
> устанавливать обновления по конкретным advisory
чьим? ;-) RH - низзя же ж, трейдмарк, своих нет.
У SL были собственные с собственными номерами?
>> Нормальные, актуальные и подписанные debuginfo (в центоси вечно отставали
> ну так то - в центоси, чтоб денег не платить - у
> оригинала-то и подписанные, и вовремя.Правильно. Но у SL нет никаких проблем с debuginfo.
А еще, кстати, они предоставляют обновления для предыдущих релизов. Т.е. можно оставаться на 7.4 например и получать критические обновления. Бесплатный аналог z-ветки в RHEL. Хотя, конечно, не настолько тщательно тестируемый и не такой качественный. Но у центоси и того нет.
>> Более здоровое коммьюнити, у центоси багтрекер, в котором годами висят баги и всем по фиг
> им не то чтобы пофиг, им нечего с ними делать - баг
> апстримный, сдать его нельзя, потому что платно, самим исправить - риск
> сломать совместимость с багами в апстриме (а то это и вообще
> не баг а так надо - редхату, такое вообще нельзя исправлять).Да, но есть разные баги. Ну и есть centosplus, в конце концов (или уже нет?)
> А какие еще там баги висели- неправильно логотип перерисован?
Были случаи, когда были баги даже с патчами, но никакого особого движения не происходило, а апстрим сомневался с багом.
В итоге пользователи редхата мучались с https://bugzilla.redhat.com/show_bug.cgi?id=1481207 а в SL выпустили патченый iptables до того как это сделал редхат (и, по-моему центось. Т.е. в центоси знали про патч, который исправляет баг, но мешкались с выпуском патченной версии вперед апстрима).
>> Опять же, есть ли в центоси свой (не редхатовский закрытый) список errata
> а делать-то с ним - что? Исправить-то нельзя, пока пчелы не прилетят.Полезно для систем, где автообновления по каким-то причинам включать не хочется, но отдельные вещи хочется отслеживать и ставить конкретно их. Подписываемся на рассылку, видим что приходит, ставим только то, что нужно: https://listserv.fnal.gov/scripts/wa.exe?A2=SCIENTIFIC-LINUX...
>> устанавливать обновления по конкретным advisory
> чьим? ;-) RH - низзя же ж, трейдмарк, своих нет.
> У SL были собственные с собственными номерами?Да. Почему были? Есть. По SLSA из рассылки по ссылке выше можно поставить. Или посмотреть что как стоит и доступно
# yum updateinfo list all security | grep java-11-openjdk-1
i SLSA-2018:3521-1 critical/Sec. java-11-openjdk-1:11.0.1.13-3.el7_6.x86_64
i SLSA-2019:0436-1 moderate/Sec. java-11-openjdk-1:11.0.2.7-0.el7_6.x86_64
i SLSA-2019:0778-1 moderate/Sec. java-11-openjdk-1:11.0.3.7-0.el7_6.x86_64
Я вообще всего-то хочу сказать, что много где SL делали работу качественнее, чем центось, пусть это и почти одно и то же. И это было удобно. Блин, я столько проблем в свое время из-за необновляемых debuginfo в центоси имел (весь цикл 6-ки, часть цикла 7-ки как минимум - дальше не знаю, везде поменял на SL) - они их пересобирали к очередному минорному релизу, а между релизами с огромным (недели) отставанием или вообще не собирали для обновлений. А в SL все как по маслу. И жаль, что SL больше не будет, т.к. я не вижу, чтобы ответственные товарищи оттуда сделали так, что все в центоси стало бы замечательно.
> Да. Почему были?ну, потому что SL уже в общем-то тож - "были".
жаль, я раньше не знал что они настолько продвинутые, может был бы мне от них какой-нибудь прок.
Посколько от центоси я отказался именно из-за феерической бесполезности обновлений с задержкой на недели (что особенно радовало на фоне поломанной отписки от редхатовского баглиста) и необходимости в каждой новой версии исправлять одно и то же (патамушта так в редхате)
Я перешел на SL когда у Centos потерялись сервера, а админ куда то укатил.А потом привык к их удобствам, одни только репы yum-conf* уже привлекли
Да, намного лучше, продуктивнее и качественнее, если делать кучу дистров "огрызков"
В итоге имеем то, что имеем, что основа та же центося, впилим туда утилиту которой нет в центоси и вуаля, у нас центося232
Всё с центом будет в порядке, за это точно не стоит переживать, даже если IBM скажет, что-то в духе "CentOS закрыт", всем будет пофиг, найдётся кто-то, кто форкнет и будет AntiCentOS
Почистить код от упоминаний цента, провести ребрендинг и вуаля, цент будет жив в то же мнговение под другим названием, но по сути в том же составе и своей мощи
А что ценного и продуктивного в том же Scientific?
Вот он был независим и теперь нет, а кроме того, что он был весь на центе основан, что дальше то?
Да уж лучше, пусть закроется ещё 5-10 дистров и вольют силы именно в один дистр, который будет допилен и вылизан со всех сторон каждой команды, которая хочет своё получать в результате использования именно цента (в данном случае)
И это правильное решение с точки зрения продуктивности и развитияНе спорю, свобода выбора дистра это замечательно, но в текущий момент времени, это уже именно идиотизм и иначе не назвать
С 2010 года даже если взять, посмотрите сколько ответвлений от rpm-based, который ныне полудохлые?
Или deb-based?
Да тьма, а разница у каждого лишь в одном "основан на стабильной ветке debian" и в этом духе (fedora, mandriva, centos, ubuntu)
> Да тьма, а разница у каждого лишь в одном "основан на стабильной ветке debian" и в этом духе (fedora, mandriva, centos, ubuntu)так то RHEL на пакетной базе fedora строится
>так то RHEL на пакетной базе fedora строится5 за внимательность
2 за непонимание сути
грефца ж еще не взяли туда на работу. без еффективных манагеров так что
В качестве примера просто напомню свежую историю с джавой.
Проприетарщина, она такая.
Ошибочка, Федора пришла из RedHat)но суть и основа либо тот же debian, либо та же красная шапочка
А Патриг не в счет, он один дистр свой строит!!!)
>но суть и основа либо тот же debian, либо та же красная шапочкаОб этом то и речь
Ошибочка, fedora.us пришла как раз _не_ из redhat. Всем пропустившим те времена напоминалочка:https://www.redhat.com/archives/fedora-devel-list/2004-May/m...
haha! that's a good one!))) отлично, я люблю такое)
Да ну. Грусто всегда как-то мне. Не знаю вот, но когда Мандрейк стал Мандривой, то я как-то так приуныл, что сбежал в эти ваши дебианы. Тогда еще 4.0
Хз, мне ни дебиан, ни убунту, ни минт не родныНо да, грустно, что есть тьма говнодистров, которые сами по себе выжить и не смогут, ибо "заимствуют" у какого-то одного дистра
Взять тот же минт, а нет в нем ничего выдающегося и офигенного прям такого
И более того, без #бунты, не будет минта
без дебиана, не будет lmde
Понимаете суть?
ИМХО это связано с приобретением IBM, скорее всего они сумели убедить в том что всё будет хорошо и в CentOS
Это не Unix-way. Юниксейно будет плодить никому не нужные форки форков и костыли под них, как было до появления линукса.
Опять происки Организации!
Эль. Псай. Конгру.
Туттуру!
Это я. Организация начала ставить минусы. Проклятый ЦЕРН. Да, понятно. Они не получат машину времени.
Эль, пси, конгру.
Организация - Организациий, но Окарин всё равно эталонный мyдак.
А теперь остаётся только дождаться новости о том, что CentOS свёрнута в пользу Red Hat Enterprise Linux :(
>дождаться новости о том, что CentOS свёрнута в пользу Red Hat Enterprise Linux :("Red Hat Enterprise Linux состоит из свободного ПО с открытым кодом, но доступен в виде дисков с бинарными пакетами только для платных подписчиков. Как требуется в лицензии GPL и других, Red Hat предоставляет все исходные коды. Разработчики CentOS используют данный исходный код для создания окончательного продукта (...)"
Ergo, мой юный и чрезмерно страшащийся корпораций друг, CentOS и есть, по сути, Red Hat Enterprise Linux, только собранная из исходников силами комьюнити, а не компании Red Hat. Свернуть гласом свыше/сбоку/из бездны это невозможно ибо GPL жеж. Если же комьюнити CentOS разбежится, морально разложится, сойдет с ума или сопьется - найдутся другие люди и образуется другое комьюнити, которое будет собирать из исходников RHEL всё ту же CentOS, даже если придумают для неё другое название.
> силами комьюнитиЧё, вот прям сидит индус на личном сервере и собирает до сих пор?
Так-то да, помним не только SL, а и WBEL.
Исходники RHEL доступны - да или нет? Если да, то весь этот сарказм просто кошачий чих. Haters gonna hate (c)
Доступны не только лишь всем.
Всё меняется, не известно во что их превратит новый владелец, но вроде как он очень любит в науку...
Fermi Linux забыл. И еще стопицот шапкоклонов, пополнивших кладбище наколенных пoделок.
> только собранная из исходников силами комьюнити, а не компании Red Hatугу-угу. точно-точно не компании. На железе редхат, из исходников редхат, людьми на донейте от редхат - комьюнити-комьюнити.
> найдутся другие люди и образуется другое комьюнити
это вряд ли - вот еще одни специалисты по выпиливанию логотипа внезапно поняли, что ипотека сама себя не выплатит, даже под 2.1%, и надо идти работать.
(а может просто церновский грант кончился, а нового не дают)Кстати, прикрыть лавочку, если rh/ibm всерьез того захочет, можно одним движением пальца - просто изменить dnf/yum так, что без rhn (которая ни разу не обязана быть gpl) ничего работать не будет.
А собственный софт для поддержки репо и разрешения зависимостей - это уже несколько сложнее чем выпил логотипов.
Но они не захотят - им как раз нафиг не нужны конкуренты. Жрите вашу центось с лопаты, дорогие эффективные менеджеры, любители халявы.
> ипотека сама себя не выплатит, даже под 2.1%...а если/когда за неё приплачивать начнут -- ценники на дома просто рванут ещё дальше даже там, где до приличной школы и так далеко, зато до бездельников любого окраса близко.
это ты про ресурсную федерацию-то? Ну я прям даже и не знаю, почему в ней ценники зависят от ипотеки в чужих странах (где все хорошо со школами, а бездельники и алкашня как-то не особо попадаются на глаза).
> это ты про ресурсную федерацию-то?Вы бы матчасть-то подтянули -- где это "только приехал, уже полляма должен" и где безумные цены на этсамую недвижимость _сильно_ зависят от тех самых указанных мной факторов, которые понаухавшие вдруг неожиданно открывают для себя экспериментально. Hint: по другую сторону пролива.
Но это уже совсем п.10, так что через какое-то время наверняка пойдёт под /dev/нож...
PS: а упомянул к тому, что "два процента ипотеки" -- это не прямая ложь, а всего лишь полуправда, причём напрямую опасная для потенциального получателя.
>На железе редхат, из исходников редхат, людьми на донейте от редхат - комьюнити-комьюнити"Завидовать будем!" (с) тов. Сталин
>просто изменить dnf/yum так, что без rhn
И никто не мешает форкнуть yum/dnf. Но проще, конечно же, сидеть и бояться - "они могут покуситься на нашу свободную свободу!".
>Жрите вашу центось с лопаты, дорогие эффективные менеджеры, любители халявы
Ты так сказал "халява", как будто это что-то плохое.
> И никто не мешает форкнуть yum/dnf.редхатовской зарплаты только вот не будет. А на деньги товарищмайора Миша уже форкнул, там уже тоже лишних нет.
И нет, это не очень легко и просто будет сделать, когда все придется создавать самому, от билдсистемы до инсталлятора (потому что редхатовский, разумеется, станет работать с rhn по непаблик протоколу), и за свой счет оплачивать железо.
Неспособность "комьюнити" даже на примитивные вещи неплохо показала история с редхатовским патчем ядра, который просто разобрать на детали и разобраться в них - ниасилили, как только rh решила перекрыть крантик. (в принципе, это и раньше было очевидным, из серии - у рх индус ответственный за ядерные патчи запил/в PTO, ВСЕ - дебиан, бубунта, шлак, сузя - сидят неделю-две с remote exploit, хотя патч двустрочный и в lkml в чистом виде был. Индус протрезвел - все суматошно выпускают апдейт [кроме дебиана, у которого "разработчик" вообще к компьютеру раз в месяц подходит])
>> И никто не мешает форкнуть yum/dnf.
> редхатовской зарплаты только вот не будет.А сузешникам не нужно.
> А на деньги товарищмайора Миша уже форкнул, там уже тоже лишних нет.
Это который? Вроде никто из знакомых центосоклонов (и да, вот там бывали и "деньги трщгенерала" за последние лет десять-двенадцать) _не_ форкал yum/dnf.
А у нас подбирали конективовский форк apt (как раз начавший загибаться после скупки конективы мандрякой, помнится) в довольно трудные времена и сугубо на свои. Как, впрочем, и сейчас.
Из важного Вы упустили то, что тот же rpm сейчас те два неиндуса пилят в узко-зашоренном режиме "под шляпу" -- история начала века, похоже, повторяется неучами (хотя им и Джефф пытался что-то объяснять, и не только он, насколько понимаю).
> Неспособность "комьюнити" даже на примитивные вещи
> неплохо показала история с редхатовским патчем ядра,
> который просто разобрать на детали и разобраться в них
> - ниасилили, как только rh решила перекрыть крантик.Мне она показала как чисто тамошнюю беспринципность оракла (кто помнит профессию первого спамера, тот поймёт), так и -- лишний раз -- важность постижимости вместе с юниксовым подходом, при котором "кубики" остаются доступны человеку, а не коллективу-на-ставке.
>> редхатовской зарплаты только вот не будет.
> А сузешникам не нужно.им бы не обанкротиться нужно, для начала, в качестве плана на ближайший квартал.
>> А на деньги товарищмайора Миша уже форкнул, там уже тоже лишних нет.
> Это который?это который altlinux, не слышал о таком? ;-)
> Из важного Вы упустили то, что тот же rpm сейчас те два неиндуса пилят в узко-зашоренном
> режиме "под шляпу"напомните-ка кто-нить, что там случилось с rpm5, который не два, не те индусы и не под шляпу? Отож.
Так что пусть пилят - может даже документация будет (в конце-концов, той что есть, с кучей пропущенных угадаек, мы им же и обязаны - а так больше десяти лет был только совсем устаревший maximum rpm).
> так и -- лишний раз -- важность постижимости вместе с юниксовым подходом, при котором "кубики"
> остаются доступны человеку, а не коллективу-на-ставке.так у редхата-то они доступны - они наверняка все держат в vcs, где коммиты даже одного файла можно разглядывать поштучно.
Но не нам.Впрочем, я, помнится, еще в 2004м сдался - когда патчи были поштучными, и было их тогда что-то около 200. Когда кубиков слишком много и они на самом деле не кубики, а нечто сложное, бьющееся током или фонящее гамма-лучами - как-то быстро приедается пытаться ими жонглировать самому.
Можно только стырить кубик попонятнее - но вот как раз это - редхат успешно предотвратил, потому что им самим от этого тыренья никакой пользы не было. (опенсорсию как движению, если что - тоже, они-то сдают свои исправления в апстрим. Те, которые, правда, считают нужным). Только нахлебникам, вроде дебиана/убунты - которым, в конце-концов, пришлось искать денег на собственных вменяемых майнтейнеров.
>>> А на деньги товарищмайора Миша уже форкнул,
>>> там уже тоже лишних нет.
>> Это который?
> это который altlinux, не слышал о таком? ;-)Не, не слышал. Форком апта занимались люди, перечисленные в http://packages.altlinux.org/apt -- у mike@altlinux там заведомо ни одного коммита. Ну и у товарищмайора -- ни одной копейки, поди.
В общем, следим за руками, да? ;-)
>> Из важного Вы упустили то, что тот же rpm сейчас те два неиндуса пилят в узко-зашоренном
>> режиме "под шляпу"
> напомните-ка кто-нить, что там случилось с rpm5, который
> не два, не те индусы и не под шляпу? Отож.Во встройку ушёл, монтависту всякую, что ли.
> Так что пусть пилят - может даже документация
Свеженькое про двухлетней давности зарисовки с натуры:
https://lists.altlinux.org/pipermail/devel/2019-April/207808...
+-> http://lists.rpm.org/pipermail/rpm-maint/2017-August/006334....
+-> http://lists.rpm.org/pipermail/rpm-maint/2017-August/006335....
`-> https://github.com/rpm-software-management/rpm/pull/324
> Как требуется в лицензии GPL и других, Red Hat предоставляет все исходные коды.Тут нужно понимать, что исходники по GPL имеет право требовать только тот кто легально получил бинарники, то есть исходники можно предоставлять только тем кто купил RHEL, при этом GPL не оговаривает форму получения исходников, то есть можно хоть на глиняных табличках. А вот то, что RH предоставляет всем исходники в виде src.rpm из которых собирается потом CentOS это сугубо их добрая воля, они могут этого и не делать.
Ну вот cern и будет раздавать исходники, в чем проблема.
Ни в чем. Просто тот факт, что исходники раздает RH это сугубо их добрая воля, о чем все постоянно забывают
> Ни в чем. Просто тот факт, что исходники раздает RH это сугубо
> их добрая воля, о чем все постоянно забываютВсё Open/Free Soft движение держится на сугубо доброй воле.
нет никакого смысла делать по-другомукто-нибудь из тех кто купил обязательно завел бы репу на каком-нибудь гитлаба или гитхабе
Я просто оставлю это здесь (https://www.quora.com/Red-Hat-is-Open-Source-but-where-is-th...):Firstly let me dispel a common misconception: "Open Source" and "Free Software" can cost money, its completely fine to charge for software developed in this manner.
Free means Free Speech, not Free Lunch. As long as you can 1) Examine the source, 2) Modify the source, 3) Redistribute your modified version, and 4) Use the software however you wish it meets the standard of Free and Open Source.
(...)
As long as the source is available a provider does not have to provide the following and can charge for:
- Customer Support
- Cloud Based Services
- Managed Solutions for Large Scale Deployments
- Packaged software (ie software you don't have to compile from source)
- UI Using Custom Artwork/Typeface (Art is not software)Red Hat builds all of these into their business model and it is why you need a subscription for RHEL. Now you could download the source and go it alone, but you lose all of the above mentioned parts. The source code is here: http://ftp.redhat.com/pub/redhat/linux/enterprise/
(...)
Yes, Red Hat is open source. You can actually download its developer version from The world's open source leader For that, you might need to register on website for a developer account. You can also visit this Evaluate Red Hat Enterprise Linux page to download it for free.
А rh пару лет подряд так и делала, updates перестала обновлять.
Ну то есть в центос (тогда отдельный) они с опозданием на месяц продолжали откуда-то попадать, а на ftp была дырка от бублика. Но это они не со зла, просто что-то поломалось, а клиентам оно нафиг не нать, поэтому долго не замечали.redhat совсем не заинтересован в освобождении поляны для других, там должно быть занято.
Да понятно откуда, кто-нибудь из имеющих подписку им отдавал, вполне легальный способ получения, человек получивший GPLные исходники легальным путем дальше может их передавать, согласно тому же GPL.
> Да понятно откуда, кто-нибудь из имеющих подписку им отдавалвряд ли они такую фигню вручную делали - может и действительно просто разово платили 350 - не такая и великая сумма, дешевле в разы чем аренда мощностей для сборки и тестирования.
Может, кстати, еще и по этой причине их подгребли под себя - нефиг слишком быстро публиковать патчи, вот теперь все ок - недельная задержка ;-)
Поэтому Grsecurity добавили пункт при покупке у них услуги, что GPL-код не будет передаваться третьим лицам.
А этого делать нельзя, за что они и получили по рогам.
это польный фейл проекта и путь в никуда :(следом за CERN: In 2015, CERN began migrating away from Scientific Linux to CentOS.
Scientific Linux не создавался для "развития проекта". Scientific Linux создавался для долгосрочной поддержки окружения для специализированного ПО для нужд проектов LHC, где время заморзки определяется рамками эксперимента, который легко может продолжаться десятилетие. Сейчас это самое десятилетие фактически есть из коробки, поэтому нет необходимости заводить и поддерживать свою ветку.
Странный выбор.
SUSE был бы приятнее, но и на CentOS - сгодится.
Странный выбор перестать мучаться с отдельным дистром на базе CentOS и просто вливать свои наработки в сам CentOS? А мне кажется вполне логичный и правильный.
> Странный выбор перестать мучаться с отдельным дистром на базе CentOS и просто
> вливать свои наработки в сам CentOS?в сам центос ничего нельзя "влить", поскольку это просто пересборка rhel с нескучным логотипчиком, пересобирающаяся из редхатовских пакетов почти автоматически.
вливать можно только в rhel, а для этого официального пути нет - не считая федоры, которая потом то ли будет, то ли нет втянута в rh, но в любом случае пройдет несколько лет.
> вливать можно только в rhel, а для этого официального пути нет -
> не считая федоры, которая потом то ли будет, то ли нет
> втянута в rh, но в любом случае пройдет несколько лет.Ну да, вливать нужно в федорино горе. Хотя, учитывая что CentOS рулится напрямую RH(при чем уже пять лет, как тут напомнили) думаю можно пробовать и со стороны CentOS стучаться, если есть контакт, все равно сотрудники RH которые могут взаимодействовать со старшими.
И тут напомню, что CERN - один из крупнейших "корпоративных клиентов" у редхата,
так же как у HP, Intel, DELL и постоянный потребитель всех ресурсов, до которых
сможет дотянуться на деньги евробюджета и остальных стран участниц:https://cerncourier.com/cern-makes-it-into-supercomputing-to.../
[ причём в этой статье только их собственные мощности (тогда), и для них не такое
уж необычное дело дотянуться до соседей из top100 с настойчивым "дай пожевать!" ]Поэтому им не нужно искать отдельных сотрудников из CentOS, они, если/когда приспичило
"пинком открывают дверь в кабинеты" "старших" со словами "А вот ещё контракт хотите?
У нас тут опять ваши еnterprise проседают и обработку тормозят, к осени исправите?"А если не исправят, то можно и снова Scientific оживить, только не всегда людей
на все такие аппетиты хватает, но и это решаемо. Ротация в командировках со всех стран.
Вот что айбиэм животворящий делает.
Чем меньше дисрибутивов (sic), тем лучше.
Жду релиз RHEL 8
ждун.жпг
Вы такой оригинальный
еще в 2014 году, когда только цент перешел под крыло красношапки, это обсуждалосьhttps://www.opennet.dev/opennews/art.shtml?num=38999
сейчас объявили официально
все к этому шло, в чем кипиш ?
Блин, а CentOS уже 5 лет, как перешел под крыло RH? Фига себе время летит, мне казалось, что совсем недавно было дело.
Мировая закулиса. Корпорасты зохавывают мир.
> Разработка Scientific Linux 8 свёрнута в пользу== проект закрыт
> Разработка Scientific Linux 8 свёрнута в пользу CentOS
Первый - дистрибутив с набором специфического научного ПО, второй - универсальный дистрибутив. Сравнивают несравнимое.
Просто добавь пару реп и будет тебе ЩАСТЬЕ , wfiwwy
Если они ядро не перепиливали под свои научные пакеты, то тогда конечно нафиг еще один клон с нескушными обоями. Проще было сразу запилить репу и саппортить её.
А если ядро и корелибы подгоняли под эти пакеты - то ХЗ, как они это будут перетаскивать и что менее затратно: свой дистр продолжать пилить или мигрануть пакеты в репу и уйти на универсальный дистр.
Ядро они не трогали (ну, кроме поддержки своих ключей для secure boot). Но у них был дополнительный уровень тестирования относительно центоси.
Установить специфическое ПО бывает накладно. Еще русская адаптация NauLinux есть, судьба которого теперь неясна.
Судьба дистрибутива который в 2019 году имеет сайт в духе "1990-е" - быть забытым. "Случайно потеряют" при переезде.
Так ведь основная цель - поставить уже готовое установленное ПО. Мало добавить в репы, нужно поставить каким-то волшебным образом на пеки пользователей. И проще. когда по предустановлено, чем какие-то там манипуляции в поисках незнамо чего.
Для инженерных дистрибутивов тоже справедливо. Если CAELinux так же прикроют, возьни с установкой много будет.
> Для инженерных дистрибутивов тоже справедливо.Хозяйке на заметку: http://altlinux.org/engineering
> Если они ядро не перепиливали под свои научные пакеты, то тогда конечно
> нафиг еще один клон с нескушными обоями. Проще было сразу запилить
> репу и саппортить её.afair, в yumdnf нет приоритетов (в смысле, тех что есть у дебиана, по сути, а не названию), если в твоей репе будет лежать твой любимый патченный 1.1.1.1-128, а в центосевой 1.2-2 с кучей новых проблем - у юзера автовтянется второй, и ты еще потом потрахаешься вручную возвращать как было.
так что без координации с апстримом тут тоже далеко не уедешь.
И, судя по том что нам тут рассказывают, такие вещи делались, а не только пилился узкоспециальный софт для церновских нужд.
> Вместо поддержания собственного дистрибутива разработчики из Fermilab намерены скооперироваться
> с CERN и другими научными организациями для усовершенствования CentOSЭто зверски вольный перевод.
"
One part of this is unifying our computing platform with collaborating labs and institutions. Toward that end, we will deploy CentOS 8 in our scientific computing...
"Правильный перевод:
Научное сообщество проигнорировало наши начинания в области ИТ, а сопряжение нашего ПО с использующимся в сообществе мы не осилили, поэтому переходим на единую общую базу.
> Правильный перевод:Ну это тоже очень вольный, если уж придираться. :)
Хотя ссылку "исправить" под текстом новости не отменяли.
да б-г с ним, с SL 7/8. Отказ от afs создает больше временных неудобств.
Я что-то подобное про седьмой релиз читал %)
Там уже переписали yum с питона на C?
> Там уже переписали yum с питона на C?Так единственного, кто в нём вообще разбирался, автобус и сбил...
Привет из 2020(((.