Представлен выпуск проекта Aura 4.0.0, развивающего пакетный менеджер для дистрибутива Arch Linux, расширяющий возможности штатного пакетного менеджера Pacman. Проект создан в 2012 году и изначально был нацелен на предоставление средств для сборки пакетов для репозитория AUR (Arch User Repository), применяемого для распространения сторонними разработчиками своих пакетов, не входящих в основные репозитории дистрибутива Arch Linux. Код проекта распространяется под лицензией GPLv3...Подробнее: https://www.opennet.ru/opennews/art.shtml?num=61664
> которая переведена с использования языка Haskell на язык Rustглавное в новости
Смищно. Либа, которую pacman использует, написана на сях, полагаю разработчики aura добились охрененной безопасности за счёт API-шных функций засчёт блока unsafe...
В причинах переписывания нет ни слова про безопасность. Так что пук мимо.
В причинах переписывания нет ни одной причины почему раст. Можно взять кучу языков которые умеют все тоже самое и ещё и более привлекательные.
Ну иди к ним в рассылку и аргументируй. Здесь то чего? Ты не участвуешь в принятии решений и не знаешь.
толсто
Назови хотя бы пять или балабол.
Так если хочешь, чтобы всё собиралось в нативный бандл, перформанс и отсутствие GC, то тут либо ржавый, либо маргинальщина типа Zig. Выбор очевиден, потому что у ржавого крутое комьюнити и экосистема, как-бы злопыхателей не крючило.
>отсутствие GCОчень актуально, для пакетного менеджера. Вот пример проекта на расте: https://way-cooler.org/blog/2020/01/09/way-cooler-post-mortem вначале не смогли реализовать дерево окон без порчи памяти, потом долго превозмогали, потом переписали на си, потом закрылись. А ведь пиши они на другом языке, могли бы и до сих пор жить
В РГГУ про это не рассказывают, но ты знай - доказательство по аналогии не является доказательством.
И? Как это отменяет тот факт, что многие люди с фобией GC без этого GC не могут написать код не портящий память? Было несколько крупных сообщений, когда прогеры на расте портили память. Нельзя ткнуть в первый попавшийся проект на расте, и сказать, что он безопасен по памяти. Отказ от GC оправдан далеко не во всех случаях. Остальные пункты, из списка выше - тоже. А без отказа от GC у раста внезапно появляется куча альтернатив.
Предпоследний абзац как раз именно про это
Какой абзац? В оригинале нет ни слова про безопасность. Может хватит врать?
> В причинах переписывания нет ни одной причины почему раст. Можно взять кучу языков которые умеют все тоже самое и ещё и более привлекательные.Где в этом комментарии слово "безопасность"?
"генерировать изображения с наглядным представлением зависимостей"
Не то чтобы против, но им скоро начнут и комиксы рисовать, про бетмена объясняющего как устроен линукс.
Учитывая, что это неизбежно будет тот ещё хентай, тема, на самом деле, интересная.
целевая аудитория манги с хентаем пишет на сях, а не на расте
> скоро начнут и комиксы рисовать, про бетмена объясняющего как устроен линукс.На каком-нибудь Reddit'е примерно так оно и происходит.
> "генерировать изображения с наглядным представлением зависимостей"
> Не то чтобы против, но им скоро начнут и комиксы рисовать, про бетмена объясняющего как устроен линукс.Ты так говоришь, как-будто это что-то плохое)
У нас тысячи айтишников начинали с "Энциклопедия профессора Фортрана".
У буржуев есть даже "The Manga Guide to Electricity".Так что возможности - это хорошо!
Поворот не туда
> позволила значительно повысить производительностьДа, нужно было продолжать страдать.
Есть нормальные и более производительные языки.
Ну займись. Перепиши на Аду или Ассемблер.
Не отнимайте у разработчиков КолибриОС хлеб, пожалуйста.
Помимо производительности, есть и другие факторы при выборе языка: безопасная работа с памятью, удобство сопровождения кода, наличие богатой экосистемы, отсутствие undefined behavior, и так далее.
Выше анон пишет что безопасности в причинах нет. Этот аноним выдумывает что кому то нужна безопасность при вызове сишных либ. Вы согласуйте методички что-ли.
Разные люди акцентируют внимание на разных преимуществах одного и того же. Удивительно, правда? Если к расту приходят люди с совершенно разными потребностями, значит раст _настолько_ хорош.
Значит вокруг него много хайпа. Вон, js тоже из всех щелей лезет. Мало сделать хороший язык, нужен хайп, хороший язык делать не обязательно. У rust, js, go этот хайп есть, у условного ocaml - нет.
У окамла нет?! Да ты здоров, друже? В начале нулевых этого хайпа в нете было, что уши вяли. А для Эрланга даже реклама по ТВ (!) была! Ну вот хоть немного что ли интересовались бы индустрией, а? Ну стыдно за молодежь просто.
>В начале нулевых этого хайпа в нете было, что уши вяли.Ещё про шестидесятые прошлого столетия вспомни. Откуда я сейчас(или десять лет назад) должен был о нём узнать? На том же хабре о нём с десяток статей(по сравнению с десяками тысяч у других языков). На лоре тоже не густо, в некоторые годы ни одной статьи нет.
>Ну вот хоть немного что ли интересовались бы индустрией, а?В том то и дело, что если для ocaml-а нужно прошерстить кучу статей, желательно по функциональному программированю, то про тот же js/rust/go попробуй не услышать, когда они из каждого утюга. И хайп этих трёх до сих пор даже не думает идти на спад
> Откуда я сейчас(или десять лет назад) должен был о нём узнать?Сейчас уже ни от куда. Хайп закончился, а языки показали свою нишевость и нежизнеспособность.
Теперь они практически никому не нужны. Ну, т.е. проекты на них еще встречаются, даже какие-то новые пишутся, но "о былом величии" можно даже не вспоминать.> про тот же js/rust/go попробуй не услышать, когда они из каждого утюга
JS хайп не нужен. Он стал де-факто стандартом индустрии, нравится вам это или нет. И проектов на нем написано просто немерено.
Go тоже занял свою нишу и получил большое распространение.
У Rust наверное самые слабые позиции, тем не менее, если у него получится закрепиться, то у него тоже все будет хорошо.
>но "о былом величии" можно даже не вспоминать.А где было это былое величие? У этих языков как была своя сфера так и осталась. Вот у делфи или паскаля видно, как они утеряли это величие.
>JS хайп не нужен. Он стал де-факто стандартом индустрии, нравится вам это или нет.Ещё как нужен. Огромное количество языков компилируются в него, и без хайпа смысла использовать именно js нет никакого. Никто и не заметит, как в одном проекте его заменят на elm, в другом на java, в третьем на pure script и так далее. И будет js нужен только как язык хранения собранных артефактов.
>И проектов на нем написано просто немерено.Как написали, так и перепишут. Не впервой написанный код выкидывать.
>Go тоже занял свою нишу и получил большое распространение.Опять же, какая у него ниша? Куда удалось затащить, затащили, куда не удалось - нет. У него нет какой-то киллер фичи, которая была бы принципиально недостижима на других языках. Тот же lxc написан на си, а lxd - на go. Просто по тому, что так получилось.
>JS хайп не нужен. Он стал де-факто стандартом индустрии, нравится вам это или нет.И именно по этому сейчас переписывают на type script, хотя казалось бы компиляция и статическая типизация. А вот и нет, без хайпа даже типизацию выбрать не могут
> А для Эрланга даже реклама по ТВ (!)Что за реклама?
А где был хайп по OCaml? Помню на RSDN был некий reductor, много про него писал. А так же про Haskell и ещё каких-то штук 5 языков с названиями из одной буквы, на которых писал только их автор. Помню там же хайп про C# и MS Singularity - вот это куда больше похоже на нынешнюю ситуацию с Rust.
> которая переведена с использования языка Haskell на язык Rust*Шутка про кровати*, ибо как все правильно написано выше, либа сишная
С чем связана популярность арча?
Лично мне импонирует простота и удобство пакетов. Никакой "дебианизации" с тоннами патчей и миллионами дебхелперов, за которыми теряется здравый смысл; PKGBUILD - это просто bash-скрипт с очевидной структурой и с минимальным вмешательством в оригинальный код. Написать свой - ничего сложного даже без опыта.После опыта с gentoo, который сам по себе хорош, но надоело всё билдить из сорцов - очевидный выбор.
> но надоело всё билдить из сорцов
У меня про Gentoo воспоминания времен, когда у Gentoo ещё версионирование не по годам было. Вроде 1.4 версия была :-)
> PKGBUILD - это просто bash-скриптТы хотел сказать баш-портянка?
Не, портянки - это в debian/rules, а там обычно красиво. Ну от мейнтенера зависит, конечно, при желании везде можно портянку накатать.
Система пакетов лучшая среди меинстрим линуксов. Всего-то простой скрипт в отличие от отбитых деб и рпмов, в котором описывается весь процесс, начиная от скачивания сорцов, заканчивая сборкой и упаковкой. Элементарно несколько пакетов в одном файле описать можно, типа <пакет> и его lib<пакет>.Мой любимый пример: https://github.com/CachyOS/linux-cachyos/blob/master/linux-c...
Как вот это можно описать в дебах и рпмах?
Там Чекинстал был, проще некуда. Примитивизм слакбилдов конечно не переплюнул, но все равно намного поприятнее с ним на Дебиан.
Почему тоже самое в ините вызывает отторжение и необходимость использовать системд?
Потому что это треш. 786 строк, чтобы установить пакет...
786 строк из которых 200 это конфигурация с комментариями, а остальное отведено на сборку _шести_ пакетов. Попытка низачот, до звания кексперта-онанима не дотягивает.
> 786 строк из которых 200 это конфигурация с комментариями, а остальное отведено
> на сборку _шести_ пакетов. Попытка низачот, до звания кексперта-онанима не дотягивает.Спасибо, такую вермишель, я оставлю избранным. Деб и РПМ куда понятней и логичней выглядит.
Когда переходили, давали объяснение:
https://bbs.archlinux.org/viewtopic.php?pid=1149530#p1149530Хотя согласен, это уже не KISS, как было раньше
Глянул скрипт... спасибо, я лучше продолжу Дебы и РПМ собирать. Эта портянка, прекрасный пример линуксового красно глазия.З.Ы. Не отрицаю проблем Деба и РПМ.
Описание нескольких пакетов нормально реализуется в nix, при этом система обновляестся без необходимоси чтения новостей и ручного исправления за пакетным менеджером
Остается надеяться, что это шутка.
> Мой любимый пример: https://github.com/CachyOS/linux-cachyos/blob/master/linux-c...Какое-то непонятное вынул и что ты этим хотел сказать? Скачай исходники deb пакетов и посмотри.
> Всего-то простой скрипт в отличие от отбитых деб и рпмовВ deb простой Makefile
> в котором описывается весь процесс, начиная от скачивания сорцов, заканчивая сборкой и упаковкой.
Не хочешь - не описывай.
> Элементарно несколько пакетов в одном файле описать можно, типа <пакет> и его lib<пакет>.
Из одного source пакеты можно собрать много бинарных и все будет описано в одном Makefile.
- На десктопе ролллинг или семироллинг - оч ок, нечего 2-5 лет сидеть на протухшем kate/pidgin/vim/что-нибудь ещё. Это не касается "базовой системы", но у Линуксов с таким понятием туговато, только вон в соседних новостях кто-то работает над таким. Но есть LTS ядра, так что десктоп - обновляемый, а ядро - стабильное;
- богатая репа;
- если чего-то нет в репе или его нет, а очень надо или хочется, можно взять из AUR; если волнительно, можно почитать сборочный скрипт;P.S. Обновляться каждый день никто не заставляет. Но вот раз в неделю, наверное, уже желательно.
P.P.S. есть "стабилизированный" manjaro, но там кроме публикации пакетов ~ раз в неделю, а не каждый день, ещё и своих конфигов+скриптов+немного автомагии в системе поднакручено, так что считать это чистым арчем и один в один применять его вику кажется уже не получится.
Это у них flatpack'ов со snap'ами не было). Роллинг нужен для 10 _приложений_, а для системы как раз таки lts...
Где-то мы эту модель с "base system" + rolling apps уже видели... Ох, щщщи! Этодругое
Там же либы не переиспользуются и у анона на второй корке кончается оператива.
> Там же либы не переиспользуются и у анона на второй корке кончается
> оператива.Ээээ... где - "там"?
>- На десктопе ролллинг или семироллинг - оч ок, нечего 2-5 лет сидеть на протухшем kate/pidgin/vim/что-нибудь ещё. Это не касается "базовой системы", но у Линуксов с таким понятием туговато, только вон в соседних новостях кто-то работает над таким. Но есть LTS ядра, так что десктоп - обновляемый, а ядро - стабильное;Можно поставить NixOS и сочетать стабильнную и нестабильную версию, без риска сломать систему, в то время как в арче может внезапно прилететь абсолютно любое обновление
>P.S. Обновляться каждый день никто не заставляет. Но вот раз в неделю, наверное, уже желательно.Не обновишся и система развалится. Как и ожидалось от арча.
>P.P.S. есть "стабилизированный" manjaroНе намного стабильнее арча. Тоже может развалится после обновления
> Можно поставить NixOS и сочетать стабильнную и нестабильную версиюНо не нужно. Обычные люди пользуются стабильными версиями программ, как и ожидает от них их разработчик.
Нестабильными версиями пользуются только разработчики, которые их и так собирают/запускают/отлаживают мимо корневой системы, часто в отдельном окружении.> Не обновишся и система развалится. Как и ожидалось от арча.
Дешевый наброс. Если много лет не обновляться, худшее, что может случиться - протухнут ключи. Которые лекго восстанавливаются парой команд, затем штатно обновляется система и актуализируются конфиги (pacdiff). И всё работает.
А вот NixOS умудряется при каждом новом релизе сломать глобальный конфиг, сборку и работу половины программ, ещё и насоздавать кучу дублирующихся, совершенно не нужных, минорных зависимостей.
Не говоря уже о том, что для обновления прожорливому nix может банально оперативки (4ГБ!) не хватить.
>Если много лет не обновляться, худшее, что может случиться - протухнут ключиИли развалятся зависимости. Особенно если не сидеть на базовой системе, а пользоваться разными фичами типа аура. Или ставить пакеты, автор которых решил их переписать, выделив отдельно версию на gtk и qt. Или какой то пакет обновился и в новостях свазали вручную за пакетным менеджерем доделать.
>А вот NixOS умудряется при каждом новом релизе сломать глобальный конфигЧтоб другие системы так же ломались. Во-первых, это происходит не каждый ролиз, в, вторых конфиг не ломается, а не собирается. На современный, арч тоже gnome2 не поставить, только никто это поломкой арча не называет. С учётом того, что явно установленные пакеты перечисляются в конфиге, то и возникает необходимость его править. Во-вторых вторых, в арче эио может в любое обновление случится, нужно регулярно смотреть новости, в то время как в NixOS - только после того, как пользователь решил переключится на н вый релиз.
>Не говоря уже о том, что для обновления прожорливому nix может банально оперативки (4ГБ!) не хватить.Не знаю, не сталкивался. Я ни рзу не видел даже 2 гб использованных nix.
> На современный, арч тоже gnome2 не поставить, только никто это поломкой арча не называет.Gnome2 давно не разрабатывается. Вместо него *везде* используют форки (Mate, Mint) или Xfce. А вот на NixOS через раз ломается свежайшее ПО, которое стабильно работает в других дистрах, почему-то.
> в арче эио может в любое обновление случится, нужно регулярно смотреть новости
В Арче обновление не проходит крайне редко. И исправляется либо со временем само, либо парой команд в консоли. Из-за грядущих больших изменений или ошибок сопроводителей. За десятки лет эксплуатации я в новости заглядывал, по необходимости, от силы пару раз.
RT-поломки отдельных программ и изменения в настройках не блокируют обновление. Причём, первые - большая редкость, исправляемая в течение суток. Последние могут что-то сломать только в очень криво написанном ПО, разработчики которого совершенно не озабочены вопросами совместимости. Тем более, сейчас настройки принято оформлять включениями (drop-in), что существенно уменьшает такие риски. А вот в Nix настройки - это либо совсем отсебятина, либо обёртка-генератор со своими декларациями. Там поломки не искоренимы, как класс. Причем, они блокируют обновление всей системы из-за пары кривых "пакетов".> Я ни рзу не видел даже 2 гб использованных nix.
Подключи больше одного канала. stable и unstable, например.
Недаром в NixOS половина каналов на "-small" заканчивается, проблема немасшатбируемого жора nix очевидна даже разработчикам, но ничего лучше они не придумали.
>А вот на NixOS через раз ломается свежайшее ПО, которое стабильно работает в других дистрах, почему-то.Пример? Желательно не единичный, чтобы это нельзя было списать на кривой софт.
>В Арче обновление не проходит крайне редко. И исправляется либо со временем само, либо парой команд в консоли. Из-за грядущих больших изменений или ошибок сопроводителей. За десятки лет эксплуатации я в новости заглядывал, по необходимости, от силы пару раз.Установлена только базовая ситема, даже браузер во флетпаке? Вот пример: обнивилось DE нужно ручное вмешательство https://archlinux.org/news/budgie-desktop-1072-6-update-requ.../ вот пример с java https://archlinux.org/news/incoming-changes-in-jdk-jre-21-pa.../. Конечно, если ни то, не другое не стоит, то всё легко и простое. Другие примеры лень искать.
>А вот в Nix настройки - это либо совсем отсебятина, либо обёртка-генератор со своими декларациями. Там поломки не искоренимы, как класс. Причем, они блокируют обновление всей системы из-за пары кривых "пакетов".А как система должна реагировать, когда пакет меняется? Да, gnome 2 был давно, но ничего, некоторое время назад gnome 4 вышел, kde 6 совсем недавно. Как система должна реагироватч, когда youtube-dl устарел или редис сменил лицензию? Молча что-то нашаманить? Поломать систему? Оставить уязвимый пакет? Пусть пользователь сам скажет, чего он хочет. Или у пользователя лапки? Ну так удачи такому пользователю с ауром, например, разбраться, или джавой.
>Недаром в NixOS половина каналов на "-small" заканчивается, проблема немасшатбируемого жора nix очевидна даже разработчикамНе нужно придумывать. Вот что говорится в мануале
https://nixos.wiki/wiki/Nix_channels
>Large/small:
>
> Large channels (nixos-24.05, nixos-unstable) provide binary builds for the full breadth of Nixpkgs.
> Small channels (nixos-24.05-small, nixos-unstable-small) are identical to large channels, but contain fewer binaries. This means they update faster, but require more to be built from source.компиляция софта из бинарников к потреблению памяти самим nix отношения не имеет.
> Пример?Очевидно, что страдать с NixOS я давно бросил и актуальных примеров привести не смогу. Но с тех пор фундаментальные концепции построения дистрибутива там не менялись, что могло стать лучше?
> нужно ручное вмешательство
Одна проблема касается только пользователей Budgie. Другая - только разработчиков Java.
Обе сводятся к удалению одного их конфликтующих пакетов, средствами самого же пакетного менеджера, о чем тот сам интерактивно сообщит и нетрудно догадаться, что делать, даже без чтения новостей.
Полностью автоматического, совсем без участия человека, обновления чего угодно пока ещё не придумали. В чем угодно всегда могут возникнуть какие угодно проблемы. К счастью, те проблемы с которыми сталкиваются арчеводы при использовании пакетника весьма незначительны и тривиально разрешимы.> А как система должна реагировать, когда пакет меняется?
Это решает сопроводитель.
Как происходит в Арче, когда невозможно прозрачно перевести пользователя с одного пакета на другой, я уже рассказывал.> компиляция софта из бинарников к потреблению памяти самим nix отношения не имеет
Потребление памяти nix-ом растет с увеличением количества объявлений "пакетов" в одной большой монолитной функции, которую тому нужно вычислить. И остается только сокращать объем деклараций на канале.
>Очевидно, что страдать с NixOS я давно бросил и актуальных примеров привести не смогу.Давай неактуальные примеры. Или предлагаешь верить на слово?
>Одна проблема касается только пользователей Budgie. Другая - только разработчиков Java.Это отменяет факт проблемы? Пакман не может собрать зависимости так, чтобы они не конфликтовали. И конфликт случается даже при испольльзовании официального поддерживаемого репозитория. Если же частично откатывать пакеты, использовать аур, и так далее, то починить будет уже не так просто.
>К счастью, те проблемы с которыми сталкиваются арчеводы при использовании пакетника весьма незначительны и тривиально разрешимы.Хорошо, как поставить две версии одного пакета?
>И остается только сокращать объем деклараций на канале.Я привёл выдержку из мануала, где говорится, что каналы отличаются бинарным кешем. Что тут непонятно?
> Давай неактуальные примеры.flatpak
> Это отменяет факт проблемы?
Не затрагивает новых пользователей. Затрагивает очень узкую прослойку старых.
> Пакман не может собрать зависимости так, чтобы они не конфликтовали.
Pacman ни при чём, он делает лучшее из возможного. Проблема в конкретном ПО или его PKGBUILD'е.
`git rebase` тоже иногда приходится ручками делать из-за ранее принятых неудачных решений или для подчистки легаси.
Общее место. Панацею пока не изобрели.> конфликт случается
И разрешается нажатием Y/N.
> Если же частично откатывать пакеты
Худшее, что случится, придётся вручную доустановить пропущенный пакет (pacman -S pkgname) или удалить лишний (pacman -R pkgname).
> использовать аур
Никак не влияет. В AUR нет пакетов, только скрипты сборки.
> Хорошо, как поставить две версии одного пакета?
Арч официально не поддерживает частичные обновления. На то есть веские причины.
Но кому очень хочется странного, могут завести отдельный корень (см. mkarchroot из пакета devtools и systemd-nspawn). Если у пакета мало зависимостей (чтобы сильно под себя не гадить), можно пересобрать его с другим именем и установить в корень.> Что тут непонятно?
Непонятно, как можно до такой математически-абстрахнутой архитектуры, с немасштабируемым жором памяти, вообще додуматься. Функциональное программирование головного мозга.
>flatpakИ что дальше? Это не пример.
>Pacman ни при чём, он делает лучшее из возможного.И чем решение пакмана лучше решения условного apt-get?
>И разрешается нажатием Y/N.Это один из самых элементарных случаев, возникающих при штатном использовании системы. Существуют способы, как сломать пакетный менеджер, и в интернетах полно тем, как люди просят помочь им разобраться с зависимостями.
>Никак не влияет. В AUR нет пакетов, только скрипты сборки.И? После сборки у пакета как раз появляются зависимости.
>Функциональное программирование головного мозга.Аргументы закончились.
Эта популярность нарисованная. Убунту лидер у 4%.
(https://store.steampowered.com/hwsurvey/?platform=linux)
July 2024
"SteamOS Holo" 64 bit 40.97%
"Arch Linux" 64 bit 7.99%
Freedesktop SDK 23.08 (Flatpak runtime) 64 bit 6.35%
Linux Mint 21.3 64 bit 5.20%
Ubuntu 22.04.4 LTS 64 bit 4.04%
Ubuntu 24.04 LTS 64 bit 3.41%
Ubuntu Core 22 64 bit 2.99%
"Manjaro Linux" 64 bit 2.93%
Pop!_OS 22.04 LTS 64 bit 2.73%
Debian GNU/Linux 12 (bookworm) 64 bit 2.44%
Other 20.96%
SteamOS и Manjaro - на базе Арча, если что.
Стоит задуматься, почему Valve выбросило на мороз Debian с Gnome и перешла на Arch с KDE.
Перед тем как выбрости на мороз, естественно облили всем известной жидкостью.
> Стоит задуматься, почему Valve выбросило на мороз Debian с Gnome и перешла
> на Arch с KDE.KDE то причем? Она использует Стим окружение.
Вопрос конечно интересный, но ответ банальный. Дебиан основан на мега супер пупер стабильных пакетах сто летней давности. В этом есть свои плюсы, но для Стима наверное эти плюсы не существенны и скорей всего даже минус.
А вот почему взяли Арч, я бы хотел узнать от Габена.
Что же, моя инфа возможно устарела хотя ещё не так давно пиратки нативных игр пилились под Убунту.
>[оверквотинг удален]
> "Arch Linux" 64 bit 7.99%
> Freedesktop SDK 23.08 (Flatpak runtime) 64 bit 6.35%
> Linux Mint 21.3 64 bit 5.20%
> Ubuntu 22.04.4 LTS 64 bit 4.04%
> Ubuntu 24.04 LTS 64 bit 3.41%
> Ubuntu Core 22 64 bit 2.99%
> "Manjaro Linux" 64 bit 2.93%
> Pop!_OS 22.04 LTS 64 bit 2.73%
> Debian GNU/Linux 12 (bookworm) 64 bit 2.44%
> Other 20.96%Это статистика не дистрибутивов. А Стима где используется он.
Хотя, разделять убунту на 3 отдельных дистрибутива, хитро. Понимаю зачем это делает СТИМ и не осуждаю.
Но если посчитать
В сумме 10.44%
Вторая по популярности получается.
- простоста
- есть весь софт, в отличие от deb-based, в которых рано или поздно просто тонешь в ppa, которые друг с другом начинают конфликтовать. если какого-то софта нет в репах/в aur, значит, с большой долей вероятности его нет нигде
- обновления на ветке testing выходят раньше, чем прилетают новости о релизах
- ставишь только то, что нужно. не нужно как в убунте три часа гуглить, как же на этой неделе вырубить update notifier. не нужно чистить систему от мусора после установки
- шустрый
Какая там популярность? Дистр как дистр, который имеет свои плюсы и минусы, и который нужен, чтобы расширыть выбор пользователя Линукс, что уже само по себе есть хорошо. Сам я Арчем не пользуюсь, но производные от него мне нравятся
С тем что её использует Valve своей SteamOS.
Для пользователя:* Свежее ПО (rolling release)
* Самый большой охват открытого ПО (AUR)
* Хорошая документация (Arch Wiki)
* Быстрый (с-ка!), гибкий (пользовательские хуки, выборочная распаковка) и универсальный (MSYS2) пакетник (pacman)Для сопроводителя/разработчика:
* Последние версии ПО с минимумом кастомных настроек и патчей
* Легко настраивать, не боясь поломок из-за чужих (кривых) кастомизаций (несоответствие документации, эффект домино)
* Легко совмещать сопровождение пакета ПО с его разработкой в upstream
* Широкое использование в родном инструментарии (PKGBUILD, makepkg, mkinitcpio, pkgctl, aurutils и т.п.) традиционных технологий (bash, coreutils и т.п.), знакомых админам
* Простота пакетирования и дистрибуции (AUR): прочитал вику, завел аккаунт, сгенерировал пару ключей, и никакой бюрократии
Аур без всякой проверки, туда могут залить зловред. Поддержку пакета могут в любой момент забросоть. Из-за ролинг релиза обновления пакетов прилетают внезапно, как например новые версии гнома.
> Аур без всякой проверкиТысяча глаз.
> туда могут залить зловред
А могут и что-нибудь полезное. Волков бояться, в лес не ходить.
> Поддержку пакета могут в любой момент забросоть.
Как в любом дистре. В Дебиане нормально, когда твой любимый блокнот (привет, Cherrytree) выкидывают при обновлении, потому что у него неправильная версия Python, Gtk, Qt и т.п. И чем ты будешь открывать свои заметки никого не волнует.
В Арче такой пакет (и зависимости) не исчезает из локальной системы при обновлении, а его PKGBUILD переносится в AUR на общественное обслуживание. Где его в любой момент могут подхватить заинтересованные. Совсем заброшенные PKGBUILDы периодически подчищают.> обновления пакетов прилетают внезапно
.. по команде из консоли. Надуманная проблема. Не обновляйся, сиди на старых. Обновился по ошибке? Откатись на "Server = https://archive.archlinux.org/repos/2024/08/05/$repo/os/$arch".
>Тысяча глаз.Сколько разных контор linux проверяет и что? Уязвимости порой с десятилетней выдержкой. Rust начали делать, но вт провеку выхода за границы массива не осилили.
>Как в любом дистре. В Дебиане нормально, когда твой любимый блокнот (привет, Cherrytree) выкидывают при обновлении, потому что у него неправильная версия Python, Gtk, Qt и т.п. И чем ты будешь открывать свои заметки никого не волнует.Дебиан знаменит проблемами с пакетами, в то время как аур активно рекламируют.
>.. по команде из консоли. Надуманная проблема.Хорошо, когда компьютер только для развлечения: какая разница фильм смотреть или пакеты обновлять. И другое дело, когда на нём работаешь и не хочешь, чтобы там внезапно gnome/kde/wm обновился.
> Уязвимости порой с десятилетней выдержкой.Сколько таких "выдержанных" уязвимостей реально эксплуатируется? Не нашёл тысячеглаз, не нашёл и злокакир.
> провеку выхода за границы массива не осилили
Я из-за отсутствия проверок не страдаю. У меня, наоборот, всё быстрее работает, меньше ветвлений в коде, меньше счета за электричество.
А кто страдает, так ему и надо, бypжую. Легко пришло, легко ушло.> Дебиан знаменит проблемами с пакетами, в то время как аур активно рекламируют.
AUR в рекламе не нуждается. Первый в списке "By number of maintainers" на https://repology.org/.
> не хочешь, чтобы там внезапно gnome/kde/wm обновилсяНе хочешь, не обновляешь.
>Сколько таких "выдержанных" уязвимостей реально эксплуатируется? Не нашёл тысячеглаз, не нашёл и злокакир.Хорошо быть неуловимым Джо. Что же все так резко из-за xz всполошились?
>Я из-за отсутствия проверок не страдаю. У меня, наоборот, всё быстрее работает, меньше ветвлений в коде, меньше счета за электричество.О зависимых типах, исключающих данный класс проблем на этапе компиляции вы , полагаю, не слышали.
>AUR в рекламе не нуждается. Первый в списке "By number of maintainers" на https://repology.org/.А толку с количества? Пришёл, пакет собрал и ушёл - вот плюс один мейнтер. Ради интереса поискал, вот https://aur.archlinux.org/packages/ungoogled-chromium-git 88 версии. Сколько ему уже лет? Неуж-то три года? Вот и подключай пакет из аура, а потом самостоятельно остслеживай его актуальность.
> Что же все так резко из-за xz всполошились?Кто всполошился? Кому непофиг, давно на zstd перешли.
> (https://archlinux.org/news/now-using-zstandard-instead-of-xz.../)
> As announced on the mailing list, on Friday, Dec 27 2019, our package compression scheme has changed from xz (.pkg.tar.xz) to zstd (.pkg.tar.zst).
> ... на этапе компиляции ...Теории. На практике находится тысяча причин, почему вот этот кусок кода либо нельзя оптимизировать, либо можно, но на свой страх и риск, со всеми /про/текающими.
В итоге обещания остаются на бумаге. А моё время, затраченное на обучение новой модной технологии, мне никто не вернет.> https://aur.archlinux.org/packages/ungoogled-chromium-git
*-git пакеты не для каждого. Для тех, кто понимает что делает. И у них свои приколы с обновлением и отслеживанием версии.
Вот правильная ссылка: https://aur.archlinux.org/packages/ungoogled-chromium
>Кто всполошился? Кому непофиг, давно на zstd перешли.Речь про встроенный бекдор, а не сжатие по умолчанию.
>А моё время, затраченное на обучение новой модной технологии, мне никто не вернет.Речь шла о проверка выхода за границы массива, а не о сжатии.
>*-git пакеты не для каждого. Для тех, кто понимает что делает.https://aur.archlinux.org/packages/chromium-dev https://aur.archlinux.org/packages/ungoogled-chromium-xdg ещё пара пакетов. Я когда-то давно собирал chromium с vaapi, тогда я впервые заметил, что есть несколько почти одинаковых пакетов, различающихся актуальностью. Сейчас дела обстоят практически так же.
> Речь про встроенный бекдор, а не сжатие по умолчанию.Попытка внедрения бэкдора, на подготовку которой ушло несколько лет, а вскрылась она сразу на этапе внедрения.
В kernel, systemd, pacman поддерживается zstd. Друuие архиваторы выкидывают из обязательных зависимостей (https://systemd.io/ELF_DLOPEN_METADATA/).> Речь шла о проверка выхода за границы массива, а не о сжатии.
Так я о проверках и сопутствующих оптимизация и говорил.
Ну не вижу смысла учить Rust: слишком перемудрен (навязывает экспериментальную парадигму, не опирающуюся на теорию), слишком много обещаний (про CT-оптимизации проверок, в том числе) - слишком мало из них выполняется, решает какие-то надуманные проблемы, попутно создавая вполне реальные.
Может, Zig я бы ещё шанс дал: простой и адекватный синтаксис (не ломающий привычные парадигмы), хороший C-interop (вместо переписывания всего на Go/Rust/YetAnotherEEECorpNewLang), естественный comptime (а не легаси-уродец, как в С++), передача аллокаторов и типизированная обработка ошибок (вместо нужды шерстить доки к Си-либам на предмет, кто должен выделять/освобождать память и как интерпретировать коды возврата).
> Сейчас дела обстоят практически так же.Ну, если хорошенько поискать всегда можно найти какую-нибудь грязь в тёмных закутках. AUR - пользовательский репозиторий, гарантий качества не даёт. Если что-то сделано плохо, сделать лучше перекладывается на конечного пользователя. Но ведь всегда проще за кем-то немного доделать, чем начинать с чистого листа?
>Попытка внедрения бэкдора, на подготовку которой ушло несколько лет, а вскрылась она сразу на этапе внедрения.Настолько быстро вскрылась, что в нескольких дистрибутивах её опакетили в официальные репозитории
>Ну не вижу смысла учить Rust: слишком перемудрен (навязывает экспериментальную парадигму, не опирающуюся на теорию)Значит про линейные и афинные типы вы не слышали. Печально.
>Может, Zig я бы ещё шанс дал: простой и адекватный синтаксис (не ломающий привычные парадигмы),Уровень познания языка: критика синтаксиса. У раста мог бы быть нормальный синтаксис, не будь он испорчен наследние си и плюсов. Но синтаксис - едва ли не последняя часть, на которую стоит обращать внимание.
>AUR - пользовательский репозиторий, гарантий качества не даёт.Печально, что в начале его рекламируют, а потом, спустя время это признают.
>Если что-то сделано плохо, сделать лучше перекладывается на конечного пользователя. Но ведь всегда проще за кем-то немного доделать, чем начинать с чистого листа?Увы, но некоторые вещи на баше попросту невыразимы. В частности, nix позволяет опакетить что-то, а потом, на основе этого пакета собрать то же самое, но с musl вместо glibc, i686 вместо x64 и так далее. Возможность пользоваться уже собранным для другой системы пакетом подкупает ещё больше. В то время как содержать пакет в ауре, не совпадающий с релизным циклом арча будет крайне тяжело.
А вообще, если включить сортировку по дате обновления, то там куча пакетов начиная от 2015 года. Repology странно считает - пишет что всего 74734, а актуальных 23367 - 74.05%, в то время как это даже не половина.
> Для пользователя:
> * Свежее ПО (rolling release)Сомнительный плюс. Даже скорей минус.
> * Самый большой охват открытого ПО (AUR)Плюс однозначный. Но проблема софтом на других дистрах, я както не замечал. Арчу плюс, но маленький. Сомнительный такой.
> * Хорошая документация (Arch Wiki)Плюс. Хорошая документация всегда хорошо.
> * Быстрый (с-ка!), гибкий (пользовательские хуки, выборочная распаковка) и универсальный
> (MSYS2) пакетник (pacman)Пользователю вообще на это нагадить. Для пользователя ты написал набор звуков.
> Для сопроводителя/разработчика:
> * Последние версии ПО с минимумом кастомных настроек и патчейМинус, а не плюс. Разработчики чего? Разрабы тоже хотят спокойно работать.
> * Легко настраивать, не боясь поломок из-за чужих (кривых) кастомизаций
> (несоответствие документации, эффект домино)Это плюс только для новичков в линуксе. В первые пару лет играешься, а потом ставишь весь дефолт, максимум доводишь систему до удобных настроек. Обычно это небольшой список настроек. С каждым годом он только уменьшается. Ибо, как оно за... устаешь вечно настраивать. Хочется пользоваться, а не пердолингом заниматься. Так что скорей минус.
> * Легко совмещать сопровождение пакета ПО с его разработкой в
> upstreamСмотря для кого. За всех не расписывайся.
> * Широкое использование в родном инструментарии (PKGBUILD, makepkg, mkinitcpio, pkgctl,
> aurutils и т.п.) традиционных технологий (bash, coreutils и т.п.), знакомых админамМинус. Слишком много пердолинга для 24 года.
> * Простота пакетирования и дистрибуции (AUR): прочитал вику, завел аккаунт, сгенерировал
> пару ключей, и никакой бюрократииВидел я ваши портянки для пакетирования, назвать это удобно, язык не повернется. Куда удобней Дебпакет запаковать. А учитывая автоматизацию, то вообще в чем вопросы, не понимаю. Ну дистрибуция, это хорошо наверное.
Итого, тебе нравится, значит хорошо ;)
>> * Свежее ПО (rolling release)
> Сомнительный плюс. Даже скорей минус.Для людей творческих профессий (кому нужны свежедобавленные фичи в LibreOffice, Blender, QtCreator и т.п. уже вчера) очень даже весомый плюс.
Свежее ядро - это поддержка новых устройств. Вон, Valve выбрала Арч не в последнюю очередь из-за быстрого появления поддержки нового оборудовани (устройства ввода и вывода). А у игроков свежайшая mesa и xorg, исправляющие проблемы с блобом, всегда в почете были.> Но проблема софтом на других дистрах, я както не замечал.
А я замечал. Особенно сильно это касается свежеиспеченного ПО, которое в других дистрибутивах появляется обычно через год-два после новостей о нём.
>> * Быстрый (с-ка!), гибкий (пользовательские хуки, выборочная распаковка) и универсальный (MSYS2) пакетник (pacman)
> Пользователю вообще на это нагадить.Пользователи разные бывают. Линуксом часто пользуются продвинутые. Да и непродвинутые оценят, когда софт ставится быстро (а не как в Федоре или Убунту), а проблемы, требующие перепакетирования в других дистрах, здесь решаются одной волшебной настройкой, скопированной с форума.
>> * Последние версии ПО с минимумом кастомных настроек и патчей
> Минус, а не плюс. Разработчики чего? Разрабы тоже хотят спокойно работать.Разработчики этого ПО. Не хотят получать сообщения об давно исправленных ошибках из позапрошлых релизов или уникальных ошибках, добавленных не прошедшими ревью патчами случайных сопроводителей.
А когда они тормозят, например, с обновлением зависимостей, им ещё и помогают, шлют патчи. (Говорю как человек, который слал.)> В первые пару лет играешься, а потом ставишь весь дефолт
Или оформляешь постоянные настройки drop-in-ами в пакетах.
>> Легко совмещать сопровождение пакета ПО с его разработкой в upstream
> Смотря для кого. За всех не расписывайся.А в чём трудности? Что может быть лучше, когда обновления в дистрибутиве идут синхронно разработке, а реакция пользователей на них своевременна?
> Слишком много пердолинга для 24 года.
Для старой школы - наоборот, позволяет решать проблемы не глядя.
> Видел я ваши портянки для пакетирования, назвать это удобно, язык не повернется.
Не менее удобно, чем у других. Но, главное, очень гибко (для знатоков Баша, разумеется).
> Для людей творческих профессий (кому нужны свежедобавленные фичи в LibreOffice, Blender,
> QtCreator и т.п. уже вчера) очень даже весомый плюс.Либра софт вообще не нужен ни кому, ты еще сюда Gimp написал)) нет хуже софта чем Либра и Гимп.
Остальное всегда качается с сайта разработчика, а не с репы. Если ты качаешь с репы, поздравляю, ты мимоход в этом и говоришь, о том о чем не знаешь.> Свежее ядро - это поддержка новых устройств.
Оборудование меняется редко. Это не аргумент.
> Вон, Valve выбрала Арч не
> в последнюю очередь из-за быстрого появления поддержки нового оборудовани (устройства
> ввода и вывода). А у игроков свежайшая mesa и xorg, исправляющие
> проблемы с блобом, всегда в почете были.Но тут согласен. Но не все играют, у меня на убунте все хорошо играет, не хуже арча.
> А я замечал. Особенно сильно это касается свежеиспеченного ПО, которое в других
> дистрибутивах появляется обычно через год-два после новостей о нём.Примеры?
> Пользователи разные бывают.
Поэтому мы говорим про массового. А не про самых умных.
> Линуксом часто пользуются продвинутые. Да и непродвинутые
> оценят, когда софт ставится быстро (а не как в Федоре или
> Убунту),Скорость установки софта, новый пустой аргумент. Не замечал дискомфорта из-за скорости установки софта. А Федора вообще бета тест редхата. Его ставить на постояннку не стоит никому. Там проблемы от дистра к дистру всегда много и всегда разные. Гемморой постоянный.
> а проблемы, требующие перепакетирования в других дистрах, здесь решаются одной
> волшебной настройкой, скопированной с форума.Перепакатеривоние это новая фича от старой фичи пересобрать ядро. Так же нужно и также полезно.
Пустой аргумент.> Разработчики этого ПО. Не хотят получать сообщения об давно исправленных ошибках из
> позапрошлых релизов или уникальных ошибках, добавленных не прошедшими ревью патчами случайных
> сопроводителей.Хотят или нет, этого арч ни как не решает. Ибо твоим арчем пользуются не большинство.
От того, что разраб на арче, у меня ничего ровным счетом не поменяется.
Опять пустой аргумент.
> Или оформляешь постоянные настройки drop-in-ами в пакетах.Или ставишь дефолт и не играешься глупостями.
> А в чём трудности? Что может быть лучше, когда обновления в дистрибутиве
> идут синхронно разработке, а реакция пользователей на них своевременна?
>> Слишком много пердолинга для 24 года.
> Для старой школы - наоборот, позволяет решать проблемы не глядя.Ну для старой школы. беспорно. Старая школа любит пердолинг. Я тут не поспорю, так и есть.
Слава богу, я никогда к старой школе не относился. Я здоровый человек) Глаза белые> Не менее удобно, чем у других. Но, главное, очень гибко (для знатоков
> Баша, разумеется).ну нет, собрать Деб куда удобней. Не надо писать баш портянки. Сам синтаксис баша ужасен, его авторы писали поверш шел, так же убого.
> Либра софт вообще не нужен ни комуОбычный текстовый процессор. Не хуже других. Если уметь им пользоваться. Здесь, на Опенке, кто-то делился, что написал и сверстал на нём книгу. Охотно верю. Сам я, впрочем, предпочитаю структурированный (plain-)текст.
С Гимпом - аналогично.> Остальное всегда качается с сайта разработчика, а не с репы.
По хомякам и файлопомойкам пусть вантузятники рыщут.
Никогда не качаю с сайта разработчика. Тем более - бинари. Если нет в репах, то собираю пакет из сорцов от третьей стороны - сорц-хостера (Гитхаб и Ко, НКО самохост). Сорцы с вебсайта разраба встречаются весьма редко - ПО тех далёких времён, когда не было даже СурсФоржа.
Как говорится, ЧЯДНТ?> Оборудование меняется редко. Это не аргумент.
Принтеры, джойстики, видюхи. А игрокам всегда всё самое свежее подавай.
> Примеры?
Тысячи. И каждый год новые.
Godot2 пользовал с момента выхода, в других дистрах про существование движка узнали чуть ли не с третьей версии. UMLet 15 лет пользовал, пока никто не знал о его существоании. Recoll - локальный индекс и поисковик по книжкам и журналам, туда же. GoldenDict - та же история. Как и конвертеры словарей, например от Лингво для GoldenDict. ПО для обратной разработки: декомпиляторы, распаковщики. Да куча программ из непопулярных категорий, которые практически совсем отсутствуют в репозиториях других дистрибутивов, либо появляются там с огромными задержками.
И это я ещё библиотек для разработки не касался.
Сейчас, конечно, некоторые вещи есть на Flathub, что несколько сгладило проблему. Но сам Flathub появился относительно недавно. А я, так-то, с Линуксом десятки лет.> Поэтому мы говорим про массового. А не про самых умных.
Нет, я говорю о продвинутых. Благо, в Линуксе, в Арче, их хватает.
А до массового - мне дела нет, я ничем не торгую.> твоим арчем пользуются не большинство.
На десктопах - большинство. Либо Арчем, либо деривативами. Особенно, среди самых полезных разработчику, продвинутых пользователей.
> Или ставишь дефолт и не играешься глупостями.
Кому игры и глупости, а кому работать хочется в комфорте.
> Старая школа любит пердолинг.
У выпускников новой школы всё, самые тривиальные проблемы превращаются в "пердолинг". Вероятно, от недостатка знаний и нежелания его восполнять.
> синтаксис баша ужасен
Кому - шашечки, кому - ехать.
>> Либра софт вообще не нужен ни кому
> Обычный текстовый процессор. Не хуже других.Хуже! Не было бы замен, еще терпимо было, но давно уже есть куча аналогов, где всё лучше!
> Если уметь им пользоваться. Здесь, на
> Опенке, кто-то делился, что написал и сверстал на нём книгу. Охотно
> верю. Сам я, впрочем, предпочитаю структурированный (plain-)текст.Некоторые в пейнте рисуют картины. От этого пейнт не становится лучше!
> С Гимпом - аналогично.Гимп худшее что видел Линукс.
>> Остальное всегда качается с сайта разработчика, а не с репы.
> По хомякам и файлопомойкам пусть вантузятники рыщут.Да да официальные сайты для лохов, чужие репы от анонимных источников, вот выбор линуксятника с краными глазами. Именно так!
Хорошо, что профессионалы так не думают.
> Никогда не качаю с сайта разработчика. Тем более - бинари. Если нет
> в репах, то собираю пакет из сорцов от третьей стороны -
> сорц-хостера (Гитхаб и Ко, НКО самохост). Сорцы с вебсайта разраба встречаются
> весьма редко - ПО тех далёких времён, когда не было даже
> СурсФоржа.
> Как говорится, ЧЯДНТ?Ты играешься, а не работаешь. Секрет же прост.
Как наиграешься, поймешь ЧЯДНТ.>> Оборудование меняется редко. Это не аргумент.
> Принтеры, джойстики, видюхи. А игрокам всегда всё самое свежее подавай.Всё это покупается на несколько лет,как минимум.
То есть, это не аргумент, а просто очередной красно глазый опыт, который никому не нужен, кроме тебя.>[оверквотинг удален]
> никто не знал о его существоании. Recoll - локальный индекс и
> поисковик по книжкам и журналам, туда же. GoldenDict - та же
> история. Как и конвертеры словарей, например от Лингво для GoldenDict. ПО
> для обратной разработки: декомпиляторы, распаковщики. Да куча программ из непопулярных
> категорий, которые практически совсем отсутствуют в репозиториях других дистрибутивов,
> либо появляются там с огромными задержками.
> И это я ещё библиотек для разработки не касался.
> Сейчас, конечно, некоторые вещи есть на Flathub, что несколько сгладило проблему. Но
> сам Flathub появился относительно недавно. А я, так-то, с Линуксом десятки
> лет.Godot2 - С реп никто не качает. Только красно глазые вроде тебя.
UMLet - в репе есть
Recoll - есть репы как ты любишь
и тп и тд.
Короче, я понял, чисто фантазия.
Вот из этого списка нет нигде арча... то есть все твои пакеты не официальные, а собраны васянами.
Ни один профи не допустит такого. А в конторах где есть безопасник, тебя ссаными тряпками забьет за такое.
Аргумент стух.>> Поэтому мы говорим про массового. А не про самых умных.
> Нет, я говорю о продвинутых. Благо, в Линуксе, в Арче, их хватает.
> А до массового - мне дела нет, я ничем не торгую.А ты говоришь про тех кому тебе выгодно говорить. Ну это удобно. Конечно это маня мирок, но удобный манямирок для спора. Так можно сказать Линукс занимает 100% рынка десктопов. Среди пользователей Линукса!
>> твоим арчем пользуются не большинство.
> На десктопах - большинство. Либо Арчем, либо деривативами. Особенно, среди самых полезных
> разработчику, продвинутых пользователей.Среди пользователей арча 100% пользователей пользуются арчем. Тут не поспоришь!
В реальном мире правда арч не на первом месте.>> Или ставишь дефолт и не играешься глупостями.
> Кому игры и глупости, а кому работать хочется в комфорте.Комфорт это сделать задачу, а не пердолинг с ОС.
Ничего, подрастешь, поймешь. Пока ты на уровне пердолинг это круто)> У выпускников новой школы всё, самые тривиальные проблемы превращаются в "пердолинг". Вероятно,
> от недостатка знаний и нежелания его восполнять.Новая школа делает задачу, а не занимается пердолингом.
Твой пердолинг не интересен, он не делает ничего полезного, кроме как забирает время на себя.>> синтаксис баша ужасен
> Кому - шашечки, кому - ехать.Именно поэтому, я перешел на ГОЛанг. Поэтому Питон рулит. А Баш это ужас и красные глаза. Ну его нафиг.
А что люди кроме арча знают? Есть void linux, почти арч, но не популярен. Тот же NixOS, который не осилили, казалось бы матёрые, пользователи opennet
NixOS - свалка из костылей. Он угробил не самые плохие идеи отвратительной реализацией.
А бегают и рекламируют его на Опеннете те, у кого опять при обновлении вся система развалилась, и они хотят чтобы кто-нибудь вместо них, забесплатно, исправлял неиссякающие проблемы этого мертвоpoжденного уpoдца.
>NixOS - свалка из костылей. Он угробил не самые плохие идеи отвратительной реализацией.Покажите свою идею с теми же фичами, только лучше, Или не можите?
>А бегают и рекламируют его на Опеннете те, у кого опять при обновлении вся система развалиласьУдивительно, но NixOS в отличии от других систем у меня ни разу не ломался.
Покажите мне фичи, без которых нельзя нормально жить, ради которых стоило бы городить огород из костылей и тратить силы на его сопровождение?
Единственный выгодоприобретатель NixOS - это тот студент, который, не особо обременяясь, превратил курсовик в бизнес. Пока сообщество грызет этот кактус и, зачем-то, пытается там выживать. А могло бы жить.> NixOS в отличии от других систем у меня ни разу не ломался.
Ага, если не считать невозможность обновления без сноса части, якобы поддерживаемых, пакетов.
И частые runtime-проблемы с графическим ПО, которых нет ни в одном другом дистрибутиве Линукс.
>Покажите мне фичи, без которых нельзя нормально житьПлохой аргумент, ибо жить можно без многого. Амиши, например, без электроенергии живут.
>Ага, если не считать невозможность обновления без сноса части, якобы поддерживаемых, пакетов.Ну так не сноси, кто заставляет? Или не осилил?
>И частые runtime-проблемы с графическим ПО, которых нет ни в одном другом дистрибутиве Линукс.Пользуюсь несколько лет, ни одной проблемы не заметил. У вас точно с руками всё в порядке?
>>NixOS - свалка из костылей. Он угробил не самые плохие идеи отвратительной реализацией.
> Покажите свою идею с теми же фичами, только лучше, Или не можите?Легко: в именах подкаталогов /nix/store человекочитаемое имя разместить перед хешем.
Во-первых, ждём патчей, во-вторых - и это всё? Неуж-то ничего большего придумать не смогли?
> Во-первых, ждём патчейЖдём - это кто? Неумеющие следить за обсуждением и упустившие "покажите свою _идею_"?
Ну и да, анонимные патчи не принимаются, так что и запросы идут в том же направлении.
> во-вторых - и это всё?
Это не всё, а ключевое.
> казалось бы матёрые, пользователи opennetБольшинство тут специалистов, мышку не заменят на ПК. Не думай многое про здешних специалистов)
Наглядный граф зависимостей, это хорошо. Может быть некоторые майнтайнеры посмотрят и поймут, чем они заняты.
Несчастные люди, разгребать за интеллектуальными инвалидами которые формашлепят код та еще задачка.
> Несчастные люди, разгребать за интеллектуальными инвалидами которые формашлепят код та
> еще задачка.Ещё бы. Когда сами даже формошляпить не умеют. Усложняется тем, что заодно надо как-то аккуратно набросить на тех, за счёт чьего труда они живут.
Чатгоп смеется над вашим коментом. Дарпа натаскает на куче сишного кода свой транслятор и человекокот останется как хобби.
> Чатгоп смеется над вашим коментомНе думал, что кто-то возьмёт на себя смелость назвать себя чатгпт
> Чатгоп смеется над вашим коментом. Дарпа натаскает на куче сишного кода свой
> транслятор и человекокот останется как хобби.Натаскает и натаскает...
А чего на выходе будет?
Оно же от мясных мешков научится офнокодить - те вон даже сплит строки без CVE сделать не могут.
Все показательные косяки дыряшки будут просто сыпаться как из сита.
По моему опыту, только вантузятники воюют против сопроводителей, потому что в Линукс-мире разделить разработчика и сопроводителя ПО весьма затруднительно. Требуемые навыки пересекаются. Бессмысленно отгораживаться друг от друга искусственными заборами. В любом случае, м-ков хватает во обоих лагерях.
Ну, или это что-то личное, какая-то персональная обида.
> По моему опыту, только вантузятники воюют против сопроводителей, потому что в Линукс-мире
> разделить разработчика и сопроводителя ПО весьма затруднительно. Требуемые навыки пересекаются.
> Бессмысленно отгораживаться друг от друга искусственными заборами. В любом случае, м-ков
> хватает во обоих лагерях.
> Ну, или это что-то личное, какая-то персональная обида.Линус Торвальдс вантузятник чертов!!! Я так и знал!!!
И да, мейнтейнеры должны умереть как класс. Софтом должен заниматься ТОЛЬКО разраб! Посредники зло! Скажет любой адекватный человек!
Настанет день и ты это поймешь.
> Линус Торвальдс вантузятникНемного конкретики?
Я нашел противоположное:
https://www.zdnet.com/article/linus-torvalds-on-state-of-lin.../
(Там он про сопроводителей ядра говорит, но, ИМХО, во многих вещах сказанное применимо и к постоянным сопроводителям других проектов, включая разработку дистрибутивов Линукс.)> Софтом должен заниматься ТОЛЬКО разраб!
Но он предпочитает заниматься маркетингом!
> Посредники зло! Скажет любой адекватный человек!
ru.wikipedia.org/wiki/Третейский_судья
> Настанет день и ты это поймешь.
Страшный Суд, что ли?
>> Линус Торвальдс вантузятник
> Немного конкретики?
> Я нашел противоположное:
> https://www.zdnet.com/article/linus-torvalds-on-state-of-lin.../Ну тут он говорит что стал мягче. Видать поменял мнение. Раньше он считал мейтенеров лищним звеном. И хорошо аргументировал почему так.
> (Там он про сопроводителей ядра говорит, но, ИМХО, во многих вещах сказанное
> применимо и к постоянным сопроводителям других проектов, включая разработку дистрибутивов
> Линукс.)Всегда есть исключения из правил, когда утверждение ложно.
Но в целом если говорить, практика, что твой код распространяет какойто левый чувак, ужасна сама по себе. Как для разраба, так и для конечного пользователя.
В случае косяка мейтейнера, страдает репутация разработчика и страдает пользователь.
А мейтейнер как гусь, вся вода обтекает и ему пофигу. Продолжай дальше творить дичь.>> Софтом должен заниматься ТОЛЬКО разраб!
> Но он предпочитает заниматься маркетингом!Вот это и плохо. Он отдает свой продукт в чужие руки. Чужим людям.
>> Посредники зло! Скажет любой адекватный человек!
> ru.wikipedia.org/wiki/Третейский_судья?
>> Настанет день и ты это поймешь.
> Страшный Суд, что ли?Причем тут суд? Придет осознание, что мейтейнеры тормозят развитие Линукс.
Что это плохая практика. Которая прячет проблемы Линукса. И не дает их исправить. Ведь есть костыль с мейтейнерами.
> он считал мейтенеров лищним звеном. И хорошо аргументировал почему так.Ссылочку, пожалуйста. Или аргументы, своими словами.
> практика, что твой код распространяет какойто левый чувак, ужасна сама по себе. Как для разраба, так и для конечного пользователя.
Я, как юзер, хочу хоть иметь заслон из небольшой, компететной в вопросах построения моего дистрибутива, группы людей, которым я доверяю больше, чем легиону разработчиков, каждому со своими тараканами.
Я, как разраб, хочу общаться не с толпой обывателей, у которых что-то не работает, из-за неправильной фазы луны, а с несколькими куда более компетентными сопроводителями, которые найдут зерно проблемы и принесут мне в upstream. Иногда с готовыми исправлениями.
> В случае косяка мейтейнера, страдает репутация разработчика и страдает пользователь.
Репутация страдает, когда он принимает непопулярные решения, какую-то бяку пытается пропихнуть под видом улучшений. В остальных случаях пользователи, прекрасно понимают на какой стороне проблема, потому что разработка и сопровождение открыты для общественного наблюдения. Это если им вообще есть дело до какой-то там "репутации", и они не просто терпеливо ждут исправлений для привычного им ПО, которое они не готовы менять даже под страхом лицензионного рабства.
И кстати, когда разработчик работает соло, проблем в его ПО кратно больше, чем когда он работает в связке с сопроводителями. По понятным причинам. (См. "код-ревью", "парное программирование", "тестирование" и т.п.)> А мейтейнер как гусь, вся вода обтекает и ему пофигу. Продолжай дальше творить дичь.
Ты явно никогда пакеты не сопровождал. Половина проблем с ПО, которые приходится решать - это чужие проблемы, а не твои. Либо кривые руки других пользователей, либо - разработчика ПО. Лишняя нагрузка. Не говоря о необходимости работать в удобном для других (а не себя) темпе.
> мейтейнеры тормозят развитие Линукс
Каким образом?
> По моему опыту, только вантузятники воюют против сопроводителей, потому что в Линукс-мире
> разделить разработчика и сопроводителя ПО весьма затруднительно.Затруднительно тем, кто сам ничего не написал, не проектировал, не выводил проект из начальной стадии. Действительно, в "мире Виндос" программистов существенно больше, если говорить о России. Потому и возникает конфликт интересов программистов с админами и торгашами, страдательно забалтывающими факт: в соответствующем ГОСТ-е написано "сборщик", но вообще нет "программист".
> Требуемые навыки пересекаются.
Спроектировать, в том числе с учётом времени жизни - инженерный навык. Скопировать spec для rpm из Fedora и подправить пару строчек - с этим справиться не только физик-теоретик, за всю жизнь написавший лишь курсовик на Pascal.
> Бессмысленно отгораживаться друг от друга искусственными заборами.
Смысл есть, и для торговцев готовым он в том, что они не вкладываются в разработку, это позволяет существенно поднять прибыль, не задумываясь о завтрашнем дне.
> В любом случае, м-ков хватает во обоих лагерях.
> Ну, или это что-то личное, какая-то персональная обида.Да, это личное. Обидно за державу, когда "российские разработчики" ходят по сути с протянутой рукой к белому господину за исходниками, а например фамилия Марков стоит рядом с Чёрчем и Тьюрингом.
> в "мире Виндос"
> конфликт интересов
> в соответствующем ГОСТ-еНе, не слышал. Проблемы коммерсов энтузиастов не трогают. Кушайтесь там сами со своим любимым рыночком большой ложкой и не перекладывайте с больной головы на здоровую.
Над Марксом посмеялись? Теперь над Смитом поплакаетесь.> Спроектировать, в том числе с учётом времени жизни - инженерный навык.
Которым от силы обладает два-три разработчика из ста наёмных. Остальные лепят, как чёрт на душу положит, или, в случшем случае, копируют у тех, кто немного умнее, а те у академической науки.
Короче, разработчики очень всякие бывают. Нередко, даже глупее "сборщиков". В наши дни юзерфрендли инструментов и готовых библиотек и фреймворков, это не мудрено.> spec для rpm из Fedora и подправить пару строчек
Крайне ограниченное представление о том, чем занимается сопроводитель. Скрипт сборки пакета (иногда ещё сборки ПО и интеграции: .service, .desktop, tmpfiles.d, polkit-1/rules.d и т.п.) пишется один раз. А вот исправлением возникающих ошибок сборки, интеграции (конфликтов с другим софтом, конфликтов настроек) и выполнения, например, из-за неактуальных зависимостей - постоянно. В дистрибутивах с релизным циклом, добавляется ещё и бэкпортирование важных изменений, вроде исправлений безопасности.
> для торговцев готовым
Проблемы торговцев.
Перестаньте продавать медвежьи одолжения другим на рыночке и начните решать свои проблемы, совместно с другими энтузиастами. И не будет обид и разочарований.
А живёте средь волков, так и войте по-волчьи, а не по-ослиному.> "российские разработчики" ходят по сути с протянутой рукой к белому господину за исходниками
В чём это выражается?
>> в "мире Виндос"
>> конфликт интересов
>> в соответствующем ГОСТ-е
> Не, не слышал. Проблемы коммерсов энтузиастов не трогают.Так ты энтузиаст? Ничего о тебе не слышал. Порадуешь ссылочкой на гитхап? Без этого не вижу смысла читать далее, поскольку ты автоматически оказываешься потребителем-халявщиком.
Проблема не в компетентности отдельных сопроводителей или разработчиков дистрибутивов, а в децентрализованном, базарном, мелко-буржуазном характере волонтерской разработки ПО. С другой стороны, продолжениями этих недостатков являются многие достоинства.
Настанет время и в GNU/Linux будет царить крупная буржуазия.
Над всеми левыми идейками царит "крупная буржуазия", начиная с товарно-денежных отношений между Марксом и Энгельсом.
> Над всеми левыми идейками царит "крупная буржуазия", начиная с
> товарно-денежных отношений между Марксом и Энгельсом.Но только потому что у всех остальных получилось еще хуже. Погоди, сейчас тебе гопоть из подворотен объяснит в чем прикол. Еще несколько лет в таком режиме - и ты будешь радоваться придя домой одним куском, что тебя не прибили в подворотне за пакетик гречки. Это твое счастливое будущее, каким оно начинает вырисовываться уже сегодня.
> Погоди, сейчас тебе гопоть из подворотен объяснит в чем прикол.В смысле, он мне расскажет "ты один, а нас семеро: я и мой друг Аноним"?
> Настанет время и в GNU/Linux будет царить крупная буржуазия.Так уже. IBM/Redhat называется. (Ну и вечноотстающий Каноникал, где-то в хвосте плетётся.) Важные проекты в экосистеме насаждает своими сотрудниками, покупает, захватывает или заменяет на свои аналоги. Централизация разработки юзерспейса уже много лет идёт полным ходом. И добилась некоторого успеха.
И? Противники крупной буржуазии осилят хоть что-то? Или только с лозунгами будут выступать?
Без готовности переписать проект - бесполезно.
Помню, были когда-то в ходу анекдоты про русских программистов, которым лишь бы всё попереписывать. Потом большинство уехали.
> Помню, были когда-то в ходу анекдоты про русских программистов,
> которым лишь бы всё попереписывать. Потом большинство уехали.Ну так как уехали - вот и стали выходить новости что переписан %s на %s :)
Ну увидешь на двадцать больше зависимостей, чем должно быть, и дальше что? Если зависимость удалить, то программа не работает.
Мне не надо видеть, я из теории и практики знаю, что такое граф. А ты по крайней мере сможешь на него посмотреть. Опыт показывает, что наглядное представление позволяет некоторым увидеть что-то новое.
Ну увидел, и что дальше? Разве нет такой вероятности, что зависимость была добавлена целенаправлено?
Вероятность есть во всех случаях, что очевидно из формулы полной вероятности.
Так нахваливают башизмы. а в теме про Системд они же наверняка баш портянки закидывали какахами. Прогеру выше даже чекер нужен был для трехстрочников.
> Так нахваливают башизмы. а в теме про Системд они же наверняка баш
> портянки закидывали какахами. Прогеру выше даже чекер нужен был для
> трехстрочников.Поскольку тебе для клеветы пришлось сделать вид, что у тебя плохо с памятью, напоминаю: "А аналог doxygen есть?"
И поздравляю: doxygen для тебя "чекер". =)
Из того что я там вычитал про аналоги так и есть.
По-моему кое как с натяжкой только команду СтимДек можно сюда присунуть. Сомневаюсь, что кто то ещё использует Рачик.
> По-моему кое как с натяжкой только команду СтимДек можно сюда присунуть. Сомневаюсь,
> что кто то ещё использует Рачик.Да. Но тем не менее, это полезно.
>Например, доступны средства для наглядного анализа зависимостей, работы со снапшотами наборов пакетов (для сохранения и восстановления состояния), управления остаточными зависимостями и отката отдельных пакетов или всей системы на прошлые версии.Переизобретение возможностей nix продолжается. Очень интересно, как они собираются откатывать отдельные пакеты, если в арче это не подерживается. Появился в минорной версии новый символ, и всё пакет уже откатывать нельзя.
>Проект создан в 2012 году и изначально был нацелен на предоставление средств для сборки пакетов для репозитория AUR (Arch User Repository), применяемого для распространения сторонними разработчиками своих пакетов, не входящих в основные репозитории дистрибутива Arch LinuxАур - это плохо. Мало того, что модерации нет, так пакет ещё могут в любой момент забросить. Для некоторых программ есть сразу несколько пакетов разной степени устаревания.
>Смена языка позволила значительно повысить производительность, упростить установку, задействовать готовые Rust-биндинги к libalpm, сделать проект более привлекательным для новых разработчиковИнтересно, чем это раст более привлекательный чем хаскель? Если человек не знает язык, то всё равно, какой учить.
А в официальных репозиториях может и не быть вовсе. AUR - это ни хорошо, ни плохо.
С этим можно было бы согласится, если бы не пример альта и не пример никсос. Мелкий основной репозиторий отчётливо говорит о проблеме: отсутствия мейнтеров/бюрократии/малой популярности/ещё какой-нибудь, но проблеме. С учётом популярности арча, у него должен быть огромный поддерживаемый репозиторий, а не непонятный аур.
Чем Aura лучше чем зарекомендовавший себя Paru?
Там в новости написано.
Возможность сделать полный или частичный даунгрейд. Как это происходит — хз.
Умение работать с пакетами-сиротами. Чем это отличается от стандартной работы через пакман — хз. Вроде те же действия из примера можно и в pacman провернуть.
Рисовать тебе граф на все зависимости. В чём практичность этого решения — хз, но красиво, да.Какой-то свой сервер для поиска FAUR, где нельзя ни частично ни по регулярным выражениям искать.
А так просто очередная обёртка, как yay и прочие менее популярные.
Полагаю, ничем. Просто еще один враппер над пакманом. Потому что автор смог, потому что раст, потому что стильно-модно.
Ну вот, лично меня завлекла история с частичным или полным даунгрейдом.
Если это что-то путёвое, что сможет разрулить зависимости с разными версиями библиотек для разных версий программ, то уже хорошо. В пакмане такого пока нет.Ещё бы что-то дельное придумали с опциональными зависимостями...хотя, это скорее к мейнтейнерам арча.
>Если это что-то путёвое, что сможет разрулить зависимости с разными версиями библиотек для разных версий программ, то уже хорошо.Не сможет. Это нужно отказываться от FSH, как в NixOS.
> доступны средства для наглядного анализа зависимостейМожет, наконец-то, кто-то и заметит, какая "легковесная" система у них получается. Зависимости hwinfo, например.
Debian: hwinfo << libhd21 >> libuuid1 libx86emu3
Arch: hwinfo << libx86emu=3.5 perl-xml-writer perl-xml-parser >> expat perl-libwww >> perl-encode-locale perl-file-listing perl-html-parser perl-http-cookiejar perl-http-cookies perl-http-daemon perl-http-date perl-http-negotiate perl-lwp-mediatypes perl-net-http perl-try-tiny perl-uri perl-www-robotrules... всего 21 perl-* и это только обязательные.
Жуть.
Все-равно загружается и работает быстрее.
>Все-равно загружается и работает быстрее.В каком месте? Максимум, что может работать быстрее - это новые драйвера. И то, для нового железа.
Легковесность определяется не местом на диске, а местом в памяти. В память загрузится столько же, сколько у других.
Удивительно, среди "главных новостей" на опеннете сообщение о выходе версии приложения, которое даже не входит в число пакетов самого Archlinux-а.Более пятнадцати лет использую Archlinux основной системой, и вот только из этой новости узнал о Aure.
Ну, тогда уже никак нельзя не упомянуть в новостях https://salsa.debian.org/otto/debcraft - easy, fast and secure way to build Debian packages. Уже в официальных репах!
> Уже в официальных репах!?
Каких "официальных репах"?
Дебиана и Убунты.
А, ну года через три в stable появится.