Pleroma 1.0

Кстати, мы ведь понимаем, что само по себе позволение системе обновляться — это уже дыра? (испуганно) Или не понимаем?

Конечно. А запрет обновляться — тоже дыра.

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

В pleroma, diaspora или им подобным есть личные сообщения?

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

Поподробнее можно?

Эта централизованная помойка деградирует с каждым годом

Так я об этом и написал.

А чем лучше, ну как минимум централизованностью. Для таких вещей как twitter, как по мне, лучше когда все прямо вот сейчас варятся в одном котле.

В pleroma, diaspora или им подобным есть личные сообщения?

да

Для таких вещей как twitter, как по мне, лучше когда все прямо вот сейчас варятся в одном котле.

Что вы имеете в виду?

Я о проблеме получения контента по тегам. Это лишь мое дилетантское мнение, сложенное из того, что было прочитано о фидеративных сетях. На практике не проверял.

Я о проблеме получения контента по тегам

Какой проблеме?

Не подписывается на Вас :(

Ministry of Moonbutt Science Error: Something went wrong.

если макака спокойно сидит на пальме и жуёт свой банан, в веб не лезет, к компьютеру не подходит

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

Давайте посмотрим, как там.

Ага, значит это меня обманули, а не вас. Вынужден признать, что здесь я полагался не на свой опыт, а на чужой — а там, по ходу, тупо не разобрались.

Да, конечно, на си хэлловорлд займёт от силы полтора десятка килобайт.

При статической линковке с мейнстримной GNU libc — увы, намного больше. К счастью, есть другие варианты libc.

А вот на ручное управление памятью и конструирование списков на указателях у них никакого энтузиазма не хватит.

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

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

Ага, значит это меня обманули, а не вас. Вынужден признать, что здесь я полагался не на свой опыт, а на чужой — а там, по ходу, тупо не разобрались.

Возможно, что этот чужой опыт просто устарел. Разработчики Chicken’а относительно недавно выпустили 5-ю версию, в которой много чего поменяли. Как было в 4-й сказать не могу — не знаю.

Про тот же Common Lisp. В качестве примера, есть gopher-клиент на лиспе, clic. Если его собирать при помощи ECL, то получаем следующее:

$ ldd /usr/local/bin/clic | awk '/\/usr\//{print $7}' | xargs -n1 ls -lh
-rwxr-xr-x  1 root  bin   5.4M Apr 14 23:44 /usr/local/bin/clic
-rw-r--r--  1 root  bin   3.6M Apr 14 23:35 /usr/local/lib/libecl.so.6.0
-rw-r--r--  1 root  bin   628K Apr 14 03:56 /usr/local/lib/libgmp.so.10.0
-rw-r--r--  1 root  bin   264K Apr 14 06:56 /usr/local/lib/libgc.so.4.0
-rw-r--r--  1 root  bin  44.7K Apr 14 03:48 /usr/local/lib/libffi.so.1.2
-r--r--r--  1 root  bin   134K Apr 13 23:35 /usr/lib/libpthread.so.26.1
-r--r--r--  1 root  bin   636K Apr 13 23:35 /usr/lib/libm.so.10.1
-r--r--r--  1 root  bin   3.6M Jul  5 16:21 /usr/lib/libc.so.95.0
-rw-r--r--  1 root  bin  16.0K Apr 14 06:56 /usr/local/lib/libatomic_ops.so.2.0
-r--r--r--  1 root  bin   288K Jul  5 16:21 /usr/libexec/ld.so

Опять же, никаких «вооооот таких» динамических либ нету. Ну да, бинарник с libecl.so в сумме занимает под десяток мегабайт, но это не так уж и много. Конечно, будучи написанным на Си, бинарник gopher-клиента будет раз в 100 меньше. Но зато исходный текст будет в несколько раз объёмнее за счёт перегруженности низкоуровневыми деталями, так что никто не захочет его читать (да и писать, вероятно, тоже).

Тут дело в чём, и для интерпретируемого исполнения, и для «очень высокоуровневых языков» (ну, если речь не про питон) в принципе ниша есть, и даже не одна.

Во-первых, есть скриптинг

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

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

я считаю неприемлемыми любые runtime dependencies

Т.е., приемлемо ли использовать, например, Хаскелл или Go или ChickenScheme для создания широко распространяемых (в отличие от перечисленных вами случаев) программ, если они будут при этом зависеть только от нескольких стандартных системных библиотек? Если нет, то почему (критерий runtime dependencies мы уже исключили)?

разработчик на голубом глазу создаёт лишние проблемы толпе людей, чтобы сэкономить себе чуть-чуть усилий.

Кстати, используя «очень высокоуровневый язык», разработчик экономит усилия не только себе, но и тем людям, которые будут его программу читать. А это, сдаётся мне, одна из больших проблем современного open source — программы очень много пишут, но очень мало читают.

Для тех кто непонял, Mastadon инстансы могут спокойно говорить с Pleroma и наоборот!

Так напиши на своем кашерном C++ никто тебя недержит!

Опять же, никаких «вооооот таких» динамических либ нету. Ну да, бинарник с libecl.so в сумме занимает под десяток мегабайт

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

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

Если на чистом Си — то да. Если на C++, то там можно даже даже вот так. На всякий случай — нет, я не сторонник того монстра, которого сейчас обычно называют «C++»; я пользуюсь очень жёстким подмножеством, не включающим, в частности, стандартную библиотеку (всю). Даже такого подмножества хватает, чтобы используемые (как правило, созданные под конкретную задачу) абстракции были сколь угодно высокоуровневыми.

я всё пытаюсь понять вашу позицию относительно использования «очень высокоуровневых языков» вне описанных вами ниш

Это несколько сложно. Попробуем разобраться.

если они будут при этом зависеть только от нескольких стандартных системных библиотек?

Нет, тут всё плохо. Зависимость от динамических библиотек означает непереносимость бинарников, то есть мне, чтобы на хостинговой системе получить написанную на «этом» программу, нужно «это» (хаскель, схему, гоу, не важно) поднять либо на самом сервере, либо на системе, слепленной локально и повторяющей ту, что на сервере, с точностью до версий всех библиотек.

Иной вопрос, если будет возможна статическая сборка, то есть бинарник не будет зависеть ни от чего от слова совсем от слова вообще. Только от команд процессора и сисколлов ядра. Тогда, пожалуй, я дома возьму какой-нибудь центос или дебиан (а скорее вообще-то devuan, я в основном его использую), под ним поставлю все нужные для сборки пакеты, соберу софтину и полученный бинарник залью на сервер.

Вообще-то, конечно, всё равно это неудобно, то есть нетривиальные build-time deps тоже создают неудобства, но тут уж дело в чём — если я допускаю Паскаль (хотя его реализация — тоже штука не совсем обычная на *nix-машинах), то с чего бы мне не допустить другие языки. Лишь бы на выходе получался самодостаточный бинарник. Да, блин, статический — строго. Никаких зависимостей от библиотек, сколь бы «стандартными» они ни были.

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

Кстати, используя «очень высокоуровневый язык», разработчик экономит усилия не только себе, но и тем людям, которые будут его программу читать

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

одна из больших проблем современного open source — программы очень много пишут, но очень мало читают.

Кто б с этим спорил, гм...

Так напиши на своем кашерном C++ никто тебя недержит!

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

А статически это всё собрать можно?

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

И если да, то какого размера бинарь получится?

Вряд ли больше, чем сумма размеров динамически слинкованного бинарника и либ. То есть, порядка 10Мб.

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

Покопался из любопытства с ChickenScheme. Поскольку она компилирует через промежуточную трансляцию в Си, то вклиниться в этот процесс и задать полностью статическую линковку оказалось несложно.

Хелловорлд:

$ objdump -p hw | grep NEEDED
$ du -sh hw
1.2M    hw

Чуть менее тривиальный (с подключёнными сторонними модулями) пример, который лезет в веб по HTTP и разбирает полученный JSON:

$ objdump -p somafm-chicken | grep NEEDED
$ du -sh somafm-chicken
6.4M    somafm-chicken

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

Никаких зависимостей от библиотек, сколь бы «стандартными» они ни были.

Ок, вашу идею я понял и согласен с ней. Я и сам считаю, что когда изобрели динамическую линковку, индустрия IT в очередной раз свернула куда-то не туда.

Всё это не отменяет, например, того, что тот же Go я нахожу неприемлемым с другой точки зрения

Ну про Go понятно: насколько я помню, вы считаете бессмысленным сочетание императивности и сборщика мусора. А что насчёт приемлемости Хаскелла, Лиспа/Схемы, OCaml и прочих? При условии, конечно, что они умеют компилировать в абсолютно статически слинкованный нативный код.

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

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

Да это всё понятно и очевидно. Опытный программист на Фортране безусловно может написать программу на Фортране на любом языке.

Однако, правильно использованные абстракции позволяют писать короче и не перегружать текст низкоуровневыми деталями. То есть, при наличии вкуса и самодисциплины программа на Хаскелле или Лиспе таки получится заметно короче и будет, соответственно, читаться легче, чем на Си.

Но да, моё высказывание нуждается в уточнении: используя «очень высокоуровневый язык», разработчик имеет больше возможностей сэкономить усилия не только себе, но и тем людям, которые будут его программу читать. Хотя, конечно, не факт, что он эти возможности правильно использует.

А что насчёт приемлемости Хаскелла, Лиспа/Схемы, OCaml и прочих? При условии, конечно, что они умеют компилировать в абсолютно статически слинкованный нативный код.

Простите, а какого ответа вы от меня ожидаете? Если что, я всю свою научную жизнь занимаюсь парадигмами программирования, руковожу одноимённым спецсеминаром, до недавнего времени читал лекции по курсу «Парадигмы программирования», и всё тот же четвёртый том, судя по всему, будет называться просто «Парадигмы». При этом одна из частей там будет посвящена языкам, ориентированным (условно) на неразрушаемые данные, правда, там набор рассматриваемых языков может показаться неожиданным — Lisp, Scheme, Prolog, Refal, Hope (нет, не говорите мне про Haskell, не надо :) ) Сейчас вот как раз прологовскую главу пытаюсь допилить, пилится с трудом, но не она первая, не она последняя.

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

