Выпущен комплект Информика 6.0 Школьный

Старейшие дистрибутивы? Нет, по определению велосипеда.

Они - те же велосипеды, только более старые. И, кстати, не болльно-то старее ALT: ему тоже больше десятка лет уже.

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

Либо устранение одной из давних проблем опенсорса. Да-да, устранения, и именно силами одного из дистрибутивов (или нескольких). Во-первых сейчас уже не те времена, когда вам будут благодарны просто за сборку 1000 или 10000 программ «As is». Качество репозиториев в debian/opensuse/ubuntu должно быть выше за счёт тестирования огромным сообществом/огромной доли среди линуксов/rpmlint соответственно, и фраза «УМВР» от альтовца ничего не изменит - в опенсорсе всегда у кого-то что-то в состоянии УМВР. И теперь от дистрибутивов ожидается совсем другое - они должны руководить опенсорсом, быть фильтром между тысячами групп разработчиков и честолюбивых фирм (со своими тараканами в голове) и людьми (зачастую теми же) которые в итоге пользуются цельной системой, вот за такое и правда могут быть благодарны, и даже очень - если судить по продажам iPhone/iPad/etc. и по тому факту, что Apple недавно превзошла исторический максимум капитализации Microsoft.

В общем, сейчас многие в том числе на ЛОРе приходят к мысли - задача дистрибутива состоит не в сборке своего репозитория. И в этом, наверное, причина срачей в темах про Росу и Альт (и Calculate, и Fuduntu) - обязательно спросят про решение исторических проблем опенсорса (завуалировано), обязательно найдётся в команде Росы/Альта хотя бы один дооолгий человек, который до сих пор видит идеалом дистрибутива дворовый репозиторий с пакетами в состоянии «As is», и понеслась.

