25 лет команде Альт!

Там по треду было уточнено, что речь не о х86 и даже не об армах.

Это не важно. Номер бага-то где?

Во всём мире принято использовать сокращение «dev» для обозначения разработки - от «development».

И только альтернативно одаренные разрабы поганой альтушки за каким-то деволом используют «devel».

Как результат, это вызывает просто лютую ненависить. Ибо рекомендации из интернетов типа «apt-get install XXX-dev» на поганой альтушке просто не работают! Радость-то какая!

Ты лишь расписался в своей рукопопости.

Во всём мире принято использовать сокращение «dev» для обозначения разработки - от «development».

# ls -l /dev/hands
lrwxrwxrwx 1 root root 12 Jan 01 00:00 /dev/hands -> /dev/ass

Мальчег, вынь руки изжеппы (с)

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

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

Я не копался в потрохах Маков, но и в Винде проги вовсе не целиком в свой каталог ставятся, я много раз сталкивался, что даже при выборе «ставь в d:\nameOfProg», инсталятор что-то пишет в Prorgam Files, а то и в system иль ещё куда, а потом натыкался на окаменевшие остатки этих прог даже после удаления.

И только альтернативно одаренные разрабы поганой федорушки за каким-то деволом используют «devel».

попытка уменьшить объём устанавливаемого

Это было актуально четверть века назад когда место на дисках было дефицитом. Сейчас, когда даже дома у людей встречаются аж терабайтные диски - сомневаюсь что настолько жесткая экономия места на библиотеках так уж актуальна. Если бы была возможность сэкономить время (на обслуживание системы и ловлю глюков) за счет занятия большего места на диске - лично я выбрал бы занять место.

и в Винде проги вовсе не целиком в свой каталог ставятся

Я и не утверждал что винда в этом смысле идеальна. Там тоже проблема свалки библиотек в системном каталоге имеет место быть. Но всё же в целом в виндах разделение разного софта по подкаталогам работает лучше. Если бы это совместить с таким как в линуксе пакетным менеджером - было бы совсем хорошо. А что с библиотеками делать - эта проблема нуждается в тщательном обдумывании и готового решения у меня нет. Всё равно даже в линуксе достаточно регулярно встречается ситуация когда в системе требуется две и даже больше разных версии одной и той же библиотеки.

потом натыкался на окаменевшие остатки этих прог даже после удаления.

Как раз вопросы установки/удалени вполне хорошо решаются существующими пакетными менеджерами. Хуже когда начинаешь плотно закапываться в работу с каким-то крупным софтом - довольно неудобно то что его части раскиданы по всей системе. Это неудобство вылезает сразу как только приходится переходить от «общения» с софтом исключительно через его GUI на уровень работы с отдельными файлами. А при глубоком вникании и активном использовании всех возможностей - это неизбежно. Допустим если мне надо добавить в KiCAD какой-нибудь радиоэлемент о котором он не знает - это возможно сделать только положив нужный файл в определенное место(а то и не один и в разные). Ну не имеет пока что большинство софта пункта в меню «возьми вот эти файлы и положи куда там тебе надо» - ну чтобы я как юзер мог вообще не задумываться где оно их хранит. А пока задумываться приходится. Будь оно не так - не был бы настолько востребован такой класс программ как файловые менеджеры. Пока что увы очень много софта (например компиляторы), которые работают именно с файлами. К примеру, если я пишу прошивку для микроконтроллера и мне нужно что-то сделать с стартовым кодом, который исполняется до main() - то мне надо искать его где-то в дебрях системных каталогов. Да он к установленной на компе системе вообще отношения не имеет - он для микроконтроллера. Так с какого такого он лежит где-то среди системных файлов? А почему линкер для сборки микроконтроллерного кода лежит в том же каталоге где общесистемный линкер? Особенно учитывая что это варианты одного и того же линкера. Это уже никакой экономией места на общих библиотеках не объясняется.

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

рекомендации из интернетов типа «apt-get install XXX-dev» на поганой альтушке просто не работают!

А почему в Альте должны обязательно и дословно работать рекомендации из интернета, написанные для ДРУГИХ дистрибутивов? Дистрибутивов линукса вообще-то довольно много и у них есть какие-то свои традиции и соглашения. Вас же не удивит что в дистрибутиве без systemd не будут работать рекомендации, написанные для дистрибутивов где он используется.

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

Ты лишь расписался в своей рукопопости.

