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)
Ответ на: комментарий от t184256

Вырос из ясель силятор ? и подобрал то, что другими заброшено когда стало понятно что оно тухлое по своей природе :)

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

1979, 2003. Но завирусилась контейнеризация ради воспроизводимости только в 2014, и пока даже сборкой без сети не разродилась.

t184256 ★★★★★
()

Почуяли наступление GnomeOS и осознали свою ненужность.

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

На компьютерах задачки решают.

А кто-то даже иногда и компилирует.

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

А сейчас нейронкой только Вас и любителя nix можно удивить )

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

Go только для веба годен и очень хорошо годен.

Go - ЯП общего назначения. Приложение компилируется в один бинарник, который работает на чем угодно, где есть нужное ABI. Сам Go мне безразличен.

Давайте начнем с того, чтобы базовые компоненты системы заработали, не нужно было тянуть с гитхаба стопицот пакетов зависимостей и компилировать расширения на Си в хрен знает каком окружении хрен знает каким компилятором.

А для экосистемы, построенной на принципах СПО, сборочная система - совершенно точно один из базовых компонентов.

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

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

Вам - возможно.

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

Хер знает что давно уже придумана

    1. ports
    1. portage
    1. nix - интересный функциональный подход, но чисто академический
    1. теперь же очередь за унификацией и заменой .ebuild на .meson
Deleted
()
Ответ на: комментарий от t184256

Но завирусилась контейнеризация ради воспроизводимости только в 2014, и пока даже сборкой без сети не разродилась.

Баззворды какие-то.

Была возможность, кому надо, ей пользовался. Потом докер популяризовал идею, вот и все.

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

Человек хочет что бы автомобиль делался только одним топором, а не кучей специализированного инструмента.

Больше похоже, что человек хочет, чтобы все гайки в автомобиле были одной системы, а не часть метрических, часть дюймовых, часть торксов.

https://www.youtube.com/watch?v=qf5cvn8IxaA

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

не топором, а мультитулом вместо болгарки лома и топора впрочем тоже

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

теперь же очередь за унификацией и заменой .ebuild на .meson

«The Meson language is intentionally not Turing complete, and can therefore not express an arbitrary program. Instead, arbitrary build steps beyond compiling supported languages can be represented as custom targets.»

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

Берете в помощники t184256 и пишите на haskell иделогически правильный meson.haskell.build )

И думаю это будет правильно, но мне пока временно сойдет и meson.python.build

Тем более что python как и perl это неотъемлемые части gentoo.

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

Мое конкретное видение таково. Для ускорения несколько утрирую.

Все популярные пакетные менеджеры — ущербное говно для частичного управления рассыпухой файлов, именуемых ОС. То, что они там что-то отслеживают и что-то могут с этим сделать, суть детский лепет и Слака. Дореволюционные ПМ плавно обрастают костыликами типа подобия воспроизводимой сборки или системами миграции конфигурационных файлов, но это все — сбоку прилепленный пластырь, а не решение. Полноценный ПМ должен управлять системой полностью.

Все популярные системы управления конфигурациями — говно. Декларативные у них только конфиги, в реальности они всего лишь очередные императивные утилитки для потыкивания в разные стороны сразу многих хостов. Прописал «включи апач», задеплоил - сто апачей. Стер «включи апач», задеплоил - все еще сто апачей. Когда твой «декларативный» конфиг по дефолту приводит к зоопарку хостов с неопределенным состоянием, это позор и надувательство. Полноценная СУК должна управлять системой полностью. Что-то подобное может дать контейнеризация, но

Все популярные технологии контейнеризации — говно. Изоляции нет, юзайте VM. Системы инициализации? Юзайте лучше VM. Накой мне тогда ваши чруты на стероидах? «Легкие»? Нет, они не «легкие». Когда они будут занимать на диске только дельту от хостовой системы, вот это будет «легкие». Декларативное описание? Размечтался. Кеширование недетерминированной хрени? Вот этого навалом, да.

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

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

Очень низкое соотношение полученного результата (узконишевый нерасширяемый DSL, без поддержки авторов meson-а устареющий за 5 лет) и технологий под капотом (целый python со всеми своими заморочками).

Тем временем системы *BSD целиком собираются при помощи своего диалекта make - как пример такого же узконишевого DSL, но намного более расширяемого, и не требующего компилировать питон.

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

Была возможность, кому надо, ей пользовался.