Теперь насчёт проблемы бинарной совместимости. Она - выдуманная. В ядре совместимость хранится почти везде, кроме внутренних API (которые можно ломать за счёт GPL'ной природы большинства драйверов) и файлов в /proc (стоить API на строках вообще смешная идея, так что язык Tcl и procfs - отстой). В оффтопике - хранится годами. В solaris - хранится десяток лет. В OpenGL - хранится.

Одна из причин, по которой ABI в линуксе постоянно ломается, состоит в разобщённости и безнаказанной упоротости некоторых групп разработчиков или тщеславных фирм. Раз в пять лет очередному непризнанному гению-библиотекарю приходит в голову светлая идея поломать API/ABI во имя добра в отдельно взятом проекте. Зачастую о линуксе он вообще не думает, сидя под виндой. Библиотек - много, документировать и анонсировать поломки API/ABI не принято (ну правильно, это всё равно что детскую неожиданность радостно анонсировать), и возникает несогласованность. 1000 библиотек -> ABI ломается раз в неделю.

И тут появляется Убунту, и говорит - «я не будут использовать Nautilus 3.6, потому что он сломан, а оправдываться, что это не баг, а фича, можете перед стенкой». Аналогичных действий ждут от других, от Альта и РОСы в том числе. Да что там, ещё в 2003 году гном начал выпускаться раз в полгода сам (март/сентябрь) и другим советовать. Ubuntu послушалась. Остальные показали всю премудрость пескаря из сказки Щедрина.

Я к ООО ALT Linux никаким боком не отношусь

Хм, не заметил. Впрочем, не важно - я выступал против вашего мнения, а не против вас или Альта.

С точки зрения дистрибутивостроения - не велосипеды. И старше альта. Особенно «нового», на мандриве не основанного.

Пакеты, в рамках одного репозитария, собираются с набором библиотек из него же.

Debian unstable - это фактически rolling release.

Качество репозиториев в debian/opensuse/ubuntu должно быть выше за счёт тестирования
огромным сообществом/огромной доли среди линуксов/rpmlint соответственно

А по факту, зачастую, ниже, так как система сборки и тестирования в ALT реально круче. И тому есть неоднократные примеры. Самый главный пример: при подготовке пакета сильно сложнее пройти сборочные тесты, чем в том же Red Hat.
Просто вот нужен отсутствующий пакет, берёшь его откуда нибудь, пишешь спек по аналогии и... болт. А в том репозитарии он болтается. Про Debian не скажу, всё же, так как проще из чужих rpm-ок адаптацией заниматься, а не из deb.

и фраза «УМВР»

Ну так вы же голосновно. Почему я не могу ?

который до сих пор видит идеалом дистрибутива дворовый репозиторий с пакетами в состоянии «As is», и понеслась.

Я не знаю, с чего Вы решили, что репозитарий ALT - это as is. А вот последствия попыток добавить пакеты в репозитарий ALT - это куча патчей в апстримы.

и фраза «УМВР»

Ну так вы же голосновно. Почему я не могу ?

И мой «УМВР», кстати, это «УМВР» от представителя ИСП. На всякий случай... Пусть и небольшого. То есть, и по поводу Open VZ «УМВР», и по поводу почтовых и веб-сервисов/хостингов «УМВР». И, даже, немножко по поводу динамической маршрутизации (ospf/bgp) «УМВР», хотя маршрутизаторов-железок, несколько больше.

Удивление, что внедряет свой велосипед в условиях хронической и тотальной нехватки ресурсов.

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

Безусловно, «должны процветать сто школ» ради изменчивости и прогресса. Но при этом нужно быть готовым к ожидаемым издержкам. Если хотите железной рукой всех загнать на один дистрибутив, то не придумано никакого способа вернуть человека в реальность, кроме как попросить его организационно доказать обоснованность и жизнеспособность такого взгляда. Иначе это просто подсчёт чужих курей у соседа и сетования на несправедливость мира.

В общем, сейчас многие в том числе на ЛОРе приходят к мысли - задача дистрибутива состоит не в сборке своего репозитория. И в этом, наверное, причина срачей в темах про Росу и Альт (и Calculate, и Fuduntu) - обязательно спросят про решение исторических проблем опенсорса (завуалировано)

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

Одна из причин, по которой ABI в линуксе постоянно ломается, состоит в разобщённости и безнаказанной упоротости некоторых групп разработчиков или тщеславных фирм.

Инженеры не плачутся, а решают задачи, какие бы сложные они не были. Смена сонеймов уже стала обычной практикой и удивительно ожидать от динамичного и гетерогенного мира СПО величественного застоя Windows. Конечно, можно оставить ABI в рамках дистрибутва в неприкосновенности. Но это будет весьма затратно, если хотите поддерживать исправления и оправдано только при значительном финансировании. Основная масса пользователей предпочтём новые версии ПО вместо незыблемости ABI. Собственно, в начале этого топика это и озвучивалось.

А по факту, зачастую, ниже, так как система сборки и тестирования в ALT реально круче.

Объясните тогда вот это: Выпущен комплект Информика 6.0 Школьный (комментарий)

А по факту, зачастую, ниже, так как система сборки и тестирования в ALT реально круче.

Объясните тогда вот это: Выпущен комплект Информика 6.0 Школьный (комментарий)

Если бы Вы владели ситуацией, то понимали бы, что это никаким боком не относится к качеству репозитария, например, к отсутствию избыточных зависимостей и качеству сборки пакетов. Это относится к качеству сборки дистрибутива на базе репозитария, а это совсем другой момент.

дак о системе сборки пакета же речь :) А тут не то

Про Debian не скажу, всё же, так как проще из чужих rpm-ок адаптацией заниматься, а не из deb.

Хотя нет, про Debian скажу тоже. Либо в Debian всё так же плохо, как в RH и SuSe с тестированием в процессе сборки, либо дебиановцы зажимают корректирующие патчи и не отдают их в апстирм. Если бы отдавали, не было бы так плохо в RH/SuSe.

Это относится к качеству сборки дистрибутива

В случае rolling release нет какого понятия, как сборка дистрибутива, и эта ошибка относится уже к качеству репозитария.

к отсутствию избыточных зависимостей

В Debian зависимости тестируются более тщательно уже потому, что используются мягкие зависимости, которые поддерживать гораздо более сложно.

качеству сборки пакетов

А что такое качество сборки пакета и почему не учитывается качество всего пакета?

В случае rolling release нет какого понятия, как сборка дистрибутива, и эта ошибка относится уже к качеству репозитария.

При чём тут rolling release ? Вы читали, что в Выпущен комплект Информика 6.0 Школьный (комментарий) написано ? Там просто не оказалось пакета, на который ссылается какой-то там конфигуратор/установщик пакетов/разное.

В Debian зависимости тестируются более тщательно уже потому, что
используются мягкие зависимости, которые поддерживать гораздо более сложно.

Согласен. Но обратный эффект - они могут быть хуже в итоге. Так что, тут место для спора. ;-)

