Doomed to Wordpress (circa 1993)

2020/11/20 perl coverage

Памятка. Coverage для отдельного теста:

perl -MDevel::Cover t/require.t
cover

#perl #coverage


[
] permanent link

2020/11/20 freebsd git

Понадобилось поставить git на FreeBSD. Пакет тянет около 20 зависимостей, решил собирать из портов. И такого кривого порта, как этот git, я в жизни не видывал. Такое впечатление, что делали его люди из какой-то параллельной вселенной, никогда не пользовавшиеся FreeBSD. Всё не как у людей. В частности, make config начисто игнорировался, при запуске make повторно предлагался config, заданные там настройки тоже игнорировались. Догадался обновить дерево портов, оказалось, порт исправили, но удивительно, как такое вообще могло попасть в дерево?!

#git


[
] permanent link

2020/11/15 plone dexterity

Имеется инсталляция Plone, установленная из Plone-5.2.1-UnifiedInstaller-r3 в основном ради исследования реализации связей между объектами в ZODB. Создал Dexterity content type, одно из полей которого ссылается на объект другого типа. При редактировании объекта, однако, поле невозможно заполнить, вылезает невразумительная ошибка, которая в веб-форме отображается как "Loading failed", а в логе как "ValueError: value or token must be provided (only one of those)". Поиск показал, что проблема была известна уже в июле 2019 года и что она возникает именно при adding a Dexterity content type which includes a RelationChoice field in conjunction with the IDublinCore behavior creators (possibly also contributors) (https://community.plone.org/t/plone-5-2-rc5-issue-with-relationchoice-field/8776). Действительно, отключение поведения IDublinCore её решило. Высказано предположение, что ошибка возникла при обновлении до Python 3 (почему я не удивлён? Как бы то ни было, ошибка такого рода не единственная: https://github.com/plone/plone.app.theming/pull/163). По всей видимости, проблема описана и обсуждается тут: https://github.com/plone/plone.app.vocabularies/issues/59, обсуждалась в течение года, наконец, кажется, исправлена в августе 2020 (через год). Не изучал внимательно, попало ли исправление в релизы. Само по себе ужасно, что система целый год оставалась практически негодной к использованию, и никто этого не замечал и не жаловался, кроме нескольких человек, участвующих в обсуждениях, указанных выше! Ибо, собственно, без типов контента CMS смысла не имеет, тем более такая, где всё построено вокруг них. Если даже в одной из лучших CMS возможно такое, что̀ говорить про другие?!

#plone #python3

UPD. Вот ещё в том же духе (https://community.plone.org/t/can-you-make-a-ttw-dexterity-content-type-that-is-not-folderish/2195):

"TTW content-types being folderish is a known misconception in Plone 5. This issue has been reported and discussed but there does not seem to be anyone interested changing this misconception...so take it as it is."


[] permanent link

2020/11/14 ssl bump

Настроил-таки ssl bump на squid. Я, честно говоря, давно уже в ярости из-за нынешнего как навязывания https, так и навязывания отдельных версий SSL/TLS или бойкотирования других. Нет никакого смысла гонять все данные по защищённым соединениям. Бдительность от этого только усыпляется. Все мы помним времена, когда у всех были ещё самоподписанные сертификаты и мы приучились их принимать на автомате, вообще не заглядывая никуда. Пользователь должен сам понимать, какие данные есть смысл передавать по защищённому соединению, какие нет. И иметь возможность самостоятельно управлять передачей данных по тому или другому. Если он этого не понимает, он всё рано или поздно станет жертвой кибермошенников, не из-за https, так из-за чего-нибудь другого. Всё это навязывание защищённых протоколов только усугубляет нынешнюю тотальную компьютерную безграмотность, человек не учится понимать ни как устроена сеть, ни когда соединение защищено, когда нет, ни вообще что̀ такое защита и соединение. Это часть ненормальной привязанности к постоянной, не зависящей от твоих собственных усилий безопасности и комфорту, которая проявляется и в других сферах жизни (например, в той же мнимой "пандемии").

Так или иначе, у меня есть несколько устройств, на которых https уже некоторое время толком не работает, так как они не поддерживают современные версии TLS, а сервера постепенно перестают поддерживать старые. Одно из них — это Nokia N900, другое — временный комп со Slackware 12, которую я скоро снесу, но пока с нею играюсь. В первом случае мне некогда осваивать портирование современного openssl на Maemo и весь инструментарий разработчика (давно хотел это сделать, но, похоже, так и не найду времени), во втором — хочется иметь дело с оригинальной системой в том виде, как она была задумана, выпущена и использовалась людьми прошлого (и печально, что в таких выражениях приходится говорить о времени всего 10 лет назад).

Генерируем ключи:

$ openssl req -new -newkey rsa:2048 -sha256 -days 3650 -nodes \
-x509 -extensions v3_ca -keyout squid-ca-key.pem -out \
squid-ca-cert.pem
$ cat squid-ca-cert.pem squid-ca-key.pem >> squid.pem
# mkdir /usr/local/etc/squid/certs
# mv squid.pem /usr/local/etc/squid/certs/
# chown squid:squid -R /etc/squid/certs

Опцию sslcrtd_program /usr/local/libexec/squid/security_file_certgen -s /var/squid/cache/ssl_db -M 4MB не добавлял, так как данное значение по умолчанию меня пока устраивает. Однако пришлось вручную создать хранилище /var/squid/cache/ssl_db, иначе squid не запускался:

# /usr/local/libexec/squid/security_file_certgen -c -s \
  /var/squid/cache/ssl_db -M 4MB

В squid.conf добавляем следующее:

acl step1 at_step SslBump1
acl step2 at_step SslBump2
acl step3 at_step SslBump3

http_port 3129 ssl-bump cert=/usr/local/etc/squid/certs/squid.pem \
      generate-host-certificates=on version=1

sslproxy_cert_error allow all
tls_outgoing_options flags=DONT_VERIFY_PEER

ssl_bump bump step1 all

(взято в основном отсюда: https://stackoverflow.com/questions/34398484/can-i-use-squid-to-upgrade-client-tls-connections, я добавил sslproxy_cert_error и tls_outgoing_options).

Проверяем конфиг squid: squid -k parse.

Чтобы браузер клиента не ругался, генерируем сертификат и импортируем его туда:

openssl x509 -in /usr/local/etc/squid/certs/squid.pem -outform DER -out squid.der

Проблему с Нокией полностью решить пока не удаётся. В about:config браузера Нокии нужные мне параметры называются network.proxy.ssl, network.proxy.ssl_port, network.proxy.type (1, иначе прокси не работает!), network.proxy.no_proxies_on. Однако proxy.type сбрасывается в 0 при закрытии окна, в котором был запущен about:config, и при переподключении! См. https://talk.maemo.org/showthread.php?t=85497.


[] permanent link

2020/11/14 paul graham

http://www.paulgraham.com/noop.html

"Object-oriented programming is popular in big companies, because it suits the way they write software. At big companies, software tends to be written by large (and frequently changing) teams of mediocre programmers. Object-oriented programming imposes a discipline on these programmers that prevents any one of them from doing too much damage. The price is that the resulting code is bloated with protocols and full of duplication. This is not too high a price for big companies, because their software is probably going to be bloated and full of duplication anyway."

"Object-oriented programming generates a lot of what looks like work. [...] Something that a Lisp hacker might handle by pushing a symbol onto a list becomes a whole file of classes and methods. So it is a good tool if you want to convince yourself, or someone else, that you are doing a lot of work."


[] permanent link

2020/11/14 32 vs 64 bit

На одной машине:

$ uname -a
FreeBSD zayats 11.4-RELEASE-p3 FreeBSD 11.4-RELEASE-p3 #0: Tue Sep  1 07:47:00 UTC 2020     root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC  i386

$ perl -v

This is perl 5, version 24, subversion 4 (v5.24.4) built for i386-freebsd
(with 1 registered patch, see perl -V for more detail)

$ perl -V | fgrep size
    intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234, doublekind=3
    d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12, longdblkind=3
    ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8

$ ./script/gt_fastcgi.pl -l /tmp/gt.socket -n 2 -p /tmp/gt.pid --daemon &

$ ps auxww | fgrep fcgi
rp     8784   0,0 25,4 135028 125480  —  Is   23:04           0:00,16 perl-fcgi-pm [GT] (perl)
rp     8785   0,0 25,4 135028 125480  —  I    23:04           0:00,01 perl-fcgi (perl)
rp     8786   0,0 25,4 135028 125480  —  I    23:04           0:00,01 perl-fcgi (perl)
rp     8790   0,0  0,3   6372   1488  1  S+   23:06           0:00,02 fgrep fcgi

$ fgrep memory /var/run/dmesg.boot
real memory  = 536870912 (512 MB)
avail memory = 493191168 (470 MB)

На другой:

$ uname -a
FreeBSD my.host.name.ru 12.1-RELEASE FreeBSD 12.1-RELEASE r354233 GENERIC  amd64

$ perl -v

This is perl 5, version 24, subversion 4 (v5.24.4) built for amd64-freebsd
(with 1 registered patch, see perl -V for more detail)

$ perl -V | fgrep size
    intsize=4, longsize=8, ptrsize=8, doublesize=8, byteorder=12345678, doublekind=3
    d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16, longdblkind=3
    ivtype='long', ivsize=8, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8

$ ./script/gt_fastcgi.pl -l /tmp/gt.socket -n 2 -p /tmp/gt.pid --daemon &

$ ps auxww | fgrep fcgi
gt    75231  0,0 11,0 241468 225924  —  Is   23:10             0:00,08 perl-fcgi-pm [GT] (perl)
gt    75232  0,0 11,0 241468 225920  —  I    23:10             0:00,00 perl-fcgi (perl)
gt    75233  0,0 11,0 241468 225924  —  I    23:10             0:00,00 perl-fcgi (perl)
gt    75235  0,0  0,0    524    336  0  R+   23:10             0:00,00 fgrep fcgi

$ fgrep memory /var/run/dmesg.boot
real memory  = 2147483648 (2048 MB)
avail memory = 2043199488 (1948 MB)

Всё, что̀ нужно знать о "преимуществах" 64-битной архитектуры.

Та же проблема и возможное решение: https://gundersen.net/32bit-jail-on-64bit-freebsd/


[] permanent link

2020/11/13 microsoft python

Почему все технологии, которые я недолюбливаю, стекаются в одно место?! И вообще, конечно, поразительно, неужели на пенсии нечем заняться, кроме как снова работать?

https://www.opennet.ru/opennews/art.shtml?num=54076

"Гвидо ван Россум, создатель языка программирования Python, сообщил, что ему надоело сидеть на пенсии и он принял предложение о работе в подразделении разработки компании Microsoft. Напомним, что в январе 2021 года года Гвидо исполнится 65 лет. В прошлом году он покинул компанию Dropbox и сообщил о выходе на пенсию."


[] permanent link

2020/11/03 mysql foreign keys

Показать внешние ключи, ссылающиеся на таблицу:

SELECT
    TABLE_NAME,
    COLUMN_NAME,
    CONSTRAINT_NAME,
    REFERENCED_TABLE_NAME,
    REFERENCED_COLUMN_NAME
FROM
    INFORMATION_SCHEMA.KEY_COLUMN_USAGE
WHERE
    REFERENCED_TABLE_SCHEMA = 'db_name' AND REFERENCED_TABLE_NAME = 'table_name';

На столбец:

SELECT
    TABLE_NAME,
    COLUMN_NAME,
    CONSTRAINT_NAME,
    REFERENCED_TABLE_NAME,
    REFERENCED_COLUMN_NAME
FROM
    INFORMATION_SCHEMA.KEY_COLUMN_USAGE
WHERE
    REFERENCED_TABLE_SCHEMA = 'db_name'
    AND REFERENCED_TABLE_NAME = 'table_name'
    AND REFERENCED_COLUMN_NAME = 'column_name';

Source: https://tableplus.com/blog/2018/08/mysql-how-to-see-foreign-key-relationship-of-a-table.html

#mysql


[] permanent link

2020/10/24 pkgsrc c++11

Взялся теперь собирать inkscape. Постепенно прихожу к выводу, что pkgsrc всё же годится для мелких консольных программ, не для сложных и графических (lynx ранее собрался быстро и вообще без проблем). И опять источник бед — новшества и нестандартные средства сборки. В данном случае пришлось столько помучиться с c++11, что в конце концов я вынужден был явно добавить в /usr/pkg/etc/mk.conf:

GCC_REQD+=     5

(где-то в зависимостях было видимо указано gcc5, но крайне сложно проверить их все, чтобы понять, где) — потому что по умолчанию почему-то c++11 в USE_LANGUAGES никак не переключает версию gcc. Способа задать что-то подобное для любых пакетов, но только при определённых условиях (.if !empty(USE_LANGUAGES:Mc++11) или вообще .if !empty(USE_LANGUAGES:Mc++)), не нашёл. Да и некоторые авторы пакетов почему-то ошибочно считают, что gcc 4.7 для сборки их пакета на c++11 достаточно. Но это оказывается не так! Да мало того, некоторые из них даже не удосуживаются упомянуть c++11 в USE_LANGUAGES, хотя configure явным образом проверяет компилятор на поддержку c++11.

В одном случае пакет надеется на наличие libbacktrace в Linux, но у меня, например, в Wheezy его нет. Здесь хочу записать, что конструкция PLIST.backtrace= no не сработала: очевидно, надо, чтобы переменная имела пустое значение, я в итоге просто закомментировал PLIST.backtrace= yes. (Это пакет boost-libs.)

Поскольку я устал выставлять в Makefile'ах пропущенное c++11 и, кроме того, в cairomm возникла проблема при линковке, когда почему-то libtool не находил libstdc++.la из gcc 4.9, потому что в worl/.buildlink оказывалось gcc48, я решил внимательнее почитать https://wiki.netbsd.org/pkgsrc/gcc/.

If PKGSRC_GCC_VERSION and PKGSRC_GXX_VERSION are not set, the system
will behave much as before. As a possible exception, builds may still
fail if the required version is greater than the base system
version. So far the only known reason to avoid setting these variable
is if pkgsrc gcc cannot be built.

Each of c99, c++, c++11, and c++14 will be associated with a minimum
gcc version, such that almost all programs declaring that language can
be built with that version.

Но это всё, как я понимаю, теория, предложения. В реальности такого не происходит.

When the base system is almost new enough, the decision about the
default is more complicated. A key example is gcc 4.8, found in NetBSD
7. Firefox requires gcc 4.9, and all programs using c++14 also need a
newer version. One options is to choose 4.8, resulting in firefox
failing, as well as all c++14 programs. Another is to choose 4.9, but
this makes little sense because c++14 programs will still fail, and
the general rule of moving to the most recent generally-acceptable
version applies, which currently leads to gcc5.

Итог такой, что придётся всё-таки собирать все пакеты одним компилятором. (В этом своя логика, конечно, есть. Но вот в венде разве требуется, чтобы все программы в системе были собраны одной версией компилятора?!) И придётся повышать его версию, как только найдётся хоть один пакет на c++, которому требуется более новая версия. И пересобирать после этого все пакеты на c++ из-за бесконечных перекрёстных зависимостей.

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

Ещё интересные статьи (правда, 2015 года) о логике выбора версии gcc в pkgsrc:

https://atomicules.co.uk/2015/10/17/Adventures-in-Pkgsrc-Build-System-and-GCC-Selection-Part-1.html

https://atomicules.co.uk/2015/11/02/Adventures-in-Pkgsrc-Build-System-and-GCC-Selection-Part-2.html

NB: bmake show-depends-dirs покажет гораздо больше зависимостей, чем просто show-depends — включая, как я понимаю, build и tool depends.

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

#pkgsrc #gcc #inkscape #qgis


[] permanent link

2020/10/24 mysql readline

Оказалось, что с некоторых пор идиоты из Oracle ради своих проприетарных нужд перевели клиент mysql с readline на editline; при этом перестала работать такая ежеминутно нужная вещь, как обратный поиск в истории по ctrl-r. Они не могут, дескать, собирать mysql с libreadline по каким-то своим дебильным лицензионным соображениям. В этот момент я наконец-то понял, зачем нужна MariaDB (но, к сожалению, так и не могу заставить себя на неё перейти, потому что не нравится название). На самом-то деле понятно, что можно пересобрать с libreadline. В FreeBSD я так и делал, даже почти не заметив какой-то иной вариант и не рассматривая его. Однако в Debian mysql-client-5.6 собран с editline. Поиск по ctrl-r можно вернуть добавлением

bind "^R" em-inc-search-prev

в .editrc (см. https://bugs.mysql.com/bug.php?id=60465; вот здесь: https://stackoverflow.com/questions/20363737/mysql-reverse-i-search — пишут, что на некоторых версиях mysql не работает и это). Интерфейс поиска, однако, непривычный и потому неудобный.

Припомнив ещё, как Oracle угробили прекрасную инициативу OpenSolaris, я готов поставить эту корпорацию зла в один ряд с Гуглом и M$.


[] permanent link

2020/10/22 git

В очередной раз убеждаюсь, насколько мне не нравится git и насколько неудобна платформа GitHub (не говоря уж о том, насколько мне неприятна та корпорация, кому она принадлежит. Ядро Linux теперь разрабатывается на майкрософтовской платформе. Какой трагический абсурд.)

Казалось бы, если у меня есть форк некоего репозитория, то влить туда новые изменения из мастер-репозитория должно было бы быть проще простого, это рутинная операция, которая должна бы выполняться одним кликом в веб-интерфейсе. Но нет!

Во-первых, оказывается, что информация о том, откуда сделан форк, нигде не хранится (кроме сайта гитхаба). И вообще я так понял, что это какое-то нововведение конкретно гитхаба и прочих веб-сервисов (GitLab, bitbucket), реализуемое в каждом случае по-разному, а не функционал собственно гита. Разобраться сложно, поиск лишь даёт понять, что большинство разработчиков вообще не мыслят гит без гитхаба и, следовательно, вопросом, что̀ такое технически форк на Гитхабе, не задаются. Даже официальный сайт https://git-scm.com/ почему-то включает документацию по Гитхабу. Вопросы типа «Как сделать форк репозитория git?» повсеместно получают ответы типа «Идёте на Гитхаб и там делаете то и то». Какая-то каша у людей в мозгах.

Цитата со страницы, которая, впрочем, тоже мне ничего не прояснила (https://drewdevault.com/2019/05/24/What-is-a-fork.html):

GitHub is a proprietary, commercial service, and their ultimate goal is to turn a profit.

Как бы то ни было, приходится делать обновление, не вполне понимая, что̀ происходит. Говорим

git remote -v

и убеждаемся, что никакой информации об источнике форка у нас нет. Добавляем эту информацию:

git remote add upstream https://github.com/author/Repo.git

(То есть, получается, если у меня много локальных копий, то это нужно проделать для каждой из них?!)

git fetch upstream
git checkout master

(последняя команда должна нас переключить на локальную ветку master; зачем было менять привычное значение слова checkout, непонятно).

git merge upstream/master

(В других местах советуют git rebase upstream/master.)

git push origin master

обновит форк на гитхабе. Уффф.

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

#git

UPD (24.10.2020): показательные новости про гитхаб:

UPD 2 (03.11.2020): ну всё, понеслась:

"В ответ на активность пользователей по массовому созданию клонов заблокированного репозитория youtube-dl на GitHub, Джесси Джерачи (Jesse Geraci), корпоративный юрист компании GitHub, внёс изменения в правила обработки запросов о нарушении Закона об авторском праве в цифровую эпоху (DMCA)." (https://www.opennet.ru/opennews/art.shtml?num=54012)

Далее превращается уже в какую-то комедию:

"Web-интерфейс GitHub примерно на 30 минут оказался неработособен из-за того, что сотрудники забыли вовремя продлить SSL-сертификат для домена githubassets.com" (https://www.opennet.ru/opennews/art.shtml?num=54018)


[] permanent link

2020/10/11 qemu

Test bootable ISO images with QEMU

USB bootable flash drive:

qemu-system-i386 -hda /dev/sdc -m 512

CDROM:

qemu-system-i386 -boot d -cdrom ~/tmp/slackware-live-xfce-current.iso -m 512

Вернуть фокус мыши из qemu: Ctrl+Alt (но на практике это не нужно, сам возвращается).

#qemu


[
] permanent link

2020/10/08 sound file diff

Найти различие двух звуковых файлов:

sox -V4 -S -m -v 1 sound-original.wav -v -1 sound-altered.wav sound-difference.wav

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

(Источник: https://sound.stackexchange.com/questions/40222/show-the-differences-between-two-similar-audio-files-using-graphical-method)


[] permanent link

2020/10/06 pkgsrc

Доведённый до отчаяния адом зависимостей в пакетных менеджерах современных Линуксов, я начал экспериментировать с pkgsrc. Впечатления на первый взгляд хорошие. Очень порадовало, что для многих программ есть выбор, какую версию поставить: так, в дереве пакетов хранятся версии gcc со 2-й по 10-ю, 5 версий emacs, perl5 вот правда почему-то единственный, а во FreeBSD несколько, и ardour тоже, а даже в Дебиане можно несколько ставить. И evince2 буквально две недели назад удалили. Но в целом это решаемо: в будущем можно будет создать свою ветку и восстановить в ней удалённые пакеты или создать отдельные пакеты для нужных мне версий. Из обнаружившихся недостатков: дерево пакетов огромное (у меня сейчас занимает 2,5 гига, включая собранные пакеты в packages/All, а без них что-то около 1,5 гигов), обновляется медленно, индексации я вообще не дождался, ищу пакеты через find . -type d -name .... Кроме того, у меня уже накопилось достаточно локальных правок, и если переносимость получаемых бинарников между разными линуксами подтвердится (ради чего я это всё и делаю), логично было бы хранить всё дерево где-то в одном месте, скажем на флэшке или в чём-то вроде nfs/sshfs, но учитывая скорость сборки (о чём далее), есть опасение таким образом ещё более всё замедлить. Кроме того, пакеты из packages/All надо бы перенести на какой-то сервер.

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

После установки (инструкции: https://opensource.com/article/19/11/pkgsrc-netbsd-linux) не забыть прописать новые пути:

echo "PATH=/usr/pkg/sbin:/usr/pkg/bin:$PATH" >> ~/.bashrc
echo "MANPATH=/usr/pkg/man:$MANPATH" >> ~/.bashrc

После этого я попробовал в чруте собрать недавний fontforge на wheezy. Сборка в итоге продлилась неделю. Правда, в итоге было получено достаточно много готовых пакетов (установилось 175), и теперь (опять же, если переносимость подтвердится) можно их ставить уже собранными. Разумеется, я могу затем подробнее поковыряться в опциях каждого пакета (bmake show-options) и отключить кучу ненужных зависимостей; это делается куда проще, чем в deb-пакетах. Так, уже в процессе я добавил в /usr/pkg/etc/mk.conf

PKG_DEFAULT_OPTIONS+=   -wayland

— не думаю, что когда-либо в жизни поведусь на эту моду и стану им пользоваться.

Теперь о том, что̀ же оно такое делало целую неделю.

Для сборки какого-то пакета понадобился cmake (куда ж без него; недавно в интернете прочитал — уж не могу теперь найти — в связи с какой-то проблемой в новых версиях каких-то продуктов Мозиллы некто жалуется, что всё это оттого, что Мозилла, как и многие другие нынешние разработчики, отказалась от GNU build tools — и воистину, он прав), но не собирался, выдавая ошибку, что не может найти -lgcc_s. А оно мне поставило gcc 4.8 в /usr/pkg/gcc48. Я поначалу долго думал, что оно просто не может найти gcc из-за нестандартного расположения. К сожалению, информации по конкретным проблемам с pkgsrc довольно мало. С трудом нашёл описание аналогичной проблемы и решение: https://mail-index.netbsd.org/tech-pkg/2020/06/25/msg023446.html — оказывается, надо вместе с gcc собирать и libgcc, которое почему-то не ставится по умолчанию. В /usr/pkg/etc/mk.conf написал:

PKG_OPTIONS.gcc48+=     always-libgcc -nls

Тут — https://mail-index.netbsd.org/tech-pkg/2020/06/25/msg023445.html — предлагается сделать это для всех версий gcc сразу так:

PKG_DEFAULT_OPTIONS+=  always-libgcc

Следующий сбой случился при установке какого-то модуля питона 2.7, когда сам питон ещё не был установлен. Ничего иного от питонщиков я и не ждал, будь они хоть создателями пакетов pkgsrc. Решилось каким-то образом повторным перезапуском сборки, при котором питон уже поставился. Так и не понял, что̀ произошло, ну и ладно. Разумеется, надо было в опциях пакетов отключать сразу питон везде, где это возможно. Но это не везде возможно.

Следующая проблема была с gcc49 и gcc5, которые тоже оказались в чьих-то зависимостях и не собирались с ошибкой типа описанной здесь: http://mail-index.netbsd.org/pkgsrc-users/2019/06/16/msg028814.html, вот пример из gcc5:

/usr/include/i386-linux-gnu/bits/stdio2.h: In function 'void GTM::gtm_verror(const char*, va_list)':
/usr/include/i386-linux-gnu/bits/stdio2.h:125:1: error: inlining failed in call to always_inline 'int vfprintf(FILE*, const char*, __gnuc_va_list)': function body can be overwritten at link time
 vfprintf (FILE *__restrict __stream,
 ^
../../../gcc-5.5.0/libitm/util.cc:35:31: error: called from here
   vfprintf (stderr, fmt, list);
                               ^

Пришлось добавить

FORTIFY_SUPPORTED=  no

в gcc49/Makefile, иначе не знаю как.

Опять какие-то новшества всё убивают. Раньше была проблема, что старые исходники не собираются более новым компилятором, теперь наоборот — новые не собираются старым. Вот зло!

Далее, пришлось в Makefile для textproc/icu поменять

GCC_REQD+=              4.8

на 4.9. Далее не собирается harfbuzz (кажется, fontforge с его зависимостями был слишком сложным выбором для начального тестирования системы). Там ninja, meson и прочее. Пора бы сделать операционную систему, в которой было бы строгое требование, чтобы весь софт собирался только с помощью единого стандартного, традиционного и обратно совместимого инструментария.

../test/api/hb-test.h:178:5: error: 'for' loop initial declarations are only allowed in C99 or C11 mode
     for (unsigned int i = 0; i < expected_length; i++)
     ^
../test/api/hb-test.h:178:5: note: use option -std=c99, -std=gnu99, -std=c11 or -std=gnu11 to compile your code

Пришлось поменять в Makefile USE_LANGUAGES на

USE_LANGUAGES=  c99 c++

Не забыть make clean после этого!

И то же самое понадобилось для gcc5 (это уже третий gcc, который пришлось поставить в процессе). Не понятно, если уж так нестерпимо хочется писа́ть

for (int i=...)

вместо

int i;
for (i=...)

— то это же совершенно механическая замена, ну пиши ты как хочется и добавь в сценарии сборки обработку особым препроцессором, который твой ленивый код приведёт к нормальному виду (и тут и выясняется вся абсурдность таких «упрощений», которые сводятся к машинно выполнимой замене; хотя вот придумали же всякий TypeScript и Less и пишут как хочется, а потом компилируют в стандартный JS/CSS, почему с C так не сделать?). (В Perl вот тоже никогда не понимал добавление этого словечка state — чем сложно было то же самое делать через замыкания, как испокон веку делалось?)

Но и на этом не всё. Gtk3 требует libexpoxy, которое требует MesaLib, которое с некоторых пор в единственном месте употребляет специфический для Linux системный вызов:

#if defined(__linux__)
...
  return syscall(SYS_kcmp, pid, pid, KCMP_FILE, fd1, fd2);

Однако этот системный вызов появился только в ядре 3.5 (https://rdhafidh.web.id/blog/11/04/2020/Building+mesa+19.3.5+on+ancient+ubuntu). Очевидно, более старые версии ядра̀ для разработчиков не существуют. В моём случае дело осложняется тем, что моё-то ядро поддерживает данный вызов, но я собираю для более старых дистрибутивов, кое-где у меня отлично работает ядро 3.2 и я не вижу поводов его заменять. Поэтому данный код нужно убрать полностью (начиная с изменений в коммите https://github.com/mesa3d/mesa/commit/ed271a9c2f40f8ec881bf3e4568d35dbfcd9cf70, как указано по ссылке выше), а не пытаться добавлять какие-то условия, чтобы включить его для ядер >= 3.5. Кстати, глядя на историю этого кода, видно, что разработчики уже столкнулись с проблемами из-за его добавления: в последующих версиях им пришлось скопипастить кусок из linux/kcmp.h. Так что их путь без сомнения ложный, без всяких сожалений убиваем данное новшество. Это можно сделать либо удалив лишний код, либо поставив заведомо невыполнимое условие вместо #if defined(__linux__). Чтобы облегчить себе в будущем сопровождение этих патчей, выбираю путь минимальных изменений — второй.

Применение патчей в pkgsrc

Опять сталкиваюсь с малочисленностью документации, из которой не могу, например, понять, зачем при запуске pkgvi переходить в каталог с исходниками и обязательно ли это. Я этого не делал. В итоге я так и не понял, вполне ли правильно всё делаю, но такая последовательность у меня сработала:

cd /usr/pkgsrc/graphics/MesaLib
bmake fetch extract patch
pkgvi work/mesa-20.0.6/meson.build
pkgdiff "work/mesa-20.0.6/meson.build" # проверка
mkpatches
bmake makepatchsum

Однако после этого сборка стала падать с ошибкой:

src/util/libmesa_util.a(crc32.c.o): In function `util_hash_crc32':
crc32.c:(.text+0x1c): undefined reference to `crc32'
src/util/libmesa_util.a(disk_cache.c.o): In function `cache_put':
disk_cache.c:(.text+0xc1c): undefined reference to `deflateInit_'
disk_cache.c:(.text+0xca2): undefined reference to `deflate'
disk_cache.c:(.text+0xd02): undefined reference to `deflateEnd'
disk_cache.c:(.text+0xd51): undefined reference to `deflateEnd'
src/util/libmesa_util.a(disk_cache.c.o): In function `disk_cache_get':
disk_cache.c:(.text+0x1830): undefined reference to `inflateInit_'
disk_cache.c:(.text+0x18b1): undefined reference to `inflate'
disk_cache.c:(.text+0x18c4): undefined reference to `inflateEnd'
disk_cache.c:(.text+0x18e2): undefined reference to `inflateEnd'

Основная сложность была даже не в том, чтобы найти подлинную причину — казалось бы, ничто не мешает пробовать разные варианты, но тут оказывается, что ещё больше времени уходит на то, чтоб разобраться, как сделать то или иное в этом дебильном Мезоне. Как там добавить флаг линкеру, как убрать флаг? Где определяется порядок аргументов, передаваемых ему? Как определить, видит ли он вообще libz и какой именно — системный или из pkgsrc?

Решилось так:

add_project_link_arguments(
      '-Wl,--no-as-needed',
      language : ['c', 'cpp'],
)

Не знаю, насколько правильно, но работает.

Как видим, ни одного сбоя не произошло по вине стандартных, проверенных временем технологий; все сбои из-за введения новшеств: начиная с написания кода, привязанного к определённым (новейшим) версиям gcc и ядра и жертвующего переносимостью ради синтаксического сахара, и заканчивая нелепым желанием разработчиков привнести как можно больше разных систем сборки (в основном так или иначе завязанных на питоне), взамен простых, стандартных и проверенных configure/make.

К сожалению, данный подход делает бессмысленной всю идею свободного ПО, которое любой человек может сам собрать из исходников. Как видим, не то что любой человек, а даже профессиональный программист не всегда может собрать программу из исходников с таким инструментарием. Пользователи оказываются вынужденными устанавливать сторонние сборки, заявляемая возможность «скачать исходники и собрать самому» оказывается чисто теоретической. (Ещё раньше это произошло с браузерами — насколько я помню, уже довольно давно Мозилла официально (!) не рекомендовала (!) собирать свои браузеры из исходников, вместо этого навязывая собственные сборки. Впрочем, как видим, на моих машинах такая сборка заняла бы, наверно, месяц.) В этой ситуации пользователю становится безразлично, свободный софт у него или проприетарный, раз установка программы ничем принципиально не отличается от установки проприетарных бинарников в винде, с той разницей, что в винде программа ещё и не тянет за собой миллион зависимостей. Создатели таких инструментариев вбивают лишь гвозди в гроб свободного ПО, к сообществу которого они наивно сами себя причисляют, но на самом деле лишь вредят, и со своими модными инструментами и технологиями место им среди высокооплачиваемых сотрудников какой-либо большой корпорации, выпускающей пропритарный хлам.

Вдогонку: сегодня, 06.10, получаю новость:

Разработчики проекта Mesa обсуждают возможность использования языка Rust для разработки драйверов OpenGL/Vulkan и компонентов графического стека.

Почему я не удивлён.

#pkgsrc #gcc


[] permanent link

2020/10/04 lunpacms

Это ещё что?!

http://www.lunpacms.org/

Определить давность этого странного изделия не представляется возможным (CGI с возможностью FCGI, собственный шаблонизатор, но при этом HTML5, встраиваемые шрифты). Как будто куча всяких возможностей, включая магазин, но непонятно даже как скачать.

#perl #cms #cgi #lunpacms #fcgi


[] permanent link

2020/09/27 seamonkey chroot

Seamonkey in chroot

Может потребоваться установить Seamonkey в chroot. Начиная с 2.53, Seamonkey (как и Chromium с неустановленных пор) требует доступа к /dev/shm. Для schroot можно раскомментировать строчки в /etc/schroot/default/fstab:

/dev/shm       /dev/shm        none    rw,bind         0       0
/run/shm       /run/shm        none    rw,bind         0       0

либо, чтобы не делать это для всех чрутов, создать отдельный файл, скажем, /etc/schroot/shmem/fstab и в настройки данного чрута прописать

setup.fstab=shmem/fstab

или, чтобы вообще для отдельной программы это сделать, прописать там же

user-modifiable-keys=setup.fstab

и запускать программу в chroot, например, так:

schroot -c sid -o setup.fstab=shmem/fstab -p -- chromium

#schroot #seamonkey


[
] permanent link

2020/09/22 keyserver

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

W: There is no public key available for the following key IDs:
648ACFD622F3D138
E: Release file for http://archive.debian.org/debian/dists/jessie-backports/InRelease is expired (invalid since 580d 3h 3min 36s). Updates for this repository will not be applied.

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

apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 648ACFD622F3D138

echo 'Acquire::Check-Valid-Until no;' > /etc/apt/apt.conf.d/99no-check-valid-until

(поскольку в Debian нету по умолчанию файла /etc/apt/apt.conf, можно записать эту строку и туда. Вроде бы можно также так (не проверял): Acquire::Check-Valid-Until "0";.)

#apt #debian


[] permanent link

2020/09/21 local infile

По умолчанию в MySQL не включена возможность LOAD DATA LOCAL INFILE на удалённый сервер. Запускать клиент нужно с ключом --local-infile:

mysql -u user -p --local-infile -h host dbname

После этого данные загружаются так:

load data local infile '/path/to/local/file.csv' \
into table table_name character set utf8 FIELDS \
TERMINATED BY ','  ENCLOSED BY '"' LINES \
TERMINATED BY '\n' (field, names, list);

#mysql


[
] permanent link

2020/09/21 apt

Создание собственного репозитория apt

Много (хотя на самом-то деле не так уж и много...) разных решений предлагалось из-за нелепого перехода Debian на systemd. Странно, что нигде, кажется, не предлагалось такого варианта, как остаться на всю жизнь на Wheezy (как последней версии без принудительного systemd) и бэкпортить туда всё необходимое. Теоретически это должно быть осуществимо, если не быть совсем параноиком по безопасности.

(UPD: это оказалось едва ли осуществимо, по крайней мере, с приемлемыми затратами труда. См. например https://askubuntu.com/questions/1019763/using-backportpackage-gives-circular-ish-dependency: "dpkg and debhelper are nearly impossible to backport safely...")

Мне, честно говоря, больше нравится Squeeze, и вообще почему-то чётные релизы Дебиана всегда более стабильные, чем нечётные, которые зачастую непонятно вообще зачем выпущены — версии интересующих меня программ там зачастую не меняются, зато ломается что-то непременно. Так и в Wheezy, кажется, что-то было капитально сломано (CUPS? не помню точно). Тем не менее, бэкпортировать что-либо на Squeeze было, насколько я помню, сложно из-за необходимости выпиливать multiarch отовсюду. Поэтому ничего не остаётся, как попробовать остаться на Wheezy навечно.

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

Процедуру бэкпортирования надо будет описать позже, сейчас же будет пример выкладывания уже готовых пакетов в собственный репозиторий. Есть такой проект ubuntuzilla, который готовит deb-пакеты из официальных сборок программ Мозиллы. Как показал опыт, они работают независимо от дистрибутива и его версии. Поэтому заморачиваться со структурой каталогов для каждой версии не нужно. Конфиг их репозитория для apt:

deb http://downloads.sourceforge.net/project/ubuntuzilla/mozilla/apt all main

Я так и не понял, как скачать весь репозиторий с sourceforge, поэтому вручную скачал только нужные мне (проверенные) версии. Сохраняю их в ~/src/ubuntuzilla. Далее:

cd ~/src/ubuntuzilla
dpkg-scanpackages -m . | gzip -9c > Packages.gz

Ключ -m как раз должен добавлять в индекс все обнаруженные версии (хотя не проверял, что̀ будет без него).

После этого выкладываю каталог ubuntuzilla на свой сервер. Строка для apt выглядит так:

deb http://home.rp.spb.su/ubuntuzilla/ ./

#apt #dpkg-scanpackages


[] permanent link

2020/08/26 perl curse

Случайно наткнулся на ещё одну реализацию ООП для Perl:

https://github.com/Ovid/Cor/wiki

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

И в обоснование необходимости такой реализации ООП приводится вот эта статья:

http://winestockwebdesign.com/Essays/Lisp_Curse.html

Очень примечательная. Действительно, то, что̀ там сказано о Лиспе, столь же может быть отнесено и к Perl. Невероятная мощь языка превращает программирование на нём в самодостаточный процесс, приносящий удовольствие, и в то же время позволяет легко реализовать то, чего в языке, как может показаться, не хватает. Поэтому программисты плодят многочисленные собственные реализации одного и того же, остающиеся неизвестными и не превращающиеся в стандарт. Это объясняет и ситуацию с веб-фреймворками и CMS, на которую я ранее многократно жаловался. Я и сам формулировал это для себя таким образом, что перл-программист не хочет использовать готовые решения, хочет всё писать с нуля и сам, потому что он отчасти делает это из-за чистого удовольствия низкоуровневой работы с языком. То есть он работает как художник, а не как практик. Теперь, однако, сюда можно добавить ещё и такой фактор, как объективная мощь языка.

Я, однако, не могу сказать, что мне легко написать CMS с нуля. И не думаю, что на Лиспе было бы проще, если бы я вполне знал Лисп. CMS отражает иной если не уровень, то стиль мышления, мышление пользователя, а не разработчика. Ранее я тоже об этом писал, о том, какое страдание для программиста-художника работать с запросами конечных пользователей. В этом плане, возможно, конечных пользователей лисп-продуктов не так уж и много и уровень их пользовательского опыта, возможно, иной. А пользователей веба миллиарды и уровень их крайне низок.


[] permanent link

2020/08/20 alive

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

В моей поисковой системе будут индексироваться не страницы, а документы. И в метаданных документа будет поле alive. Успешно проиндексированный документ помечается как alive. При повторных индексациях, если документ исчез, флаг alive снимается, но контент у меня локально сохранён и доступен теперь непосредственно с серверов поисковой системы. Документы не должны исчезать бесследно.

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


[
] permanent link

2020/07/26 emacs cms

Как-то я придумал идею EmacsCMS, то есть управления сайтом из Emacs. Оказывается, подобное уже есть: https://github.com/kofuk/emacs-cms. Но, похоже, всё-таки не то. Там Emacs сам выступает в качестве сервера приложений, что̀, конечно, совершенно непрактично. Я же имел в виду, что Emacs будет предоставлять нечто вроде интерфейса для редактирования к виртуальному иерархическому дереву объектов, типа как в Zope.


[] permanent link

2020/06/30 handel

Вот такое ещё есть (было?):

Building E-Commerce Sites with Handel https://www.perl.com/pub/2005/11/17/handel.html/ https://metacpan.org/pod/Handel

Выглядит обещающе, но последний релиз 2011 года. Остаётся надеяться, что Catalyst достаточно консервативен.

Вообще это было бы крайне удобно, если бы функционал интернет-магазина можно было бы добавлять к существующему сайту в виде набора модулей (в данном случае это должен быть сайт на Catalyst, но я имею в виду сайт на чём угодно — хоть на самописных CGI-скриптах). Да и не только магазина. По сути, все эти магазины, форумы, лайки и прочее — всё это совершенно стандартно и однообразно. Всё сводится к определённой структуре БД и интерфейсу к ней на определённом языке программирования. И ничто не мешало бы создать универсальные модули типа Web::Shop, Web::Forum, Web::Likes, содержащие такой интерфейс и не привязанные к конкретному движку/фреймворку (который может добавлять свою дополнительную прослойку). В гофере такие вещи вообще могли бы делаться на уровне интерфейса клиента (как отдельные item types, например) или через внешние скрипты, подходящие для любого сервера, настолько они все (форумы, магазины и проч.) одинаковы.

#perl #e-commerce

UPD: Markdown настолько идиотский формат, что не позволяет даже нормально хэштеги вставить. Приходится отбивать начальный # пробелами. Позже напишу отдельный пост о формате разметки для текстовых файлов.


[] permanent link

2020/06/07 perl cms

Неожиданно почти решились мои проблемы с поиском CMS на Perl, по крайней мере для моих текущих целей. Во-первых, нашёл вот такую вещь:

https://metacpan.org/pod/Yancy

Это CMS на Mojolicious (который, кстати, при всё более близком рассмотрении оказывается всё лучше), пока что work in progress, но прогресс действительно есть (нашёл и зарепортил баг, его разработчик его пофиксил через пару дней и выпустил новый релиз), удобный и красивый дизайн, и главное — то, что̀ я как раз искал, возможность подключения к произвольным базам и генерация удобного и работающего CRUD для них, даже с поддержкой связей таблиц по внешним ключам, на что̀ я и надеяться уже перестал. Кроме БД, впрочем, пока что почти ничего нет, но мне и нужна была в первую очередь БД.

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

В-третьих, я попробовал RapidApp, о котором писа́л ранее. Вовсе не так уж он похож на Битрикс, скорее разве что по интерфейсу, чем по идее. Он может всё то же самое: подключаться к произвольной БД и создавать удобный табличный интерфейс для редактирования записей. Есть также пара готовых приложений на его базе: Rapi::Blog (движок блога c приличным дизайном и (почти?) стандартным для блога функционалом), Rapi::Fs (просмотрщик файловой системы).

Правда, он довольно громоздкий: Catalyst, DBIx::Class, ExtJS, с базами из Вордпресса и других CMS, которые я за неимением иного ему скормил, процесс сервера занял >132 Мб (процесс rdbic.pl, который не включает только CRUD для базы, почему-то ещё больше: >160 Мб). В продакшене как движок сайта я не стал бы использовать (разве что Rapi::Blog, если бы пришлось делать полноценный блог под заказ), а как админский интерфейс для просмотра баз и файлов, особенно не моих — пока что лучший найденный вариант. (Yancy лучше во многих отношениях, но любой сторонний пользователь сразу ощутит отсутствие привычных удобств, то есть потребует доработки и допиливания, если им кто-то будет пользоваться, кроме меня.)

Так что единственное, что̀ ещё осталось для моих рабочих целей, это нормальный интернет-магазин на Perl. Нашёл ещё вот такое:

https://agoracart.com/demos.php

(Да, сайт на php, что̀ уже само по себе настораживает.) Это какая-то дремучая архаика на cgi-скриптах. Похоже, этот продукт претендует на ту же нишу, что и многочисленные поделия на php, то есть установку на шаред-хостингах. То есть как бы получается, что в наши дни CGI на Perl — это аналог mod_php под apache, такой же простой, дешёвый, непроизводительный и архаичный. (Хотя, судя по приводимому на сайте количеству инсталляций последней версии — менее 100, конкурирует с php без особого успеха.) Код даже без use strict, с local внутри функций вместо my и прочими призраками из начала 90-х (удивительно, что апострофа нет в качестве разделителя имён пакетов и что используется CGI::Simple, а не CGI). С другой стороны, должен признать, что такой архаичный код часто выглядит более понятным, чем современный с use strict и прочим, зато с миллионом уровней абстракции. К недостаткам отнесём также собственный шаблонизатор и при этом зависимость от модных современных JS-библиотек. Кроме того, практикуется расширение функционала в виде платных модулей.

Но вообще-то, если оно работает, а заказчику не объяснить, что такое PSGI, фрэймворк и сервер приложений, то почему нет?


[] permanent link

2020/06/01 static typing

Вот любопытная статья:

https://codefork.com/blog/index.php/2016/09/24/the-myth-of-artisanal-programming/

и особенно цитата: "it’s no mystery why people are turning to the newer generation of statically typed languages like Scala, Haskell, Go, etc."

Как работает кое-что из этого новомодного софта на Хаскелле, я имел несчастие видеть. Такое ощущение, что его действительно выбирают как язык ради языка, не заботясь совершенно о том, выполняет ли написанная программа то, что̀ от неё изначально требуется.

Но интересно и другое: я в последнее время подсел на Moose не из любви к ООП, а именно из-за того, что тот добавляет к перлу хоть какую-то типизацию (хотя бы на уровне свойств объектов), которой мне ощутимо не хватает. И мне всё чаще хочется пользоваться Method::Signatures::Simple, потому что объявлений параметров функций тоже не хватает. И я уже задумывался над тем, что и какой-то модуль для явной типизации остальных переменных тоже неплохо бы освоить. И хорошо, что перл всё это позволяет своими средствами и без смены языка.

Потому что воистину зачастую половина работы в скриптовых языках (с php то же самое) заключается в ручном написании проверок переданных параметров и типов переменных.


[] permanent link

2020/05/30 craft programming

Публикую здесь по-русски некоторые идеи и обоснования идей крафтового программирования, которые размещены по-английски на сайте моего грядущего поисковика http://legeon.org.

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

(Далее следует обоснование выбора Perl в качестве основного языка разработки и Z39.50 в качестве протокола поискового сервера.)

Поддержка Z39.50 нужна для стандартизации взаимодействия с поисковым сервером. Фактически нужны два стандарта: поискового запроса, вводимого пользователем, и запроса, отправляемого бэкенду. Насколько мне известно, первый, несмотря на некоторые попытки, не стандартизирован до сих пор. Для второго же, пожалуй, со времён Z39.50 ничего лучшего не придумано. Опять же, стандарты эти должны быть защищены от "развитий" и изменений, которые заставили бы меня провести весь остаток жизни в переделывании уже написанного и работающего кода.


[] permanent link

2020/05/28 noscript

Я пользуюсь браузером Seamonkey (как единственным графическим браузером, сохраняющим одинаковый интерфейс уже лет 15), и на одном из компов у меня в нём стоит плагин NoScript. До недавнего времени это было очень удобно, невероятно ускоряло загрузку и снижало нагрузку на CPU, теперь же кривых сайтов, не работающих без JS, всё больше, и приходится всё чаще включать скрипты с основного домена сайта, чтоб хоть что-то увидеть, и избирательно со сторонних доменов. И я прихожу в ужас от обилия этих никчёмных сторонних сервисов, которые стало модно пихать себе в сайты. В этом посте я буду записывать сведения о доменах разных скриптов, чтобы помнить, что̀ они делают и насколько надо их отключать. Зачастую даже изучив сайт того или иного скрипта, невозможно понять, что̀ он делает и зачем он вообще кому-то мог понадобиться. Джаваскриптовый психоз рано или поздно заставит меня полностью уйти в гофер.


[
] permanent link

2020/05/27 craft programming

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

(под заглавием «Working with end users is hard» написано для обоснования идеи крафтового программирования)


[
] permanent link

2020/05/18 google spam

Уже пару месяцев слежу вот за этой любопытной статистикой:

https://www.spamhaus.org/statistics/networks/

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

По ссылке мы видим истинное лицо этих лицемерных борцов со спамом.


[] permanent link

2020/04/01 frameworks vs diy

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

Целый день писал тесты для сайта на Poet/Mason. Сразу скажу, что эту архитектуру для данного сайта выбрал я давно, сознательно и пока что не было случая, чтобы мне приходилось горько об этом жалеть. Конечно, сама идея шаблонизатора как некоего дополнительного недоязыка, который приходится осваивать разработчику и который требует особого интерпретатора, дурна и её следует избегать. Масон несколько оправдывается, во-первых, чрезвычайно удобной идеей объектно-ориентированных шаблонов (что̀, впрочем, некоторые считают как раз его недостатком; при этом я не рассматриваю всё объектно-ориентированное как благо, но в данном случае это прекрасный пример уместности ООП), во-вторых, минимальностью самого синтаксиса шаблонов: по сути, есть только маркеры, указывающие, интерпретировать ли данный код как perl или html, а всё остальное можно и не использовать. (Я говорю о Mason 2; судя по масоновской рассылке, до сих пор многие сидят упорно на Mason 1; тот куда больше похож на классический шаблонизатор или php, и я не понимаю этих людей.)

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

Начинается всё с того, что мне надо для тестов переопределить пару параметров в конфиге. С удивлением обнаруживаю, что возможность вручную выставить значение ($conf->set(...)) не предусмотрена! И сознательно, т.к. это, дескать, дурной тон, менять конфиги где попало. "Setting and resetting of configuration values will make it much more difficult to read and debug code!" Да, разумеется, особенно с таким синтаксисом, который всё же предусмотрен — с оговоркой, что исключительно для тестирования — чтобы временно поменять значение для данной лексической области видимости:

my $lex = $conf->set_local({key => 'value', ...});

В моём случае это сработало. Но, учитывая, сколь разными могут быть ситуации тестирования и специфику областей видимости в perl, тем более в Moose, не удивлюсь, если будет работать не всегда (например, когда придётся разбить код данных тестов на несколько модулей/функций, а общий код, содержащий как раз эти изменения конфига, вынести отдельно). Надо ли говорить, что если бы фрэймфорк писал я, не было бы такого ограничения. Когда я работаю с чужим кодом, возможность оперативно изменить значение из конфига в любом месте кода и быстро увидеть результат, вместо того чтобы городить отдельные тестовые конфиги или создавать их в памяти, требуется постоянно. (А тут кстати даже и создать конфиг нельзя, не прибегая к файлу. Конфиг почему-то всегда считывается из файлов, причём имена файлов хардкодные! Конечно, я могу переопределить класс конфига и всё это там сделать. В будущем я так и сделаю. Но на выяснение неизбежности этого весь день и ушёл. Дело осложнялось тем, что ряд параметров ещё и устанавливается в значения по умолчанию в других местах и через конфиг не переопределяется, хотя неработающий пример приведён в документации, но это уже можно считать багом. А если бы речь шла не о тестах, а о чём-то более срочном и важном?)

Мало того! И масоновский компонент нельзя создать на лету, поскольку иного способа его создания, кроме чтения из файла, не предусмотрено! Приходится городить кучу временных файлов. К чему объектноориентированность шаблонов, если такой шаблон, представленный в программе объектом, нельзя создать как любой другой объект?

Некоторые объекты являются синглтонами, но нет возможности переинициализировать их либо работать в каждом тесте с заново создаваемым объектом. Использование синглтона само по себе тут оправдано, но возможность заменить/переинициализировать его для тестирования является очевидной необходимостью. (Допускаю, что в некоторых реализациях данного паттерна это технически или идеологически невозможно. Но в perl препятствий к этому я не вижу.)

Итог: день потрачен на то, чтобы выяснить, что ряд возможностей, которые мне понадобились, отсутствуют в выбранном мною фреймворке, не работают или работают странно. Написанный тест в результате изобилует некрасивыми хаками, призванными как-то выкрутиться в узких рамках, в которые поставили меня описанные ограничения.

Конкретно дело не в Poet. В другом фрэймворке это были бы, возможно, другие ограничения. Сколько кода собственного, полностью удовлетворяющего меня фрэймворка мог бы я написать за это время?


[
] permanent link

2020/03/30 fossil

http://fossil-scm.org/home/doc/trunk/www/fossil-v-git.wiki

Так хорошо ругают git, что даже захотелось попробовать (fossil, в смысле, попробовать).


[] permanent link

2019/06/14 UR

Я обнаружил UR как возможную альтернативу KiokuDB, но на самом деле это скорее альтернатива Moose, ориентированная более на табличные объекты. Как известно, нормальный ORM для Moose мне пока так и не удалось найти.

https://metacpan.org/pod/UR


[] permanent link

2019/06/12 openinteract

Вот ещё пример абсолютно неизвестного, непризнанного и забытого, но, возможно, достойного приложения на перл:

https://metacpan.org/pod/distribution/OpenInteract/OpenInteract/Intro.pod

В редких упоминаниях в интернете рекомендуется сравнивать его с Zope. Как я понимаю, там тоже веб-интерфейс к собственной объектной БД. Но, опять же, это Apache/mod_perl. Сколько хорошего софта погублено и обречено на забвение из-за ориентации на эту оказавшуюся провальной платформу.


[] permanent link

2018/05/02 masonsql

Вот, похоже, серьёзный и используемый в бою фрэймворк (на Mason1, правда) — опять же никакой инфы нигде, кроме пары постов в рассылке Масона и пары объявлений о найме работников для портирования на Mason2.

https://www.leader.it/Portal/MasonSQL


[] permanent link

2018/04/27 interchange

Удивительно, но есть вполне рабочее решение для e-коммерции на Perl, существует с 1995 г., последний коммит 20 дней назад, никакой инфы — нигде! Нашёл совершенно случайно.

http://www.icdevgroup.org/i/dev/

Существенный недостаток, конечно — собственный шаблонизатор.


[] permanent link

2017/12/11 more perl cms

Начал сайт на ShinyCMS и вскоре увидел, что там нет такой элементарной вещи, как привязка постов блога к секциям. Технически заложена возможность нескольких блогов, но к ней ней интерфейса не то что в админке, а даже в коде толком нету (при создании поста в блоге id блога хардкодится).

Полез в инет и, изучая сайты, сделанные на оной ЦМС, наткнулся на удивительные вещи.

http://rperl.org/ — компилятор перл, якобы сопоставимый с C/C++/Fortran и, в отличие от множества подобных проектов, вроде бы даже продакшен-уровня. Та же компания собирается в 2018 выпускать rperl-enabled смартфон (http://www.autoparallel.com/products/genius/), так что всё серьёзно. Правда, сайт http://cloudforfree.org/, который должен предоставлять какие-то облачные сервисы с этим самым rperl, не работает, потому что перегружен.

Оттуда вышел на ещё разные проекты улучшения перла, правда, не столь амбициозные: http://perl11.org/

Помимо этого, обнаружились ещё несколько ЦМС:

http://wiki.cyclone3.org/index.php/Cyclone3Frameworkinstallation — какой-то невероятно амбициозный проект, не решусь опробовать; как я понимаю, состоит из серверной части под апачем (фрэймворк) и клиентской — внимание! — на XUL! При этом последние обновления совсем недавние и, похоже, активно развивается. Уже апач в 2017 г. странен, но только что похороненный Мозиллой XUL — это совсем за пределами разумения. Хотя я, конечно, за XUL. Демо не нашёл.

http://xims.info/about.html — нечто заброшенное в 2013 г. Вроде нормально выглядит и даже интерфейс напоминает Zope, но настолько древний код, что даже Seamonkey всё перекорёживает.

http://cms.simpleness.org/about/for_developers — меня настолько шокируют шрифты, что всерьёз не могу воспринимать. Демо выглядит как сырое поделие, ссылка здесь только для полноты картины.

https://www.dreamwidth.org/site/opensource — как я понял, форк ЖЖ. Поддерживается. https://github.com/dreamwidth/dw-free

Понемногу смирился с TT, при некоторой настройке (INTERPOLATE=1, OUTLINE_TAG, собственные TAGS) вполне можно пользоваться.


[] permanent link

2017/12/04 perl wiki

Twiki и Foswiki, насколько я понимаю, часто используются как CMS. На них поэтому также надо обратить внимание.

Сайты на Foswiki: http://foswiki.org/About/ExampleSites

У Twiki такой странички не нашёл.


[] permanent link

2017/11/30 HTML Zoom

Вот ещё интересный шиблонизатор:

http://search.cpan.org/~jjnapiork/HTML-Zoom-0.009009/lib/HTML/Zoom.pm

Синтаксис не очень, но идея хороша.

UPD (14.12.2017): Вообще много подобного есть. Достаточно посмотреть Catalyst::View::* на CPAN.


[] permanent link

2017/11/28 rapidapp

http://www.rapidapp.info/ — очень навороченный фреймворк на перле и js, настолько, что напоминает битрикс по интерфейсу. На Каталисте. Отмечу для себя, но лезть не буду.

Внимание! У них есть интерфейс для создания CRUD: https://metacpan.org/pod/rdbic.pl Есть и интерфейс к файловой системе. JS отпугивает, впрочем.


[] permanent link

2017/10/30 shinycms

Поставил ShinyCMS 0.9.1 так:

perl Makefile.PL
make

установит модули. Перед этим должны быть установлены Module::Install и Module::Install::Catalyst. (На сервере с FreeBSD после этого установилось не всё. Пришлось повторно запускать make. XML::Feed не поставился, доставил из портов. Оттуда же пришлось ставить не упомянутые в качестве зависимостей DBI и DBD::mysql.)

(UPD: проще cpanm -v --installdeps . Могут возникнуть проблемы с тестами для DBIx::Class::Schema::Loader. Это из-за бага в Hash::Merge, поэтому нужен Hash::Merge версии 0.200.)

Базу надо создать вручную:

mysql -u root
mysql> create database shinycms character set utf8 collate utf8_general_ci;

и далее создать юзера и заполнить таблицы тестовыми данными:

mysql -u root < docs/database/mysql-create-user.sql
./bin/database/build-with-demo-data

Важно! Базу нужно сразу создавать с кодировкой utf8, и в конфиге shinycms.conf внести следующие изменения для работы с юникодом:

encoding utf8

в начале,

mysql_enable_utf8 1

в разделе connect_info, а в разделе View::HTML:

ENCODING           utf-8

(вообще я конечно уже думаю, чем и как заменить этот ужасный TT).

Кроме того, для использования юникода в конфиге надо ещё добавить

-UTF8 => 1

в параметры драйвера конфига General в файле ShinyCMS.pm (строка 44). Иначе, например, название сайта в конфиге будет не написать кириллицей.

Запускаем:

./script/shinycms_server.pl

Админка:

http://localhost:3000/admin/ (admin:changeme)

Любопытно, что здесь также используется принцип построения страницы из "кирпичиков". Хотя, как я понял, всё же существуют и рукотворные шаблоны, куда эти кирпичики вставляются в качестве элементов.


[] permanent link