stalin в этом ИТТ треде уже обсуждали?

Владимир

Haskell? Scheme? OCaml? Вас нае... эээ... обманули, они «компилируются» в сишный текст, который потом превращается в бинарник, зависящий от воооооооот таких динамических либ.

В Haskell'е и OCaml'е не ковырялся

Суть лора. Не ковырялся, но херню несет. У обоих нативный компилятор, генерирующий нативный код. Оба прекрасно компилируются статически, если надо — c musl.

Scheme

У схемы 666 разных имплементаций, компилирующих во что угодно, от байткода (racket) до си (chicken) и нативщины (chez) с самыми разнообразными зависимостями.

Ок, вашу идею я понял и согласен с ней. Я и сам считаю, что когда изобрели динамическую линковку, индустрия IT в очередной раз свернула куда-то не туда.

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

В итоге имеет. Helloworld на лисп:

-rwxr-xr-x 1 user user 42M Jul 15 17:25 hello-lisp

-rwxr-xr-x 1 user user  78 Jul 15 17:26 hello-python.py

docker image ls | head
REPOSITORY                                                                  TAG                 IMAGE ID            CREATED             SIZE
hello-python                                                                latest              d4d0d0d2573c        14 seconds ago      98.6MB

То есть. Питоновский вариант вдвое жырнее лиспового. И, да, наслаждайтесь вашим хелловорлдом за 100 мегабайт.