А что такое качество сборки пакета и почему не учитывается качество всего пакета?

Что значит «всего пакета» ? Понятие «качество сборки пакета», по Вашему, не есть качество всего пакета ? Это как так ? А что это такое - это и правильная линковка, и правильные стартовые скрипты, если необходимо, и правильные десктоп-файлы, если надо, иконки в нужных местах и т.п. И правильно проставленные зависимости, в том числе. В ALT, кстати, зависимости, как правило, не проставляют - это делает сборочный робот, а он значительно реже ошибается, чем человек. Хотя возможность помочь ему руками остаётся.

В случае rolling release нет какого понятия, как сборка дистрибутива, и эта ошибка относится уже к качеству репозитария.

При чём тут rolling release ? Вы читали, что в Выпущен комплект Информика 6.0 Школьный (комментарий) написано ?
Там просто не оказалось пакета, на который ссылается какой-то там конфигуратор/установщик пакетов/разное.

Хотя... Имеет смысл разобраться. Вообще, если нечто используется хотябы в каких-то скриптах внутри пакета, зависимость проставляется. В общем, посмотреть стоит, где именно упоминался gksu, и выполняются ли соответствующий поиск зависимостей для этого класса объектов. Может и баг поймался, всякое бывает.

Там просто не оказалось пакета, на который ссылается какой-то там конфигуратор/установщик пакетов/разное.

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

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

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

Но обратный эффект - они могут быть хуже в итоге.

Главное - будет ли это «хуже» самым слабым звеном, или нет.

Это очевидно. Потому что в этом случае имеет контроль над сборочной средой.

OBS можно развернуть на своём сервачке, так что мимо.

Это очевидно. Потому что в этом случае имеет контроль над сборочной средой.

OBS можно развернуть на своём сервачке, так что мимо.

hasher существует на много дольше OBS.

Инженеры не плачутся, а решают задачи, какие бы сложные они не были. Смена сонеймов уже стала обычной практикой и удивительно ожидать от динамичного и гетерогенного мира СПО величественного застоя Windows

Инженеры не плачутся, инженеры решают задачи - ваша правда. Инженеры сделали в Objective C категории, чтобы существующие классы можно было расширять новыми методами. Инженеры написали в knowledge base проекта KDE сводку о том, какие именно изменения ломают ABI в C++, какие не ломают, а где имеется неопределённое поведение. Инженеры задумали систему расширений OpenGL и статически компилируемые фреймворки, которые на самом деле используют стабильный API, но избавляют программиста от личного копания в нём; но некоторые до сих пор думают, что обращаться прямо к иксам или прямо к OpenGL - это круто.

Авторы дистрибутивов плачутся, что бинарная совместимость не нужна. А ещё я только что обнаружил, что в OpenSUSE у многих библиотек пакет lib{name}-static отсутствует, а в lib{name}-devel статические библиотеки (файлы lib*.la) удаляются явным вызовом rm. А у вас в сизифе как дела обстоят?

hasher существует на много дольше OBS.

Слакварь существует много дольше альта

Там просто не оказалось пакета, на который ссылается какой-то там конфигуратор/установщик пакетов/разное.

Не оказалось пакета в сборке, а не в репозитарии.

В сборке, простите, чего ? Пакета ? Или таки дистрибутива ?

Роботом, я так понимаю, это не отловишь,

Отнюдь. Робот это ловит во многих местах. В init и прочих скриптах, в конфигах для крона, например, и т.п. Потому я и написал, что, наверное, стоит разобраться, что это было, и как прошло мимо робота.

И контроль апстрима на предмет исправления ошибок, если найдутся.

Это, разумеется, делается. Если апстрим вменяемый. Всегда предпочтительнее загнать патч в апстрим, чем таскать в пакете и править наложение в следующей версии. Как раз, из-за недостатка ресурсов в том числе.

Слакварь существует много дольше альта

Давайте, теперь, за основу Слакварь брать. Только же что речь про Debian была ? :-)

Так, всё же, давайте определимся, где тот самый лучший репозитарий, на основе которого всё надо делать ? Я тут уже спрослил, где, но анонимус проигнорировал.

А ещё я только что обнаружил, что в OpenSUSE у многих библиотек пакет lib{name}-static отсутствует,
а в lib{name}-devel статические библиотеки (файлы lib*.la) удаляются явным вызовом rm. А у вас в сизифе как дела обстоят?

Аналогично, причём сделано это было на много раньше, чем у всех остальных.

