LINUX.ORG.RU

Fermilab прекращает выпуск Scientific Linux

 , ,


6

2

Scientific Linux (SL) — дистрибутив операционной системы Linux, который создан совместными усилиями Fermilab и CERN, при поддержке различных лабораторий и университетов со всего мира. Он сделан из исходного кода для версий Red Hat Enterprise Linux в соответствии с условиями лицензионного соглашения с конечным пользователем.

В последнее время все больше и больше людей переходили с использования Scientific Linux на CentOS от Red Hat. И вот наконец Fermilab заявил что Scientific Linux 8 уже не будет, а все свои наработки они будут вливать в CentOS.

>>> Подробности

★★★★★

Проверено: Shaman007 ()
Последнее исправление: Shaman007 (всего исправлений: 1)

Ответ на: комментарий от Deleted

Ты мизинчик оттопыриваешь когда чай/кофе пьёшь?

WatchCat ★★★★★
()
Ответ на: комментарий от mv

Раньше центось была полумёртвым бажным говном, а SL - тем, что сейчас из себя центось представляет.

А как сейчас CentOS?

anonymous
()
Ответ на: комментарий от Deleted

Насчёт Nix - в результате его работы получается фарш в /nix/store, и никто не поручится, что этот фарш работает надежно.

Ну здрасте.

Софт не может обратиться к «неправильной» версии пакета? В теории да, а на практике - может, если захочет.

Ему для этого нужно обойти эвристику.

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

Ну и Nix уже полпути прошел.

При этом Nix еще и не позволяет реализовать базовый принцип инженера: работает - не тронь. Если мне нужно запатчить баг в glibс, не изменяющий её API, я всё равно должен пересобрать весь стек, хотя вышележащие компоненты не нуждаются в пересборке. В идеальном мире пересборка даст точно такой же результат. А в реальном возможны варианты.

Так это он его не нарушает, а энфорсит.

Nix решает проблемы не с того конца: требуется не уничтожение FHS, а её полная виртуализация. Вопспроизводимость - это условная характеристика, зависящая от требований конкретной задачи, а nix не дает возможности её регулировать.

Ну спрототипь. Это возможно, но выйдет в разы сложнее и без плюсов.

Итого из реальных недостатков контейнеризации - только недостаточный уровень дедупликации файлов.

Вот тут я завелся. Реальный недостаток контейнеризации - невоспроизводимость контейнера - куда делся? Можешь пересобрать случайно взятый «spectrum2/spectrum» и получить тот же контейнер, что и разраб перед коммитом? Я внимательно слушаю.

t184256 ★★★★★
()
Ответ на: комментарий от t184256

Реальный недостаток контейнеризации - невоспроизводимость контейнера - куда делся? Можешь пересобрать случайно взятый «spectrum2/spectrum» и получить тот же контейнер, что и разраб перед коммитом? Я внимательно слушаю.

Я уже говорил, воспроизводимость - критерий условный. На практике побитовая воспроизводимость - оверкилл. Т.е. на бумаге красиво, но на практике без надобности.

Deleted
()
Последнее исправление: Deleted (всего исправлений: 1)
Ответ на: комментарий от t184256

Насчет nix - может это взлетит лет через 20. Против концепции ничего не имею, но у текущей реализации пока проблем больше, чем достоинств.

Дело даже не в самом nix, не готова инфраструктура сборки.

На примере той же glibc и произвольного приложения app:

glibc sources                    app sources
|                                |
+----------------+               |
|                |               |
v                v               |
glibc compiled   glibc headers   |
|                |               v
|                +-------------->app compiled
|                                |
|                                v
+------------------------------->app deployed

В nix пока такое не сделать (ну или через костыли).

Deleted
()
Последнее исправление: Deleted (всего исправлений: 3)
Ответ на: комментарий от router

В жопу эти проприетарные недоподелки одного вендора.
router ★★★★★ (23.04.19 09:27:09)

Напомни, как от ограниченности микротика мы перешли к gpl?
router ★★★★★ (23.04.19 14:10:49)

гы

mogwai ★★★★
()
Ответ на: комментарий от DrRulez

Там не с udp беда, а с openvpn по udp. Нет, и не думаю, что завезут сами. Для s2s есть eoip и ipsec, для c2s лучше l2tp/ipsec, ибо из коробки в большинстве телефонов и десктопов клиент есть. Вангую, что раньше wireguard завезут, чем openvpn@udp

mogwai ★★★★
()
Ответ на: комментарий от Deleted

слишком толсто, у меня со смартфона жир потёк

burato ★★★★★
()
Ответ на: комментарий от mv

Начать с того, что сам RHEL в плане качества сильно сдал.

Какова причина падения качества?

Red Hat пытается объять необъятное, поэтому компании не хватает ресурсов для поддержки уровня качества на должном уровне? Или банально желание сэкономить на кадрах?

anonymous
()
Ответ на: комментарий от burato