У обоих нативный компилятор, генерирующий нативный код. Оба прекрасно компилируются статически, если надо — c musl.

Я, в принципе, даже готов признать, что нёс херню, ну мало ли, я же не всё знаю, что в мире происходит. Только у меня условие. Давайте сюда пошаговые инструкции для известных вам инструментов, допускающих статическую компиляцию и сборку с musl'ом для неимперативных языков. И выдачу ls -l для бинарника, реализующего... эээ.. нет, не Hello world, это слишком просто; пусть этот бинарник реализует echo, т.е. печатает аргументы своей командной строки. Ну и для того же бинарника выдачу file, чтоб убедиться, что он действительно статический.

Вопрос не праздный - мне нужен иллюстративный материал для книги. Пока что куда я ни тыкался, вместо компиляции видел издевательство какое-то. А изучать все

666 разных имплементаций

- жизни не хватит.

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

Ну и для того же бинарника выдачу file, чтоб убедиться, что он действительно статический.

Не любой file рассказывает, статический бинарник или динамический. OpenBSD’шный, например, не рассказывает.

Более универсально: objdump -p <file> | grep NEEDED или, на крайняк, ldd («на крайняк» потому, что привыкать пользоваться ldd я бы не рекомендовал из-за его проблем с безопасностью).

Вопрос не праздный - мне нужен иллюстративный материал для книги.

Более подробные пошаговые инструкции для моего примера с Chicken Scheme нужны?

Только что попробовал с OCaml из любопытства. Оказалось до безобразия просто:

$ cat echo.ml
print_string (String.concat " " (List.tl (Array.to_list Sys.argv)));;
print_newline ()
$ ocamlopt.opt -ccopt -static echo.ml -o echo
$ du -sh echo
1.8M    echo
$ objdump -p a.out | grep NEEDED
$ ldd a.out
a.out:
        Start            End              Type  Open Ref GrpRef Name
        0000078100b35000 0000078100bfa000 dlib  1    0   0      /home/username/work/ocaml/echo
