Как стать автором
Обновить
1
Карма
0
Рейтинг
Дмитрий Маракасов @AMDmi3

Разработчик свободного ПО

  • Подписчики 7
  • Подписки

Fediverse – социальная сеть будущего

Уже пару лет тестирую mastodon, и пока это вызывает только лютую печаль.


Нет никакой возможности фильтровать полезный контент. Из трёх упомянутых лент:


  • Глобальная бесполезна, потому что это сплошной поток (и уже довольно значительного объёма) нерелевантного мусора. Ото всех подряд, обо всём подряд (хотя в основном ни о чём, т.е. shitposts), на всех подряд языках (фильтр по языку есть, но не похоже чтобы он работал).
  • Локальная бесполезна, потому что отсекает большую часть постов по синтетическому признаку (принадлежности к инстансу). Хотя она и может иметь более высокую среднюю релевантность если вы выберете правильный тематический инстанс. Но, во-первых, обычно на тематических инстансах явно не запрещены другие темы и всё равно на инстансе про СПО получаем фотки еды и домашних животных и обсуждение ковида, во-вторых, что делать если мне интересно несколько тем, не плодить же аккаунты?
  • Подписки на пользователей бесполезны потому что даже если подписаться на кого-нибудь из-за качественного интересного поста, следующим постом обязательно пойдёт еда, политика, ковид, superbowl и прочая ерунда.

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


К платформе тоже есть вопросы. Пока впечатление такое что цензура там куда реальнее чем в централизованных сетях, при этом злее и неадекватнее. Кто-то позволил себе не поддержать BLM/SJW, сразу начинаются призывы (а к слову, неадекватных SJW которых забанили в других сетях в fediverse пруд пруди) забанить (defederate) весь его инстанс. И админам приходится дефедерироваться, иначе начинают дефедерироваться уже с ними.


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

Еще один взгляд на парадокс Ферми

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


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

Google захватывает Python

Это очень хорошо, сказал он, потому что теперь можно использовать BigQuery на индексе репозитория!

Это же очень давно можно, и это большая проблема, потому что полные метаданные о пакетах в PyPI можно получить только через проприетарное гугловское API, требующее ещё и наличия Google аккаунта. Для Repology, например, мне пришлось написать сервис который собирает частичные метаданные из нескольких разнородных, полурабочих и частично deprecated API, вместо того чтобы просто скачать json, как это делается для других поддерживаемых коллекций модулей включая RubyGems, crates.io, CPAN, CRAN, MELPA, Hackage, LuaRocks и т.д.

Pet-проекты: зачем они нужны, и стоит ли тратить на это время в 2020 году + опрос

Очень неприятно что постулируется первичность работы и вторичность "pet-проекта". Как насчёт того что, наоборот, основной деятельностью талантливого разработчика является развитие собственных проектов, а работа — всего лишь средство поддержки этой деятельности?

Линукс-порт Far Manager: прогресс за 4 года

Кстати, чтобы проще было попасть в пакетные репозитории неплохо было бы ответственнее относиться к релизам. А у вас в cmake версия 2.2.0, а в тэгах какое-то alpha-17sep20.

Линукс-порт Far Manager: прогресс за 4 года

В репозитории дистрибутивов мы пока не попали

Попали уже несколько лет назад (ALT, AUR, FreeBSD, nix, Rosa)

Make на мыло, redo сила

CMake тут не в чем винить — у вас очень странная хотелка и я не знаю систем сборки которые позволяли бы для каждой зависимости индивидуально контролировать где её искать. Обычно разные окружения ставят целиком в разные префиксы и указывают CMAKE_FIND_ROOT_PATH, больше ничего не надо.


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

Альтернатива ему пилится ровно одна — meson. От второй, qbs, сами авторы отказались в сторону CMake — не был бы он так приятен и понятен, этого бы не произошло. Но я не настаиваю — используйте любую другую высокоуровневую систему сборки. Посыл был прежде всего в том чтобы не писать скрипты вручную.

Make на мыло, redo сила

А какая разница как описать структуру проекта? Декларативно или в виде набора команд с флагами разными? Грубо говоря, количество информации которое вам, как разработчику, нужно ввести в компьютер, чтобы объяснить ему правила для сборки — и в том и в другом случае одинаковое

Ну конечно же нет, в том то и дело. Количество информации различается на порядки. Команды и флаги будут разными на разных системах, компиляторах, дистрибутивах и версиях одного дистрибутива. Например, чтобы подключить потоки может потребоваться -pthread, -lpthread, -lthr только на BSD. -ldl на FreeBSD не существует, а на Linux нужен. C++17 может включаться как -std=c++17, -std=c++1z, /std:c++17, где-то вообще быть по умолчанию. Банальная сборка статической библиотеки это два ни разу не очевидных вызова ar/runlib только на *nix, в windows вообще по другому. У install есть несовместимости в аргументах между GNU и BSD версиями. Как и у sed, awk, grep и что вы там ещё будете звать из ваших скриптов.


В CMake каждая из этих операций делается ровно одной строкой, которая описывает сама себя и работает везде, даже на solaris и haiku, даже если вы о них первый раз слышите.

Make на мыло, redo сила

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