Не беспокойся, то не жир а литий.

А машинку где сфоткал, и почему такое ужасное качество?

Выбрасывай и покупай как у всех айфон.

Deleted
()
Ответ на: комментарий от Deleted

ну это слишком сложно, даже hello word скомпилять в nixos и найти куда система положит результат сборки может оказаться не тривиальной задачкой )

nixos это система будущего, будущего но уже без людей :)

а новость топика конечно же печальна, но она и неизбежна, по мере совершенствования portage и из-за популяризации meson.build

PS. meson.build потому что и portage уже стала не прогрессом, а тормозом прогресса :) не позволяющим оперативно обновлять ПО. А уж про разные фермы сборки аля Hydra и говорить не приходится. Интересно в каких дистрах успели обновить CUDA последней ? Команда Gentoo так вообще забила на половине CUDA начиная с 10ки. Toolkit опакетила, а на SDK забила. :) и напрасно !

Deleted
()
Последнее исправление: Deleted (всего исправлений: 2)
Ответ на: комментарий от Deleted

Мода - это

Модно-это когда ты используешь Fedora rawhide с Гномом.

Odalist ★★★★★
()
Ответ на: комментарий от Deleted

К выживанию никакого отношения не имеет

burato ★★★★★
()
Ответ на: комментарий от popov-aa

заменить maven с его тысячами плагинов

Если для сборки потребовалась не то что тысяча, а хотя бы один плагин (в смысле, к системе сборки, какой бы она ни была), проект надо закопать, пока не настала экологическая катастрофа.

Croco ★★★
()
Ответ на: комментарий от Deleted

Компилируемым… Это зачем для системы сборки ?

Это затем, например, чтобы мне на немейнстримных дистрах не надо было собирать питон.

Я, впрочем, его всё равно собирать не буду. Как следствие, весь софт, который без питона не соберётся (включая, естественно, всё, что на этом вашем meson) — можно рассматривать как несуществующий.

Croco ★★★
()
Ответ на: комментарий от Deleted

Когда-то сложно было себе представить и многопоточное программирование.

Зато сейчас очень хорошо можно представить себе таких интересных «программистов», которые обожают запускать много-много тредов, зато при этом не знают (реально не знают, блин, и таки да, сам таких видел, и много), зачем нужен мьютекс. В смысле, что вот надо обращения к разделяемым данным как-то там обвешивать, это им кто-то сказал, да; но что и как может произойти, если не — этого не знаем, куда там.

Croco ★★★
()
Ответ на: комментарий от anonymous

Какова причина падения качества? Red Hat пытается объять необъятное, поэтому компании не хватает ресурсов для поддержки уровня качества на должном уровне? Или банально желание сэкономить на кадрах?

Желание влезть в каждый трендовый баззворд, куда и перенаправляются ресурсы с дойной коровы (RHEL). Ну и шапку пока IBM не купил, то пытались растянуть матрицу поддерживаемого добра, не наращивая особо количество работников. До смешного ведь доходило с год назад: какая-то шлачная убунта после апдейта работала, а когда-то монументальная шапка - валилась.

Сейчас, говорят, бабки на инфраструктуру и сотрудников активней начали тратить.

Ещё общая для индустрии проблема: хипстеры в кедах поголовно хотят кубернетес на голанге пилить, а заменить вымирающих матёрых кернельщиков некому. Не хотят в сложном говне копаться. Толковая молодёжь приходит, но один приходит, а двое на пенсию уходят или с поехавшей крышей в тундру на укулеле сбегают играть. 200к в год кернельщикам уже на Восточном побережье давать легко начали.

mv ★★★★★
()
Последнее исправление: mv (всего исправлений: 1)
Ответ на: комментарий от Croco

Наверное Pi и прочие ягодные вкусности. Тогда да, удав такое не глотает, живите с миром - удав или хаски Вас не тронут :) сами вымрете или сгниете.

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

Deleted
()
Последнее исправление: Deleted (всего исправлений: 1)
Ответ на: комментарий от Croco

Да и про ламповые машины и уж про релейные те же программисты уже и забыли. Эх ностальгия это штука очень заразна. Не позволяет вынырнуть из безвозвратно ушедших в прошлое технологий в новую реальность и хорошо зарабатывать на хипстерских штучках )

Deleted
()
Последнее исправление: Deleted (всего исправлений: 1)
Ответ на: комментарий от Deleted

Да и про ламповые машины и уж про релейные те же программисты уже и забыли.

Про ламповые машины помнить не обязательно в том смысле, что можно писать более-менее сносный код, не зная, как был устроен триггер на лампах и вообще что такое эта самая лампа (ещё в 2007 году для меня было открытием, что есть такие люди, которые реально не знают, как она выглядит).

