BSDPORTAL.RU

Я тут между делом запилил проект repology.org. Идея его в том, чтобы сравнивать версии ПО доступного во всевозможных дистрибутивах и репозиториях (сейчас умеет порты FreeBSD и OpenBSD, pkgsrc, пакеты Debian, Ubuntu, Arch, Gentoo, ALTLinux (репозиторий Sisyphus), OpenSUSE, SlackBuilds и Chocolatey (пакетный менеджер для windows, если кто не знает)), понимать где пакеты требуют обновления, где софт свежее и т.д. Пока бета, но уже неплохо работает - в частности, с помощью него я узнал о пачке новых версий для моих портов, которые пропустил portscout.

Так вот, новость состоит в том, что FreeBSD является одним из лидеров по свежести пакетов (вообще, как считать лидера довольно спорный вопрос, но пока лучшей метрики чем общее количество пакетов/портов с известно свежайшей версией я не придумал - она оценивает сразу и количество, и качество):

https://repology.org/statistics

и уступает только Debian Unstable.

PS. Отдельно по играм, FreeBSD безусловный лидер.

Очень круто!
А почему FreeBSDшный portscout не справляется?

З.Ы. Ещё б поиск по наименованиям...

Он ищет новые версии там же где лежали старые. А если проект переезжает на другой хостинг, на github, меняет мантейнера или схему именования релизов, он его никогда не увидит.

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

Фряху лидером, наверное, можно назвать лишь с оговоркой, что у Фряхи берется current-срез портов, а не ежеквартальные срезы + в Линуксе сравниваются стандартные репы дистрибутива. Но как правило, у всех производителей ПО есть свои собственные репы (apt например), в которых авторы ПО, как правило, заботятся о Линукс-пользователе и самостоятельно собирают всегда свежий пакет.

Не сканятся. В будущем возможно подключу тот же portscout или его аналоги от других дистрибутивов, а может и сам добавлю похожую функциональность, но это в любом случае будущем. Здесь нужно быть аккуратным чтобы не нахватать false positive. А так помимо дистрибутивов уже есть поддержка freshcode.org - это преемник freshmeat как я понял, новости о релизах софта - он местами довольно свеж. Но пока не на главной - в таблицу всё уже не влезает, не придумал пока как это по-человечески верстать.


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


Нет, у всех дистрибутивов по возможности берутся наиболее свежие пакеты, поэтому сравнение вполне корректно. Аналог FreeBSD quarterly будет ближе к debian testing/stable (они тоже поддерживаются "за кулисами"), в сравнении же участвует unstable.

Еще пока не разобрался как мапы делать, какое название брать за эталон и по каким правилам (нужно GUI / WEB- редактор к этому файлу правил сделать )

Посмотрел на свои порты: https://repology.org/maintainer/olevole%40olevole.ru

Почему-то не смапились порты в Ubuntu по этиму правилу:



Еще, эти правила

- { namepat: "python-(.*)", setname: "python:$1", repos: [ debian ] }
- { namepat: "lua[0-9]{0,2}-(?:lua)?(.+?)", setname: "lua:$1", repos: [ freebsd, pkgsrc, openbsd, arch, debian ] }

по идее, можно на ubuntu расширить:

freebsd: fusefs-zip , ubuntu: fuse-zip
freebsd: lua-lpeg{51}, ubuntu: lua-lpeg
freebsd: py-spice-gtk, ubuntu: python-spice-client-gtk

(сделал pull request)

Это сложный вопрос. У меня есть два основных критерия: лучше брать за эталон наиболее полное и однозначное развание (flight-of-the-amazon-queen вместо fotaq, например), а также то, которое используется большинством. Когда они противоречат, или явного большинства нет, приходится разбирать каждый случай индивидуально.


Это да.


Почему, как раз смаппились. Всё смаппилось fusefs:zip для FreeBSD, Debian/Ubuntu, Gentoo, OpenBSD.


Там указывается не конкретный репозиторий, а семейство, и в семейство debian входят и debian и ubuntu. Зарефакторю в family чтобы было понятнее.

Есть пожелалки ... если конечно они будут интересны

1. Собирать данные и сортировать их хронологически, раз в период делать промежуточные пересчеты и хранить их
2. Мочь отображать статистику в виде графиков
3. Интересует периодичность: от начала первого скана, за текущий год, за прошлый месяц
4. Предусмотреть/разработать децентрализацию сбора инфы, чтобы множество интересующих и могущих - подключали свои выч.-информационные ресурсы и участвовали в благом деле А это и инструментарий, и документация, и регламент, и вайт-лист надежных "коллег"
5. Самое главное - рубрикация статистики! О ней ниже:

Берем любой пакет/порт/либу. Что нас прежде всего интересует, в порядке убывания важности (за указанные выше периоды):

* он жив? когда был очередной релиз/билд (тупо календарь)?
* как интенсивно идет доработка, как часто выходят новые релизы (штук в период(ы))?
* он нужен, популярен - какая ОС/дистрибут и когда его запилили под себя (кто и когда быстрее)?

Ну и пересчет упоротой статистики (за указанные выше периоды):

* кто пилит быстрее под себя по всему?
* кто пилит быстрее под себя по конкретному порту?
* какие порты живее более чем другие?

========================================================================

"Если гора не идет к Магомету ... то утро вечера мудренее!"