Речь шла о системе сборки. Не понравились репозитории дебиана - давай фигачить свой. А как со системой сборки, так «hasher существует много дольше», такое лицемерие.

А какая вообще разница, кто там существует больше? OBS имеет XML-ный API и плагины к Eclipse, QtCreator (неофициальный), признан Linux Foundation (будет включён в linux developer network, т.е. является единственным и официально рекомендуемым инструментом), поддерживает кучу дистров и добавление новых, его можно развернуть на своих серверах.

Hasher не несёт вообще ничего нового и тем более ничего полезного.

Молодцы. Теперь буду рекомендовать всем не использовать альт для разработки, потому что в нём невозможно скомпилировать библиотеку статически - я имею ввиду для нормального человека, который не будет сам ручками пересобирать 100 библиотек. Зато 100 КБ у разработчика экономятся.

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

Программу конечно же, очепятка

В сборке, простите, чего ? Пакета ?

Не оказалось пакета в сборке пакета?

Робот это ловит во многих местах.

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

Это, разумеется, делается.

Это делается сопровождающим. Чем больше у него пакетов, тем труднее ему придётся при решении этой проблемы.

Теперь буду рекомендовать всем не использовать альт для разработки, потому что в нём невозможно скомпилировать библиотеку статически

А кому нужны разработчики, которые предпочитают статическую сборку и которые не могут сделать себе пакеты *-static, при том, что во многих спеках оно просто обложено %if_enabled static/%endif, если оно, действительно, необходимо ?

Речь шла о системе сборки. Не понравились репозитории дебиана - давай фигачить
свой. А как со системой сборки, так «hasher существует много дольше», такое лицемерие.

Тут я запутался в Вашей мысли. :-)

В сборке, простите, чего ? Пакета ?

Не оказалось пакета в сборке пакета?

Одно из двух. Или я запутался в анонимусах, или анонимус запутался в том, где проблема. :-)

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

Робот это ловит в описанных местах, ибо нет стандарта по поводу того

Конечно, но наиболее общие места существуют, и их можно уточнять.

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

Ах, да. Это Вы про какой сейчас дистрибутив ? Буду людям пальцем показывать, как не надо репозитарий готовить ? Я правильно Вас понял, что там всё статически собрано ?

А кому нужны разработчики, которые предпочитают статическую сборку

Да вам походу вообще никто не нужен. Но зачем тогда писать новость на ЛОРе? Можно жить в шалашике в лесу и никому не мешать, никого не видеть.

Статическая сборка - наиболее простой способ закинуть простенькую программу на RedHat 4, а передо мной сейчас такая задачка стоит.

Предложение поменять одну строчку в 100 пакетах и пересобрать - просто супер. Как говорил один знакомый маковод, «опять всё у линуксоидов не как у людей».

В хорошем дистрибутиве (которого, видимо, не существует) никто не экономит 100 КБ на пакете -devel, удаляя из него статические библиотеки. Если ментейнер решает, что никому не мешающая часть продукта никому не нужна, он слишком много на себя берёт.

В хорошем дистрибутиве (которого, видимо, не существует) никто не экономит 100 КБ на пакете -devel, удаляя из него статические библиотеки.

Практика такова, что пакеты devel-static, если они просто существуют, имеют свойство просачиваться в сборочную среду (считайте разновидностью закона Мерфи). А заниматься пересборкой 100500 пакетов из-за свежей уязвимости в какой-нибудь libssl ну очень никому не хочется. Потому, со стратегической точки зрения, эти пакеты лучше убрать совсем. А Вы, в вашем частном случае, вполне можете эту проблему решить, при соответствующей квалификации.

Вау, стратегическая точка зрения проскользнула. От неё же Skull чуть выше открестился, мол, о стратегиях на кухне рассуждают, а у нас тут Настоящий (C)(R)^tm Энтерпрайз (C)(R)^tm.

Не хочется проблем с уязвимостями - так проверять следует программы, использующие статическую линковку. Rpmlint на что? В OpenSUSE кстати оный используется (и в OBS), и всё равно проблема есть - видимо не в стратегии дело, а в том же самом, почему конторы не хотят писать под линукс с его 1%.

Вау, стратегическая точка зрения проскользнула. От неё же Skull чуть выше открестился, мол, о стратегиях на кухне рассуждают

Так тут было сказано - сделано. И нет devel-static, кртоме случаев явной и осознанной необходимости.