Пожалуй это слишком категоричное утверждение. Это четверть века назад можно было быть специлистом «в линуксе», в смысле - вообще во всём линуксе. Сейчас линукс стал настолько большим, что один человект физически не способен разбираться во всех совершенно разных его тонкостях. К примеру тот кто умеет засунуть линукс в какой-нибудь экзотический SoC - совершенно не обязан например разбираться в вопросах виртуализации и контейнеризации, актуальных для мощных серверов. Ну и наоборот естественно тоже.

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

Весь FHS идёт козе в трещину. Но дело того стоит.

Да, я тоже довольно скептически отношусь к FHS в нынешнем его виде. О чем выше и написал. Но - древняя традиция, увы. Сделать что-то иное - по трудозатратам сравнимо с гугловым андроидом.

Пожалуй это слишком категоричное утверждение.

А утверждение «альтернативно одаренные разрабы поганой альтушки» не слишком?

Вот тебе еще примеры - нужно удалить все пакеты asterisk со звуком, но оставить в формате alaw:

apt purge '~nasterisk-sounds!~nalaw'

Смелый вы человек. Я бы точно не стал рисковать используя удаление по шаблону, а удалял бы каждый отдельно, внимательно отслеживая что именно удаляется. Ибо пакетные менеджеры иногда выдают странные результаты. Вот только что же обсуждали как lua попала в зависимости к asterisk. Представьте что кто-нибудь столь же смелый набрал команду, удаляющую asterisk и все что к нему относится, а оно бы удалило lua, которая может быть нужна для чего-нибудь еще.

При удалении чего-то крупного лично я предпочитаю использовать aptitude в интерактивном режиме - там сразу видно что еще может сломаться. Но это в дебиане, как там с aptitude в Альте - пока не знаю.

Это не очень хороший вариант. Потому что всё что попадёт под этот запрос будет помечено как установленное «вручную».

Справедливо, согласен. Забавно что в Alt и это поломано

Вот насчет «поломано» - я бы как раз и поспорил, именно в этом случае. Ибо не вижу смысла помечать как установленное вручную то что было притащено по зависимостям автоматически. И поведение Альта считаю более логичным чем поведение Дебиана который постоянно пытается «автоматическую» метку снять и потом «забыть» удалить притащенное. Подчищать вручную приходилось многократно. Так что с рассмотрением поведения пакетного менеджера в Альте как бага - я просто не согласен.

Извините что я пришел в Alt избалованный aptitude и apt>=2.0 и испытываю дискомфорт после удобных инструментов

Человеку всегда удобнее то к чему он привык. К достоинствам или недостаткам самого инструмента это имеет довольно косвенное отношение. Например значительная часть линуксоидов (включая меня) буквально жить не может без mc и использует его постоянно. Не скажу за всех, но в моем случае это связано с тем что я в линукс пришел в 95 году из ДОСа. Но есть немало и тех кому mc не нужен, они предпочитаю файловые менеджеры, подобные (в той или иной степени) виндовому «проводнику» - просто потому что пришли из виндов и принесли с собой свои привычки.

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

На Debian/Ubuntu я иногда устанавливаю пакет, а потом помечаю его как «auto»

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

Скорее переделывания зависимости с asterisk-build-hacks на liblua-devel там, где оно используется, c последующим убиранием этого Provides.

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

вероятно, давно устарело

Вылезло-то оно сейчас и версии 0.0.2, а там про удаление версии 0.0.1. Так что вопрос «устарелости» и [не]нужности требует как минимум консультаций с специалистами по asterisk.

Есть архитектуры, скажем так, гораздо более удивительные.

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

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

А мне вот наоборот Альт нравится и я хочу на него переехать после того как якобы «консервативный» Дебиан плюнул мне в душу и бросил поддержку x86-32. В Альте она есть и обещает быть и дальше в обозримом будущем. Но чтобы переехать - мне надо корректно перенести кучу своих сильно кастомизированных настроек чтобы в итоге получить комп, решающий мои задачи не_хуже чем сейчас Дебиан 11, который мне таки полностью устраивает на настоящий момент. Но вполне может настать момент когда придется что-то обновлять/ставить такое чем в этом дебиане нет. А в том который сейчас stable - нет поддержки x86-32 которая мне необходима. Поэтому таки собираюсь заморочиться с попыткой переезда на Альт. А еще мне в Альте нравится форум и багтрекер на РУССКОМ языке, который можно не только читать (это я могу и на английском), но и писать туда, чего я на английском не могу.

25 лет команде Альт!

Много дали, интересно за что.

Cейчас линукс стал настолько большим

А он всегда был «большим».

Разумеется, если речь о его сложности и разнообразии «внутреннего устройства», а не о физическом размере системы...