$ file echo
echo: ELF 64-bit LSB shared object, x86-64, version 1
$ ./echo a b c
a b c

Из доки к OCaml:

-ccopt option
    Pass the given option to the C compiler
    and linker. For instance, -ccopt -Ldir causes
    the C linker to search for C libraries in
    directory dir.

С musl’ом помочь не могу, у меня OpenBSD, тут musl не актуален. Но, думаю, полистав доку по ссылке, можно минут за 10 соорудить подходящие опции и для musl.

давайте бартер

Лично меня бартер не итересует, ради книги я вполне бескорыстно готов помочь. Так что, если нужно что-нибудь уточнить — спрашивайте.

А, да, забыл:

$ strip echo
$ du -sh echo
688K    echo

Более подробные пошаговые инструкции для моего примера с Chicken Scheme нужны?

Да, если не сложно.

Пример с OCaml впечатляет — результат по размеру получился сравнимый с тем, что получается из Си с использованием glibc (да, я знаю, что это негодный жирный монстр, но и OCaml не ассемблер). Я OCaml рассматривать в книге не планировал, теперь вот уже сомневаюсь.

echo на Chicken Scheme:

$ cat echo.scm
(import (chicken process-context)
        (chicken string))
(display (string-intersperse (command-line-arguments) " "))
(newline)
$ csc -static -L -static echo.scm
$ ./echo a b c
a b c
$ objdump -p echo | grep NEEDED
$ du -sh echo
3.2M    echo
$ strip echo
$ du -sh echo
2.3M    echo

Здесь первый -static — это опция самого Chicken, а -L <опция> — значит передать <опцию> сишному линкеру.

Далее, размер бинарника можно ещё уменьшить с помощью опции -explicit-use (в 5-м Chicken её правильнее было бы называть explicit import). Эта опция, если я правильно понимаю, отключает неявный импорт стандартных модулей, поэтому что-то придётся указать явно:

$ cat echo-explicit.scm
(import r5rs
        (chicken process-context)
        (chicken string))
(display (string-intersperse (command-line-arguments) " "))
(newline)
$ csc -static -L -static -explicit-use echo-explicit.scm
$ ./echo-explicit a b c
a b c
$ objdump -p echo-explicit | grep NEEDED
$ du -sh echo-explicit
2.0M    echo-explicit
$ strip echo-explicit
$ du -sh echo-explicit
1.2M    echo-explicit

Ещё есть полезные опции -v, -vv и -vvv, которые, с соответственно возрастающей информативностью, показывают, что делает компилятор csc (в частности, с какими параметрами он вызывает сишный компилятор).

Для интереса на Haskell:

# cat Main.hs
module Main where
import Data.List
import System.Environment
main = intercalate " " <$> getArgs >>= putStrLn
# ghc Main.hs -optl-static -o a.out
Linking a.out ...
/usr/lib/ghc/rts/libHSrts.a(Linker.o): In function `internal_dlopen':
(.text+0x397): warning: Using 'dlopen' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
# du -hs a.out
2.7M	a.out
# strip a.out
# du -hs a.out
1.9M	a.out
# objdump -p a.out | grep NEEDED
# ldd a.out
	not a dynamic executable
# file a.out
a.out: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), statically linked, for GNU/Linux 3.2.0, BuildID[sha1]=c7fd33c327038c2bbf126bf60089ab2885093daa, stripped
# ./a.out  abc  def
abc def

Насчет musl не знаю, но гугление «haskell ghc musl» показывает, что люди это делают, причем именно для static linking.

Пример с OCaml впечатляет

Я OCaml рассматривать в книге не планировал, теперь вот уже сомневаюсь.

Кстати, вспомнилось мне, что есть такая, довольно старая уже, книжка: Unix system programming in OCaml.

известных вам инструментов, допускающих статическую компиляцию и сборку с musl'ом для неимперативных языков

https://opam.ocaml.org/packages/ocaml-variants/ocaml-variants.4.07.1 musl sta...

«+musl+static» намекает.

`opam init && opam switch create musl ocaml-variants.4.07.1+musl+static+flambda` чтоб поставить.

Ну хорошо, про OCaml признаю, что нёс херню. Но OCaml'а в книжке всё-таки, видимо, не будет. Про что-нибудь ещё инструкции есть? Исходно вы вроде бы не только об OCaml'е говорили, когда заявляли, что я херню несу.