Если мы про сборку ПО, то уж извините, но никто кроме горстки радикалов которым не угодил размер CMake (на самом деле сборка — это сложно, и эта сложность так или иначе должна где-то обитать; очень недальновидно отказываться от замечательного инструмента который всю это сложность инкапсулирует и поддерживает за вас, тащить её себе в проект и потом нести бремя поддержки) не пишет руками россыпь императивных скриптов (и в особенности не парсит include sed'ом), когда можно декларативно написать "нужна библиотека A из исходников X и исполняемый файл B из исходников Y и этой библиотеки" на CMake, и из него получить сборку хоть на make, хоть на ninja, хоть на msbuild, хоть на том же redo (если кто-то напишет генератор) или проекты под любые IDE, и это будет нормально обрабатывать зависимости, работать с любыми компиляторами, уметь кросс-компиляцию, выполнять все требования к сборке (а не только те что вы не забыли) и ещё много много всего что вам придётся либо писать руками, либо вы написать забудете (сломав кому-то сборку), либо просто не сможете не продублировав весь набор скриптов и/или не превратив его в include лапшу. И это будет не требуя от вас вообще никаких затрат развиваться и поддерживать новые возможности существующего инструментария и новые инструменты.


Так что, вашими же словами, CMake настолько впечатлил life-changing простотой, гибкостью и куда лучшим выполнением задач сборки, что я во всех своих проектах им полностью заменил make (вместе с qmake, scons, autotools) и точно не поменяю на redo.


Помимо сборки софта, в простых случаях я однозначно предпочту make, только за то что его все знают (POLA) и за наглядность (один файл, удобное задание переменных для подстановки (=, ?=, += без лишних скобок и кавычек), далее все цели в одном месте). Для простых, повторюсь, случаев есть небольшое общее подмножество GNU/BSD синтаксисов с которым make по прежнему везде есть, и перечисленные вами минусы неактуальны, так что остаются только плюсы.


Вот примеры таких Makefile для наглядности:
https://github.com/repology/repology-logo/blob/master/Makefile
https://github.com/repology/repology-linkchecker/blob/master/Makefile


А вот прям сложные случаи сборки не-софта, с разветвлённым деревом зависимостей и разнообразными процессами, требующими вызова внешних утилит — тут да, можно и рассмотреть redo.

Корзинка с сюрпризами — cпасите наши push'и

почему Git, работающий временами с довольно таки неочевидной логикой, настолько популярнее гораздо более логичного Mercurial

Может потому что как раз с логикой там всё в порядке, а если вы к чему-то привыкли не значит что это единственный и тем более единственно верный вариант того как может быть?


Мой опыт работы с mercurial начался с непозволительно медленной для VCS последнего поколения работы с большим репозиторием, сильного удивления от закрытых веток и в итоге попадания в multihead состояние, которое я с ходу не разобрался как разрешить, на том и закончился. Просто как пример того что оценка очевидности субъективна.


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

Так работают с любой VCS, когда не требуют от неё быть другой VCS.


один из столпов сопротивления мейнстриму в системах контроля версий

О как. А какой смысл в этом сопротивлении? Последствий кроме усложнения взаимодействия разработчиков я не вижу.

Корзинка с сюрпризами — cпасите наши push'и

видны будут все перипетии работы над кодом

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


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

Это не прерогатива поклонников Git, поклонники mercurial всегда хвалились MQ, Evolve и подобными расширениями.

List Comprehension vs Map

Упустили как минимум generator expressions и обычные генераторы (с yield).

Писатели, пираты и пиастры

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

Можно также допустить и другую мысль, о том что устарело представление о обязательности/необходимости оплаты (в классическом понимании, деньгами) за определённые виды контента. Примеров этому тоже достаточно, например СПО, Википедия и OSM.

Не пора ли к мозгоправу?

"Нормальных" не существует.

Не пора ли к мозгоправу?

У вас собирательный образ обычного разработчика с талантом и эрудицией выше среднего. Собрались лечить всех разработчиков или сам образ?

Беседа о справедливой экономике

Я это и сам выше процитировал. На вопрос вы не ответили.

Используйте __main__.py

Ставить как нативные для системы особого смысла нет.

Не будь смысла, опакечивание Python модулей не было бы распространено повсеместно: https://repology.org/projects/?search=python%3A


Лишняя возня со сборкой, а премуществ никаких особо и нет.

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

Используйте __main__.py

или в pypi, или в нативный пакет для операционной системы

Я ни разу не встречал проблем с опакечиванием питоновых приложений хоть с PyPI, хоть напрямую с GitHub — setup.py делает всё что нужно и создаёт исполняемые файлы в bin — это работает и c __main.py__, и со скриптами.


Проблема, повторюсь, возникает при работе с репозиторием, потому что с __main__.py скриптов в нём не будет и чтобы пользоваться приложением из чекаута репозитория вам придётся, по сути, сначала руками распарсить entry_points из setup.py, или искать __main__.py.

Используйте __main__.py

Скрипт можно запускать точно так же, причём на 1 аргумент короче.

Используйте __main__.py

Никакого геморроя. Много кто так и делает, см., например, ansible и black.

Информация

В рейтинге
Не участвует
Откуда
Москва, Москва и Московская обл., Россия
Дата рождения
Зарегистрирован
Активность