что один человект физически не способен разбираться во всех совершенно разных его тонкостях

Способен.

Тем более, что профессионалам нет нужды «разбираться»: достаточно обладать суммой знаний, навыков и умений, позволяющих, при возникновении такой необходимости, разобраться а приемлемое время.

К примеру тот кто умеет засунуть линукс в какой-нибудь экзотический SoC - совершенно не обязан например разбираться в вопросах виртуализации и контейнеризации, актуальных для мощных серверов

См. абзац этого моего комментария выше. :)

А он всегда был «большим».

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

Тем более, что профессионалам нет нужды «разбираться»

В этом и беда таких «профессионалов».

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

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

Вообще-то нет

вообще-то да. :)

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

А его не надо «обозревать», достаточно уметь разобраться.

Тем более, что профессионалам нет нужды «разбираться»

В этом и беда таких «профессионалов».

Это не «беда», это преимущество инженера перед «мастером», заучившим определённый объём знаний по конкретной прикладной области.

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

это время для одного отдельно взятого человека стремится к времени оставшейся жизни

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

Я тридцать лет копаюсь во внутренностях линукса но имею четкое ощущение что количество всего мне неизвестного растёт быстрее чем объем моих знаний.

Ну, «копаться» - да, можно и всю жизнь... :)) Это если нет конкретной цели и стремишься «охватить» сразу всё, а не решать и решить конкретные задачи...

Инженер, профессионал - это тот, у кого есть «база»

Вот размер этой «базы» и стал очень сильно больше. Я говорю именно об этом, а конечно не о заучивании каких-то конкретных команд.

Ну, «копаться» - да, можно и всю жизнь… :))

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

Инженер, профессионал - это тот, у кого есть «база»

Вот размер этой «базы» и стал очень сильно больше.

Нисколько.

Теоретические основы остаются всё те же на протяжении десятилетий...

Я говорю именно об этом

А у меня ощущение, что мы говорим о разном...

Так ведь у меня линукс - это любимая компьютерная игрушка. Тридцать лет играю и всё не наигрался

Ну так вот и не надо выдавать сoбственную увлечённость предметом интереса за его, предмета, «сложность»... :)

Вылезло-то оно сейчас

Да просто внимания никто не обращал.

Provides: <name> делается, в основном, для случая переименования пакета (или объединения пакетов), чтобы в других пакетах, где пропадающий пакет используется в Requires/BuildRequires, ничего сразу не переделывать.

То есть какие-то пакеты asterisk имели в спеке «BuildRequires: asterisk-build-hacks», и их не надо было в тот момент ломать. Потом в тех пакетах, со временем, BuildRequires должен был поменяться на что-то вроде liblua-devel, после чего «Provides: asterisk-build-hacks» должен был стать не нужен.

Хотя какие-то нюансы могут и иметь место, надо пакеты подробнее смотреть.

Или, всё же, баг, а реакция не на Provides, что было бы нормально, а на упоминание в спеке в принципе.

Пожалуй это слишком категоричное утверждение.

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

А два: это вот самое обобщение - первый признак рукопопости. И не надо кивать на меня: я-то обобщаю исключительно в ответ и исключительно по основному признаку самой рукопопости. Знания тут оценивать бессмысленно. ;-)

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

В чем причина страха, если пакетный менеджер без ключа -y выведет список удаляемых пакетов и попросит подтверждения?

Ты мой стартовый пост читал?

Не увидел там номеров заявок.

Есть упорные организации, которые категорически не хотят совместимости с Альт. Например, РтМИС. Несколько лет мы пытаемся с ними договорится – бесполезно. Уважаемые читатели могут самостоятельно подумать о причинах такого органического неприятия.

Уважаемые читатели могут самостоятельно подумать о причинах такого органического неприятия.

А зачем «уважаемым читателям» вникать в причины ваших междуусобиц??.. Вопрос риторический. :))

А зачем «уважаемым читателям» вникать в причины ваших междуусобиц?

Sapienti sat. С другими организациями удаётся нормально договорится.

А зачем «уважаемым читателям» вникать в причины ваших междуусобиц??.. Вопрос риторический. :))

Точно такой же риторический вопрос: зачем представителям Базальта общаться с нежелающими вникать? Кому вы нужны-то?

Компания РТ МИС входит в группу компаний ПАО «Ростелеком», вот это поворот!

Компания РТ МИС входит в группу компаний ПАО «Ростелеком», вот это поворот!

Ну так в МИС-е, может быть, уже схватились за голову. :-) От НГ отошли, и схватились... :-)

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