А вот если не знать, почему (! именно такой вопрос — «почему») нельзя допускать одновременное обращение к одной области памяти из двух потоков — то многопоточный код такого «программиста» опаснее стада обезьян с контейнером гранат. При этом по моим наблюдениям среди любителей многопоточности такие товарищи преобладают. Люди, которые понимают, что такое race condition, откуда он берётся и к чему приводит, довольно часто от тредов отказываются именно потому, что знают, что это такое.

Croco ★★★
()
Ответ на: комментарий от Croco

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

anonymous
()
Ответ на: комментарий от Croco

ахаха. они не знают, они думают, что по-умолчанию питон везде установлен. ещё ниндзю собери к питону, а потом они ещё что-нибудь придумают.

anonymous
()
Ответ на: комментарий от Deleted

И это фича, а не баг, сколько можно. Просто так подменять либы в пределах минорной версии и уповать на всевышнего — рецепт половины проблем, которые Nix призван искоренять как класс.

Насчет nix - может это взлетит лет через 20.

Я ставлю на то, что взлетит лишь что-то им вдохновленное.

t184256 ★★★★★
()
Ответ на: комментарий от router

Я процитировал то, на что тебе возразил. Так проприетарный нарушает GPL, или ты таки не пробовал получить сорцы?

mogwai ★★★★
()
Ответ на: комментарий от t184256

И это фича, а не баг, сколько можно. Просто так подменять либы в пределах минорной версии и уповать на всевышнего — рецепт половины проблем, которые Nix призван искоренять как класс.

Ты не понял схему. На схеме сборка и деплой - два раздельных шага, контроллируемые разными чек-суммами. А в никсе - один шаг.

Deleted
()
Ответ на: комментарий от t184256

«ненужно» - сильный аргумент, классика =)

Не упрощай до абсурда. За любым «нужно» стоят свои трейдоффы.

Deleted
()
Ответ на: комментарий от Deleted

А в никсе - один шаг.

Упс это как ? Хм. Собираю пакеты в кожи, деплою через ансибле. Это что один шаг ? Или Вы не про линукс ?

mx__ ★★★★★
() автор топика
Ответ на: комментарий от mx__

Я про контроль целостности.

Вы можете собрать application с хидерами от libblabla-1.0.0, а задеплоить с бинарником от libblabla-1.0.1, libblabla-1.1.0, libblabla-1.2.10...

Два разных шага: с чем собираем, и с чем линкуем в рантайме.

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

В идеале, nix должен разделять build environment и run-time environment и контроллировать их отдельно.

При сборке мы получаем производный артефакт «application собранный с хидерами от libblabla-1.0.0», который должен контроллироваться отдельно как от обоих исходников, так и от не связанного с ним артефакта «бинарник libblabla». Это контроль сборки.

А контроль run-time environment в свою очередь даёт гарантию, что задеплоено будет ровно то, что побитово совпадает с задуманным. А вот что именно задумано, т.е. конфигурация, - это должен решить человек.

Из-за того, что nix смешивает роли системы сборки и системы доставки, обе вещи он реализует хуже, чем мог бы.

Deleted
()
Последнее исправление: Deleted (всего исправлений: 4)
Ответ на: комментарий от Deleted

я не знаю ничего про никс (и не особо интересуюсь), но это не абсурд и побитовая воспроизводимость не оверкилл. это основа нормального QA и безбажной работы много-много лет.

crypt ★★★★★
()
Ответ на: комментарий от Deleted

Чем оно лучше CMake? P.S. Унификация систем сборки - это хорошо, в отличие от systemd. Потому что если бы мне в Gentoo не хваталл чего либо (как, например, amdvlk) - я бы мог легко написать ебилд.

Meyer ★★★★★
()
Ответ на: комментарий от Meyer

Тем, что сценарии сборки получаются тривиальными читабельными и намного компактнее, оттого meson.build и прятягивает

А Cmake от Autotools не далеко ушел в плане повышения читабельности сценария сборки

Видится возможным и вовсе заменить .ebuild на .meson для нового portage Gentoo.

Deleted
()
Ответ на: комментарий от Deleted

В идеале, nix должен разделять build environment и run-time environment и контроллировать их отдельно.

Ага. В спеке build-reqired и просто required это отдельные позиции.

Хотя сейчас с наступлением flatpack и подобного несколько все меняется.

mx__ ★★★★★
() автор топика

Dimez

Ну и зачем?

Чтобы не уйти совсем уж истеричкой. Решение было совсем другими причинами. Более глобальными. Мелкая грызня это не повод удалять акк. Так что тут скорее тяга во внутреннюю Монголию.

anonymous
()
Ответ на: комментарий от Shaman007

SL был создан в первую очередь для того, чтобы соответствовать процедурам и нуждам CERN.

Интересно, в чём было несоответствие, из-за которого решили сделать целый дистрибутив?

bbk123 ★★★★★
()
Ответ на: комментарий от Deleted

читаю и дальше третьего про какие-то артефакты, разделение контроля сборки и пр. и выше даже почитал (там где «ненужно»)...

crypt ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.