теперь выясняется, что это таки не относится к сборке пакета, и, как следствие, к репозитарию. То есть, в итоге, это таки относится к дистрибутиву.

К качеству чего относится отсутствие пакета в дистрибутиве по причине отсутствия зависимости - дистрибутива или репозитария?

Конечно, но наиболее общие места существуют, и их можно уточнять.

Дьявол кроется в мелочах, искать его - ручная работа.

OBS можно развернуть на своём сервачке, так что мимо.

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

Авторы дистрибутивов плачутся, что бинарная совместимость не нужна. А ещё я только что обнаружил, что в OpenSUSE у многих библиотек пакет lib{name}-static отсутствует, а в lib{name}-devel статические библиотеки (файлы lib*.la) удаляются явным вызовом rm. А у вас в сизифе как дела обстоят?

Не плачутся, а не считают приоритетным. ALT Linux не исключение — у нас статика также вымарывается.

Давайте, теперь, за основу Слакварь брать. Только же что речь про Debian была ? :-)

Нет, была SUSE. А перед ней был Debian. Не обращай внимания, это просто разрыв шаблона. :)

OBS имеет XML-ный API и плагины к Eclipse, QtCreator (неофициальный), признан Linux Foundation (будет включён в linux developer network, т.е. является единственным и официально рекомендуемым инструментом), поддерживает кучу дистров и добавление новых, его можно развернуть на своих серверах.

Туда всё также нужно созданные вручную src.rpm загружать?

Да вам походу вообще никто не нужен. Но зачем тогда писать новость на ЛОРе?

Что-то у Вас логикой и обобщениями странное происходит. На основании того, что по умолчанию нет статических пакетов Вы делаете вывод, что ALT Linux для пользователя (новость была про дистрибутивы для школ) не нужен. Мне кажется, что это неверный критерий для определения полезности. надо будет раскрыть глаза ребятам из Nvidia, КриптоПро, Panasonic, IBM и Oracle, что они некомптетентны и только целиком статический дистрибутив даст проприетарщикам нормальную платформу. Очевидно, что скорее у вас проблемы с квалификацией сборщика, а не у них.

К качеству чего относится отсутствие пакета в дистрибутиве по причине
отсутствия зависимости - дистрибутива или репозитария ?

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

То есть возможность обновления ключевых библиотек без потери консистентности всего репозитория.

Какое вам дело до консистентности репозитария, если до сих пор вместо метапакетов собираете дистрибутивы? Или я уже могу скачать один дистрибутив, и поставить с помощью него на компьютер любое решение?

Вау, стратегическая точка зрения проскользнула. От неё же Skull чуть выше открестился, мол, о стратегиях на кухне рассуждают, а у нас тут Настоящий (C)(R)^tm Энтерпрайз (C)(R)^tm.

Во-первых, эта точка зрения подтверждена реализацией. В отличие от голословных рассуждений.

Во-вторых, рассматривается инженерный, а не организационный аспект. Здесь Вы опять были невнимательны.

В-третьих, про Enterprise я ничего не говорил. Это выводы, основанные на элементарном здравом смысле.

В-четвёртых, научитесь пользоваться Compose-клавишами. А то читать тяжело. На всякий случай для Вас символы: © ® ™ (целых 2 секунды набирал).

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

Или я уже могу скачать один дистрибутив, и поставить с помощью него на компьютер любое решение?

Здрасте. А я как делаю ? Я вообще дистрибутивами от ООО ALT Linux не пользуюсь. Как правило, я использую минимальный инсталятор, даже без xorg. В данный момент, в качестве него Server Light - лень собирать просто installer.

Хотя нет, чуть-чуть вру. Поставил KDesktop недавно, один раз.

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

Не должна быть зависимость от gksu для установки обновлений? Это как? К тому же что, качество дистрибутива не зависит от качества репозитария?

Не минимальный инсталлятор, а единственный дистрибутив для всего.

К качеству чего относится отсутствие пакета в дистрибутиве по причине отсутствия зависимости - дистрибутива или репозитария?

В ALT Linux оба аспекта контролируются во избежание анметов. То, что gksu не попал в дистрибутив — излишняя самодеятельность автора apt-indicator, который заменил явную зависимость на consolehelper на зависимость xdg-su. А явной зависимости xdg-utils на программы повышения привилегий нет. Тяжёлое наследие FreeDesktop. Подробности: https://bugs.altlinux.org/27246