Один раз помню только конфликт: java7 (debian 8) зависит от tzdata-java, а в debian 9 его смержили с пакетом tzdata. В итоге новое tzdata невозможно установить - оно конфликтует со старым tzdata-java. В целом ничего страшного, tzdata от 2018 года и так прекрасно работает, только досаждает строчка от apt о том что оно хотело бы, но не станет обновлять tzdata. dist-upgrade же бы его снёс вместе с джавой, что явно не то что требуется.

Мне почему-то вспоминается что я убирал depends: tzdata-java из deb-метаданных джавы (чтобы безболезненно удалить этот старый tzdata-java), но сейчас посмотрел - оно всё ещё там. Может где-то в другом месте такое делал а не на своём десктопе.

В чем причина страха

В привычке быть предельно осторожным при выполнении «потенциально деструктивных» действий. Это к вообще любой технике относится с которой я взаимодействую. Учили меня так старшие наставники еще в глубоко долинуксовые времена.

выведет список удаляемых пакетов

И шанс не заметить в этой куче что-то важное - весьма велик. Особенно в спешке.

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

Вот именно то что вы описали - я и имел в виду когда говорил что нужны прямые руки. Попробуйте объяснить это среднему пользователю, далёкому от познаний в компьютерных внутренностях. Это примерно как объяснить пользователю пылесоса как поменять щетки в его электродвигателе. Для меня - элементарня операция, для него - что-то совершенно непонятное. Хотя казалось бы пылесосы есть у всех и не первый десяток лет.

Мне почему-то вспоминается что я убирал depends: tzdata-java из deb-метаданных

А теперь поинтересуйтесь многие ли из пользователей deb-based дистрибутивов вообще знают как разобрать пакет на составные части и потом собрать его обратно. Там же архив в достаточно малоизвестном широкой публике формате ar, в котором еще два архива в формате tar. Зачем сделан такой оверинжиниринг с упаковкой и почему нельзя было просто запаковать всё в общеупотребительный zip (и переименовать в deb) - не знаю. Вон, в андроидных apk именно так и сделали.

Компания РТ МИС входит в группу компаний ПАО «Ростелеком», вот это поворот!

Компании, входящие в Ростелеком, достаточно независимы в своей политике и им не приказывают. Это же не Группа Астра.

Ну, денег-то они хотят :-) Все.

Ладно, будем посмотреть.

Теоретические основы остаются всё те же на протяжении десятилетий…

«Теория без практики - мертва, практика без теории - слепа» (С) Суворов

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

И да, я допускаю что в чистой академической науке ситуация иная. Я в академической науке не работал, не знаю.

Вылезло-то оно сейчас

Да просто внимания никто не обращал.

Я немного с другим акцентом это сказал. Выше привели аргумент что этот «hack» якобы удалён десять лет назад. И как он тогда оказался в выводе команды поиска пакетов сейчас?

Очевидно, им нужна собственная уникальность и незаменимость. Как микрософту при Баллмере.

зачем представителям Базальта общаться с нежелающими вникать?

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

Кому вы нужны-то?

Видимо есть кому если за четверть века не обанкротились. Видел статистику что всего лишь пятилетний рубеж переживает менее 1% российских компаний. А тут - 25 лет.

Кому вы нужны-то?

Видимо есть кому если за четверть века не обанкротились.

Вопрос «кому вы нужны» был чуду, у которого бомбит от devel вообще-то. Тут, смотрю, удалять начали.

Выше привели аргумент что этот «hack» якобы удалён десять лет назад. И как он тогда оказался в выводе команды поиска пакетов сейчас?

Я, вроде, все ссыки показал. hack удалён. Без якобы. Но в имеющемся liblua-devel название давно удалённого пакета (того хака) до сих пор фигурирует.

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

У тех бизнесменов все проблемы решены очевидно и вагон времени. Или они вовсе лохотронщики, а не бизнесмены, это тоже вполне себе работает на больших числах.

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

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

Sapienti sat. С другими организациями удаётся нормально договорится.

Понятно. Себя вы, конечно же, к «другим» относите...

А то, что договориться не удаётся именно вам то, разумеется, проблема не ваша... ;D

Видел статистику что всего лишь пятилетний рубеж переживает менее 1% российских компаний

«Видел статистику» © :), что к концу первого года своей «жизни» «доживает» лишь каждый десятый вновь созданный «бизнес» в США, так что такой «падёж», видимо, нормален...

$ apt list '~U~npostgres!~ntimescale'
Вывод списка… Готово

А что он должен сделать?

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

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