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

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

https://xkcd.com/927/

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

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

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

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

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

Ну здрасте.

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

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

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

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

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

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

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

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

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

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

Денис Попов, ты?

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

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

вот линукс (Android)

Вот тут смешно

так точно!

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

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

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

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

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

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

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

гы

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

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

https://im0-tub-ru.yandex.net/i?id=c9ee58e44da635dfb727128a7c1cdc5b&n=13&...

никто и не заметит

меня восхищает твоё умение читать только первую часть фразы. почти настоящий Ъ

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

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

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

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

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

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

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

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

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

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

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

только потому, что это модно?

Мода - это потреблядство, если хочешь выжить - будь модным!

Мода - это

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

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

а именно в пользу meson.build

нидождёссси

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Вы можете собрать 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 смешивает роли системы сборки и системы доставки, обе вещи он реализует хуже, чем мог бы.

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

Вы дальше 3-го абзаца не читаете?

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

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

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

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

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

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

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

Dimez

Ну и зачем?

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

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

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

Говорят, что только бюрократия.

Ещё один дистрибутив рипнулся. Скоро 1% пользователей пойдёт на убыль.

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