Doomed to Wordpress

Serious Reflections During the Life of Jeremy Fisher

   

Subscribe
Subscribe to a syndicated feed of my weblog, brought to you by the wonders of RSS.

Flavours
There's more than one way to view this weblog; try these flavours on for size.

  • index
  • circa 1993
  • RSS
  • Links
    These are a few links to my other sites.

  • Ставропигиальныя Пластинки
  • Анкылым
  • Русское Шрифтовое Зало
  • Gopher (Proxied)
  • More about Gopher
  •        

    2021/05/26 nyxt

    Нашёл, казалось бы, браузер мечты на замену непоправимо умирающему SeaMonkey, а он, оказывается, вообще не признаёт http. То есть адрес, начинающийся с http://, они не понимает как адрес и скармливает поисковику (поисковик по умолчанию, разумеется, duckduckgo). Понятно, что раз это браузер мечты, то всё это настраивается на лиспе, но такая неудача при первом же опыте общения с программой и из-за такой нелепой вещи — очень расхолаживает.

    https://nyxt.atlas.engineer/

    UPD: выяснилось, что это был какой-то глюк и вручную ввести адрес с http:// всё же можно. Ладно, продолжаем изучать.

    permanent link

    2021/05/12 perlbrew upgrade

    Иногда в старой версии perlbrew (у меня была 0.43) перестаёт работать команда perlbrew available — список доступных версий не выдаётся. Для исправления этого нужно обновить perlbrew, но perlbrew self-upgrade тоже ничего не делает. В таком случае придётся обновлять perlbrew вручную:

    cd ~/tmp
    curl -kL http://get.perlbrew.pl -o perlbrew
    perl ./perlbrew self-install
    

    #perlbrew

    permanent link

    2021/04/30 franzoni

    Вот это, в частности, мне кажется очень важным злом в современных соцсетях:

    Can't mark things as read. Have you ever noticed that? [...] Facebook and Twitter simply don't allow this functionality. You cannot mark a tweet or post as read, it could resurface at any time. And you cannot see which posts or tweets you've not read yet — probably because the amount would be simple overwhelming. You need to waste your time on such websites.

    https://www.franzoni.eu/stopping-the-internet-of-noise/

    permanent link

    2021/04/27 libedit

    Как же я ненавижу libedit.

    Я уже более 15 лет пользуюсь Emacs и Tramp для редактирования файлов по ssh. Никаких проблем до сих пор не возникало. Потом кому-то взбрело в голову в FreeBSD-шной версии libedit включить edit mode по умолчанию. Недавно, чтобы перенести свой старый VDS, на котором порты перестали собираться из-за какого-то нового синтаксиса make, а обновить систему невозможно из-за kernel panic после обновления (тоже, кстати, очень показательная история), я поставил FreeBSD 12.2 на новый VDS. С удивлением обнаруживаю, что tramp виснет при попытке соединения. Пытаюсь что-то отлаживать, тщетно выискиваю в интернете похожие случаи, день угрохал, бесполезно. Однако надо что-то делать, переезд сервера застопорился, а платить приходится за оба. Где-то через месяц возвращаюсь к этой проблеме и в этот раз уже выхожу на верный след:

    https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=243807

    https://debbugs.gnu.org/cgi/bugreport.cgi?bug=39399

    Tramp запускает /bin/sh, которое слинковано с libedit, в котором именно в версии 12.2 было непременно кому-то надо ввести упомянутое новшество.

    Предлагаемые способы решения по своей нелепости сопоставимы с самой проблемой (предлагалось устанавливать пользователю временный .editrc со строчкой edit off! Впрочем, поскольку моя задача по возможности всегда избегать любых поделий с libedit, мне ничто не мешает, кажется, записать это в .editrc навечно.) В итоге, насколько я понял, остановились на добавлении или перемещении строчки (tramp-send-command vec "set +o vi +o emacs" t) (см. патч: https://debbugs.gnu.org/cgi/bugreport.cgi?msg=33;att=1;bug=39399), однако совершенно не в функциональном стиле написанный код tramp не позволяет мне просто переопределить для этого какую-то одну функцию, а патчить системный tramp неохота.

    Узнал также, что libedit происходит из NetBSD. Это очень печально. Я уж не знаю, какая система теперь не подала бы повода к разочарованию.

    permanent link

    2021/04/05 gcc10

    Решил попробовать пересобрать libpurple-vk-plugin, который несколько месяцев назад опять перестал работать, из-за чего я окончательно вынужден был перейти с удобного pidgin'а на браузер; надо было с этим когда-то покончить.

    Там оказался ненавистный мне cmake; поругиваясь (в cmake нету аналога make clean!), собрал, заработало. Однако размер библиотеки получился 13 Мб против 8 ранее. По умолчанию у меня сейчас gcc10. Совершенно правильно догадавшись, что дело в компиляторе, пересобрал с gcc5. Ожидаемые 8 Мб.

    Всё, что̀ нужно знать о современных/новейших версиях компиляторов.

    #pidgin #vk #gcc #gcc10

    permanent link

    2021/02/08 amusewiki

    На днях внезапно обнаружил perl-модуль PDF::Imposition (https://metacpan.org/pod/PDF::Imposition), с помощью которого решил почти все проблемы со спуском полос для книжиц (вернее, не то чтобы проблемы и были, но технология была довольно сложная, которую я постоянно забывал и которую потом надо бы описать отдельно), а тут ещё нашлась целая CMS от того же разработчика (несмотря на wiki в названии, её можно рассматривать именно как CMS, ориентированную на публикацию книг или структурированных статей):

    https://amusewiki.org/special/about

    A·Muse·Wiki (also spelled Amusewiki or amusewiki) is a library-oriented wiki engine and publishing platform. It can work as a read-only site, as a moderated wiki, or as a fully open wiki.

    It strives to be simple and yet powerful enough for long-term archiving of texts.

    Full support for high-quality printing of the texts is one of the core features.

    Этот же человек, кстати, является с некоторых пор разработчиком Interchange, о котором я писал ранее (https://www.interchangecommerce.org/i/dev/, https://github.com/interchange). Interchange, похоже, — довольно распространённая система: https://www.interchangecommerce.org/i/dev/hall. В частности, некий Bibliopolis (https://www.bibliopolis.com/) массово производит на нём сайты книжных.

    Попутно ещё отмечу обнаруженный при изучении других его репозиториев шаблонизатор без специального языка шаблонов, то есть на чистом html/xml, как Petal, но не ориентированный на подражание Zope: https://github.com/racke/Template-Flute.

    #amusewiki #interchange #perl #cms

    permanent link

    2021/01/14 mariadb readline

    Одной из причин перехода моего на MariaDB было то, что там клиент якобы собирается с libreadline по умолчанию. Увы, в FreeBSD это не так (и дело тут, возможно, в политике именно FreeBSD). Способа слинковать с системной libreadline так и не нашёл (спасибо зоопарку систем сборки и cmake в частности, мне некогда всех вас изучать), смог только статически собрать с bundled версией. Осталась проблема, как передать параметр CMAKE_ARGS="-DWITH_READLINE:BOOL=on (или, проще, CMAKE_ON="WITH_READLINE") в portmaster и сохранить для последующих пересборок. Так ничего и не придумав, пришлось просто подредактировать Makefile и оставить этот пост здесь на будущее. (Заодно попробовал убирание libedit из USES, но это ничего не дало.)

    #mariadb #readline #cmake #freebsd

    permanent link

    2021/01/14 dependency hell

    Очередная симптоматичная новость (https://www.opennet.ru/opennews/art.shtml?num=54402):

    Дистрибутивы Linux столкнулись с проблемой с разрастанием зависимостей у проектов. Если для кода на Python, Perl и Ruby число зависимостей держится в разумных пределах, то в проектах на JavaScript практикуется дробление на очень мелкие библиотеки, часто выполняющие одну простую функцию. Репозиторий NPM уже насчитывает более миллиона пакетов, а типовые приложения связываются с сотнями зависимостей, которые, в свою очередь, имеют свои зависимости, что усложняет сопровождение и распространение традиционных пакетов с JavaScript-приложениями в дистрибутивах Linux.

    Проблема, конечно, относится не только к JS и вообще не только к интерпретируемым языкам. Мне часто приходит в голову мысль, как бы я объяснил пользователю виндоус, что̀ вообще такое зависимости и почему он в своей жизни с ними никогда не сталкивался?

    В 2005 году на свойм первом компе (8Мб (мегабайт!) оперативки, i486, BlackCat Linux, кажется, 1998 года) я собирал для работы Apache 1.3, PHP 4, MySQL 3.23 и для своего удовольствия gopher- и wais- сервера и клиенты (код тоже в основном из 90-х) и ещё что-то. Помню, MySQL собирался 2 дня — я успел на выходные съездить куда-то за город, вернуться и помыться, и к тому времени он собрался. И я не помню, чтоб я сталкивался вообще с какими-либо зависимостями. У меня тогда не было столько опыта, чтобы я смог бы их разрешить, а ресурсы машины не позволяли особо экспериментировать, сборка растянулась бы на недели. Однако все нужные библиотеки были в дистрибутиве (умещавшемся на одном CD). Единственное что̀ — некоторые программы пришлось собирать с помощью egcs вместо gcc. Но в дистрибутиве были оба, ничего доустанавливать не пришлось. В тех редких случаях, когда не было уверенности, сто́ит ли собирать вручную, я ставил пакеты с сайта rpmfind.net. Они были не привязаны к дистрибутиву — по крайней мере, rpm с этого сайта в 2005 году каким-то образом нормально ставились и работали на маргинальном российском дистрибутиве конца 90-х. Вообще BlackCat был очень уютной системой. Из-за этого я потом, добыв более новый комп, поставил туда его потомка ASPLinux, но это было уже не совсем то.

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

    Что̀ мы имеем сейчас даже только со сборочными зависимостями — я уже описывал в постах про pkgsrc. Из недавнего опыта — собирал MariaDB на Slackware, из-за какой-то единственной синтаксической конструкции требуется определённая версия gcc (и об этом ни слова не сказано в документации!), кроме того, есть и требования к версии cmake, причём реальность отличается от того, что̀ указано в документации, и мало того, для отдельных включённых в дистрибутив модулей хранилищ эти требования разные!

    permanent link

    2020/12/25 html5up

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

    https://html5up.net/

    (кажется, передрано всё дико с водпресса, но код куда чище)

    #html5

    permanent link

    2020/12/15 linux agile

    Вчера:

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

    После двух месяцев разработки Линус Торвальдс представил релиз ядра Linux 5.10. Выпуску 5.10 решено присвоить статус ветки с длительным сроком поддержки, обновления для которой будут выпускаться не менее двух лет. <...>

    Сегодня:

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

    Примерно через сутки после релиза ядра Linux 5.10 сформирован корректирующий релиз 5.10.1, в котором отменены два изменения в подсистемах md и dm raid, в которых всплыли проблемы. Первое изменение касалось перевода типа переменной chunk_sectors с int на unsigned, а второе изменяло лимит на выполнение операции discard для raid1 и raid10.

    Уже не смешно. Остановитесь уже. Пора создавать петицию за прекращение выпуска новых версий ПО. (И «отменены два изменения», а не «исправлены» — да, это, пожалуй, лучшее решение в таких случаях.)

    UPD 05.03.2021:

    Линус Торвальдс предостерёг пользователей о выявлении в экспериментальном выпуске ядра 5.12-rc1 критической проблемы, посоветовал не устанавливать для тестирования данную версию и переименовал Git-тег "v5.12-rc1" в "v5.12-rc1-dontuse". Проблема проявляется при использовании файла подкачки и может привести к повреждению данных в файловой системе в которой размещён данный файл.

    (https://www.opennet.ru/opennews/art.shtml?num=54703)

    #linux #agile

    permanent link

    2020/12/13 freebsd git

    Сегодня, 13 декабря, страницы с документацией FreeBSD исчезли с сайта. https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/index.html и всё остальное, кроме, как говорят, китайских и японских версий, выдаёт ошибку

    Page not found.
    Oh no. :(
    We could not find the page you requested.
    
    Please try your request again, use one of the links in the
    navigation menu, or the search box at the top of the page.
    

    Смотрю архив списка рассылки freebsd-doc, пытаясь найти что-то имеющее отношение к делу — похоже, проблема возникла сегодня и её несколько человек уже заметили (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=251800, но на удивление мало для проекта такого масштаба). Зато предыдущее сообщение в рассылке, от 5 декабря, гласит следующее:

    I have just deployed the update to build the website and docs from git
    instead of subversion, as the share/tools/webupdate{,.wrapper} are not
    automatically deployed following a commit.
    
    (https://docs.freebsd.org/cgi/getmsg.cgi?fetch=66662+0+archive/2020/freebsd-doc/20201206.freebsd-doc)
    

    Как говорится, «совпадение? не думаю». Документация была недоступна более 12 часов. Исправил тот же человек, который внёс новшество выше (https://docs.freebsd.org/cgi/getmsg.cgi?fetch=48043+0+current/freebsd-doc). К сожалению, причины происшедшего из его объяснения мне не ясны. Но приключения с документацией продолжаются: https://docs.freebsd.org/cgi/getmsg.cgi?fetch=119432+0+current/freebsd-doc (добавление 16.12).

    Добавление 18.12: тучи сгущаются. "Проект FreeBSD объявил о начале миграции основного репозитория с исходными текстами из централизованной системы управления исходными текстами Subversion в децентрализованную систему Git." (https://www.opennet.ru/opennews/art.shtml?num=54276). И 10 лет не успело пройти, как мигрировали на svn. Как можно всерьёз воспринимать проект, где за 10 лет 2 раза меняется система контроля версий? Или это просто одно лобби сменяет другое? Тем временем реальные люди практически перестают пользоваться системой, она переходит в разряд маргинальных, но никто никаких выводов не делает.

    Было бы интересно посмотреть где-то статистику, как FreeBSD теряла серверный рынок после прекращения поддержки ветки 4.x и как это было связано с переходом на agile-подобную схему выпуска версий и последовавшей чехардой релизов, сделавшей прежнюю реальность «по 10 лет без перезагрузки» уже неосуществимой мечтой, в которую современный админ, не могущий шагу ступить без докера, даже и поверить не сможет.

    #freebsd #git #agile

    permanent link

    2020/12/08 leverton

    Какой прекрасный дизайн!

    http://www.leverton.org/ http://www.leverton.org/blosxom/

    Там же про фотогалереи для blosxom.

    http://www.leverton.org/blosxom/Software/Projects/

    #blosxom

    permanent link

    2020/12/04 eav

    http://mysql.rjweb.org/doc.php/eav

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

    Хороший комментарий в другом обсуждении того же вопроса (https://karwin.blogspot.com/2009/05/eav-fail.html):

    How does one go about convincing "agile" developers that EAV is a poor choice, given that they see it as a way to speed up their development time.

    Ещё случайно нашёл такое:

    https://r.je/4-reasons-to-avoid-foreign-key-constraints-database-logic

    Современная молодёжь (судя по фото и по используемым технологиям) серьёзно считает, что до бума PHP в начале нулевых, когда заодно взлетели MySQL и его MyISAM, никаких реляционных баз не было?!

    #sql #eav #json

    permanent link

    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/. И ещё: http://en.jnlin.org/2008/06/07/12/">http://web.archive.org/web/20180216222136/http://en.jnlin.org/2008/06/07/12/. А вот как расшарить дерево портов между jail'ами: https://forums.freebsd.org/threads/sharing-ports-directory-with-jails.18421/.

    #freebsd #jail

    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, но более общая и для меня подходящая команда здесь: https://www.netbsd.org/docs/pkgsrc/getting.html, может также понадобиться export SH=/bin/bash перед запуском bootstrap) не забыть прописать новые пути:

    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";.)

    UPD: также добавил в /etc/apt/apt.conf.d/99zzz:

    APT::Install-Recommends "false";
    APT::Install-Suggests "false";
    

    — что̀ бы там кто ни возражал (https://askubuntu.com/questions/179060/how-to-not-install-recommended-and-suggested-packages). Иначе потом полжизни разгребать наставленный мусор. По ссылке выше также сказано, что в новых версиях "0" вместо "false".

    #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, всё больше, и приходится всё чаще включать скрипты с основного домена сайта, чтоб хоть что-то увидеть, и избирательно со сторонних доменов. И я прихожу в ужас от обилия этих никчёмных сторонних сервисов, которые стало модно пихать себе в сайты. В этом посте я буду записывать сведения о доменах разных скриптов, чтобы помнить, что̀ они делают и насколько надо их отключать. Зачастую даже изучив сайт того или иного скрипта, невозможно понять, что̀ он делает и зачем он вообще кому-то мог понадобиться. Джаваскриптовый психоз рано или поздно заставит меня полностью уйти в гофер.

    • polyfill.io — полифиллы (фичи JS для разных устаревших браузеров)
    • jsdelivr — CDN для npm и jquery
    • criteo — advertising
    • unpkg — CDN
    • redhelper — онлайн-консультант (ненавижу, отключать обязательно!)
    • newrelic — performance service (???)
    • ravenjs — is the (legacy) browser JavaScript SDK for Sentry. Sentry provides open source error tracking for development teams that shows every crash in the user stack as it happens, with the details needed to prioritize, identify, reproduce, and fix each issue (то есть они какие-то свои девелоперские костыли оставляют в коде, который нам выдают в браузере, или что?)
    • typekit.net — Adobe's hosted web font service
    • app.link — не пойми что̀, но оказалось нужно для воспроизведения видео с Vimeo
    • doubleclick.net — реклама! убивать!!!
    • carrotquest.io — "сервис для увеличения продаж, автоматизации маркетинга, улучшения коммуникации с клиентами" — зло!!!
    • akamaized.net — to accelerate the delivery of Web files by placing copies on servers closer to the user than the server that delivers the main file for a Web page. Без него vimeo не работает.

    permanent link