Чрут сделать можно было всегда и к воспроизводимости относился примерно никак. Культура дропать и пересоздавать их на каждый чих, которая и принесла современному девопсу псевдовоспроизводимость, зародилась когда Nix уже десяток лет как был.

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

ничего против bsd не имею, тягаю у них сценарии

а вот от nix свежих сценариев сборки не наблюдаю.

ах да, у archlinux свежие aur куда интереснее и свежее чем у bsd.

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

Вот сейчас все брошу и буду переписывать на неизвестном мне языке какое-то ненужно.

Системы сборки пишите хоть на Visual Basic, пока есть рабочие воспроизводимые деривации от них мне глубоко плевать. Есть проблемы поважнее.

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

Gentoo самый удобный мультитул для программиста на данный момент.

Рассмотрены были многие bsd, nixos и другие.

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

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

Согласен. Но как видишь, от «возможности» до «культуры» прошло очень много лет. Быстрее не вышло.

Насчёт Nix - в результате его работы получается фарш в /nix/store, и никто не поручится, что этот фарш работает надежно. Софт не может обратиться к «неправильной» версии пакета? В теории да, а на практике - может, если захочет. Если вы хотите полного контроля, каждый процесс должен быть изолирован в адресном пространстве с точностью до своих зависимостей и обрабатываемых файлов. Пока это нереализуемо в общем случае, но развитие идёт именно туда.

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

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

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

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

The Meson language is intentionally not Turing complete

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

anonymous
()

Унификация и единообразие - очень хорошо для рынка. :)
Новость явно не из разряда «всё пропало».

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

Я установил их routeros на x86 компьютер. Повторю свой вопрос: у тебя есть отказ саппорта микротик предоставить исходники?

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

Я установил их routeros на x86 компьютер

Датычо? Вот это достижение. Повторю вопрос: твой routeros или switchos будет работать на современном сетевом whitebox оборудовании ?

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

до линукскапца далеко так же как анонимусу до тонкоты

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

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

для этого они держали свой репозиторий и ставили свои обои. была заявлена максимальная совместимость.

она означает, что текущий RHEL этим требованиям соответствует и нет нужды тратить силы на свой клон.

безосновательный вывод. новость просто отзначает, что они перестанут этим заниматься.

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

routeros или switchos будет работать на современном сетевом whitebox оборудовании?

Если нуждающиеся в этом перестанут кукарекать, попросят сорцы и допилят драйверы для «современного сетевого whitebox оборудования», то будет.

Мы так и не продвинемся: у тебя есть их роутер и отказ от саппорта предоставить сорцы?

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

Если нуждающиеся в этом перестанут кукарекать, попросят сорцы и допилят драйверы для «современного сетевого whitebox оборудования», то будет.

Я фигею в этом зоопарке. Твой любимый мокротык работает только на своём железе. Ты пытаешься выдать его за современную сетевую ОСь. Ничего не смущает?

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

Месон пока слишком ущербен и не доработан для продакшена. Лет через 5, возможно, достигнет необходимого уровня возможностей, а пока даже мавен его уделывает.

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

Твой любимый мокротык работает только на своём железе

Лютое 4.2. Только у меня сейчас работает несколько инстанций под x86. Микротик к этому оборудованию отношения не имеет.

Я фигею в этом зоопарке

Аналогично. Ладно бы, купил роутер, или оплатил лицензию на routeros, обратился в саппорт, получил отказ, и только тогда возмущался. А так — один умник решил налюбить, мол «я у вас с сайта скачал фирмварь, дайте исходники, жопоэль жи», другой дурак стучался не в указанный в лицензии адрес, а третий побежал кричать о нарушении GPL ссылаясь на первых двух.

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

Лютое 4.2. Только у меня сейчас работает несколько инстанций под x86.

Напомни, где в твоём x86 ASIC'и для обработки трафика? Пионер...

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

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

Идея qbs была идеальной. Разработчик принял несколько сомнительных решений, но их можно откатить.

Кто-бы сделал нечто подобное, но без зависимостей от Qt.

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

Кстати о микротиках. Оно уже научилось нормально работать с udp? А то я слышал, что раньше были проблемы с полноценной поддержкой протокола.

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

Напомни, где в твоём x86 ASIC’и для обработки трафика?

Напомни, где в GPL требование, чтобы оно там было?

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

Ты.

Я не по части простых и дубовых интерпретаторов.

А он практически весь должен быть таким.

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

Уважаемые пользователи репозиториев Russian Fedora, а также RFRemix!

Спасибо за ниформацию.

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

Доморощенные корневые сертификаты для MITM.

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

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

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

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