LINUX.ORG.RU

Pleroma 0.9.9

 , , , ,

Pleroma 0.9.9

3

4

Спустя три года разработки представлен первый стабильный выпуск Pleroma версии 0.9.9 — федеративной социальной сети для микроблогинга, написанной на языке Elixir и использующей стандартизированный W3C протокол ActivityPub. Это вторая по численности сеть в Fediverse.

В отличие от ближайшего конкурента — Mastodon, который написан на Ruby и зависит от большого количества ресурсоёмких компонентов, Pleroma является высокопроизводительным сервером, который может работать на маломощных системах, таких как, например, Raspberry Pi или дешёвых VPS.

Также Pleroma реализовывает Mastodon API, позволяя быть совместимой с альтернативными клиентами Mastodon, типа Tusky или Fedilab. Более того, с Pleroma поставляется ответвление исходного кода интерфейса Mastodon, что делает более плавным переход пользователей из Mastodon или Twitter с интерфейсом TweetDeck. Обычно он доступен по URL вида https://instancename.ltd/web.

Из прочего можно отметить:

  • использование ActivityPub для внутренней работы (Mastodon использует свою вариацию);
  • произвольное ограничение на количество символов в сообщении (по умолчанию 5000);
  • поддержку разметки с помощью Markdown или HTML-тегов;
  • добавление своих собственных эмодзи со стороны сервера;
  • гибкую настройку интерфейса, позволяющую произвольно изменять его элементы с пользовательской стороны;
  • фильтрацию сообщений в ленте по ключевым словам;
  • автоматические операции над загружаемыми изображениями с помощью ImageMagiсk (например, удаление EXIF-информации);
  • предпросмотр ссылок в сообщениях;
  • поддержку капчи с помощью Kocaptcha;
  • пуш-уведомления;
  • закреплённые сообщения (пока что только в интерфейсе Mastodon);
  • поддержку проксирования и кэширования статусов с вложениями из внешних серверов (по умолчанию клиенты обращаются к вложениям напрямую);
  • множество других гибко настраиваемых опций, которые можно применить к серверу.

Из интересных экспериментальных особенностей можно отметить поддержку протокола Gopher.

>>> Подробности

★★★★★

Проверено: Shaman007 ()
Последнее исправление: commagray (всего исправлений: 3)

Ответ на: комментарий от anonymous

*LOL*

это потому, что ты ничего другого не заешь? да и с С ты знаком понаслышке , судя по всему

Ты, это, на LOR первый день? :-D Те, кто не первый день, знают, кто я такой (если что, в помощь тебе ссылочки из моего профиля)

Croco ★★★
()
Ответ на: комментарий от hobbit

А ты какие-нибудь функциональные языки вообще годными считаешь (годными как вообще, так и для серверного применения в частности)?

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

Есть одно утверждение, за которое я уверен: зависимости — зло. Единственная допустимая зависимость времени исполнения — ядро ОС; допустимые зависимости времени сборки — компилятор и make (и всё, все библиотеки должны быть в дереве исходников проекта, раньше я для libc делал исключение, сейчас уже и в этом сомневаюсь).

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

Это не значит, что такие реализации невозможны. Просто сейчас их нет.

Croco ★★★
()
Ответ на: комментарий от Croco

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

Ну я сразу понял, что лёгкого ответа в контексте этого разговора не будет. Спасибо.

hobbit ★★★★★
()
Ответ на: комментарий от Croco

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

Thero ★★★★★
()
Ответ на: комментарий от Thero

Если нет возможности пересобрать статическое приложение, то откуда возьмётся возможность собрать интерпретатор? Или он, интерпретатор этот, там «уже есть»? Ну так вот я и говорю, а что делать, если его нет.

Croco ★★★
()
Ответ на: комментарий от Croco

сервера этой федеративной сети должны быть в установке и администрении проще пареной репы

Куда уже проще docker run ...

Проблема ActivityPub-соцсетей ИМХО в том, что они не решают проблему отправки котиков своим френдам лучше/удобнее/быстрее, чем это на данный момент делает абстрактный фейсбук.

Ну а с админами-хоббистами есть проблемы от даунтайма из-за просроченой оплаты аренды впски до фактора автобуса.

Singularity ★★★★★
()
Ответ на: комментарий от Singularity

Ну а с админами-хоббистами есть проблемы от даунтайма из-за просроченой оплаты аренды впски до фактора автобуса.

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

Croco ★★★
()
Ответ на: комментарий от Croco

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

Thero ★★★★★
()
Ответ на: комментарий от Thero

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

Ага-ага, в теории всё именно так. На практике интерпретаторы бывают разных версий, их поведение внезапно меняется при переходе от одной платформы к другой, то и дело не хватает каких-нибудь «библиотек», попытка загрузить недостающие из какого-нибудь очередного cpan.org приводит к конфликту и драке, и всё такое прочее. Я уже молчу о том, что под ту же винду интерпретатор в одну команду не поставишь, там apt-get install не завезли; и под nix'ами, если сделать шаг в сторону от мейнстрима, оказывается, что для запуска какой-то новой приблуды интерпретатор её языка придётся собирать самому. Больше того, интерпретатор может внезапно подраться с чем-то, что у пользователя на машине есть, а у разработчика не было. И далее везде.

В общем, практика показывает, что этак вот гладко бывает только в теории.

все эти задачи можно разделить между разработчиками разной квалификации и специализации.

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

Croco ★★★
()
Ответ на: комментарий от Croco

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

Thero ★★★★★
()
Ответ на: комментарий от Thero

какие сложнее для тех кадров что у нас есть

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

какие риски проще контролировать

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

Croco ★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.