Обратите внимание на "политику" соцсетей и прочих монстров web-индустрии. Предоставляют API своих "кнопочек", "комментов", "лайков" ... А это, по сути, пассивный сбор инфы. Не вы сканер и инициатор получения нужного, а "они". Так почему бы не создать подобное, "прозвонить" держателей/координаторов прожектов и не предоставить им подобное? Пусть работают, релизятся, отчитываются, в конце-концов, рекламируются и соревнуются? Если еще подумать о репортах о фидбеках и коммитах, поле на паханное!

Ну вощем, вот такие мысли, под пьяную лавочку ...

_________________
Обращаюсь на "ты". Если не устраивает - пишите в ПМ, я применю патч :)

Начинание безусловно достойное, гляжу и прогресс есть (надо бы разобраться и хоть себя пофиксить )

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


Гордость за своих, оно конечно неплохо, но меру пожалуй терять не стоит
Тут в общем то и метрика так себе, а уж то что намеряно, это отдельная тема большой беседы, ну если кратко, то пакетные менедженры, нынче не то что бы апстрим (pip, npm, docker, пребилдед от автора и тысячи их)

Ну и да, хоть бы какой поиск что ли, рубрикация дело неплохое, но очень утомительное, вот тот же portscout с их фильтрами, неплохой образец (хотя там понятно задача попроще)

@amdmi, а по этому ресурсу как-то можно сравнить дистрибутивы по количеству unmaintained пакетов? В случае с фрей, это мейнтейнер с адресом ports@freebsd.org. А вот как в других ОСях я незнаю. Мне кажется, фряха тут тоже будет лидером, почти 5k портов бесхозных.

Нет. И unmaintained ни о чём не говорит. С одной стороны, многие порты без maintainer'а замечательно поддерживаются (и в целом у ports@ не так много портов требующих обновления), с другой - многие maintainer'ы не только не чешутся поддерживать свои порты, но и тормозят принятие изменений в дерево. Помимо этого, есть группы (perl@, python@, x11@, kde@ и т.д.) которые также не проявляют особой активности (эта тенденция не уникальна для FreeBSD, потому что, как известно, если ответственных несколько, на деле ответственных нет), но создают видимость наличия поддерживающего.

Так-то можете сами посчитать - например, FreeBSD 4.5k на 25k портов, OpenBSD (ports@openbsd.org) - 4k на 8k, pkgsrc (pkgsrc-users@netbsd.org) - 9k на 14k, так что нет, лидером не будет. Но по мне куда лучше явно unmaintained порт чем (не)поддерживаемый каким-нибудь "<distro> <topic> team/group/project/maillist".

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

Вы не видите тут противоречия? Как-бы https://repology.org/maintainer/kde%40freebsd.org. Но это ладно, пусть там хоть ничего не обновляется, я имел в виду другое - если послать PR к порту "поддерживаемому" группой, вероятность не дождаться ответа стремится к 1. Для gnome@'вских портов, например, я коммитил только по timeout'у или после пинка kwm@ в IRC. То же самое с perl@ - жду вроде review, получаю ответ "нафига ждёшь?". В этом вся суть групп - без единственного ответственного ответственных нет. Лучше пусть вместо них будет ports@ и порты разбираются теми кто их реально использует, или пусть будет blanket на смену maintainer'а с группы на персону, как в случае с ports@. Плюс ужесточение maintainer timeout'ов и reset'ов. Плюс COMAINTAINERs. Это когда при том что maintainer остаётся один, он может разрешить кому-то (кому он, понятно, доверяет, потому что вся ответственность остаётся на нём) изменять порт без его одобрения. Но и просто с тем что у нас есть ports@ уже неплохо.


Не вижу никаких проблем - с технической стороны это exp-run + commit. А так, естественно, нужно предварительное тестирование в отдельной репе, сейчас с git это делается очень легко. Раньше был, насколько я помню, невнятный marcuscom. Желательно разбить на мелкие, но понятно что с монстроDE это не всегда возможно. Хотя я вот не уверен что хотя бы часть kde'шных приложений не сильно завязанных на новые API (те же игрушки) нельзя обновить прямо сейчас.


А был спор? Почему не хотят, только я менторю двух будущих коммиттеров. Кого попало естественно не берут, нужны опыт, активность и адекватность. Нужно просто присылать побольше патчей (кроме своих портов есть ничейные которые можно взять, чужие которые нужно обновить или почистить, всяческие глобальные задачи типа https://wiki.freebsd.org/PortsLongtermTargets, фишки для Mk/ типа переделки какой-нибудь часто нужной штуки на USES, или добавления лицензии и много чего ещё).

Признаться, нет. Я имел ввиду, что в репозитории kde@ все порты давно самые новые, мы идем почти в ногу с апстримом. А во фряшном дереве до сих пор ничего нет. Впрочем, отчасти мы конечно и сами виноваты, т.к. долго собирались с открытием review.

Кстати, раз уж зашла речь о зависших PR, я жду как раз вашего review: https://bugs.freebsd.org/bugzilla/show_ ... ?id=212601

Distrowatch оказывается, тоже такое или умел или научился:

https://distrowatch.com/dwres.php?secon ... st=freebsd

Хорошо бы было и на Repology сделать форму для выбора конкретных дистрибьюций в виде сводной таблички.

У меня была такая идея. Загрузить список пакетов и получить статистику по дистрибутивам. Но это игрушки, так что только где-то в отдалённом будущем.

Пользуясь случаем хотел бы простимулировать скромную лепту в процессе вышеупомянутого освежения
https://bugs.freebsd.org/bugzilla/show_ ... ?id=222032