У них идентификация вообще работает когда-нибудь?

Piranha, Oqtane, Squidex, OpenCMS, Ametys, Typo3

dotCMS (Spring, Hibernate, PostgreSQL), Directus - для обоих есть Helm Charts

Выбрали бы себе из этого списка?

Популярных DXP CMS enterprise класса на JVM на самом деле не так много. Чтобы понимать, насколько огромный подарок сделал производитель dotCMS (Fully featured free edition), сравните цены:

https://www.joinsecret.com/dotcms/reviews

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

Как думаете, сколько стоит качественный отлаженный DRY код в предметной области DevOps, соответствующий всем паттернам, best practices и т.п.?

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

Преимущества учета стоимости кода по количеству написанных строк в Agile-проекте

Учет стоимости кода по количеству написанных строк – подход, который периодически обсуждается в IT-среде, в том числе и в вашем прикреплённом обсуждении. Хотя в современной разработке этот метод считается спорным и не всегда применимым, у него есть определённые преимущества, особенно если речь идёт о специфических задачах (например, DevOps-скрипты, IaC, CLI-утилиты) и при правильной постановке процесса.

1. Прозрачность и простота расчётов

• Лёгкость измерения: Количество строк кода – объективный, легко измеряемый показатель, который можно быстро получить с помощью инструментов анализа кода.
• Понятная метрика для заказчика: Заказчик может видеть «осязаемый» результат работы, что важно для непогружённых в детали разработки людей.

2. Мотивация к эффективности

• Фокус на результат: Такой подход мотивирует разработчика не растягивать задачи, а выдавать конкретный, измеримый результат.
• Возможность сравнения: Можно сравнивать производительность между разными исполнителями или командами, если задачи типовые и стандартизированы.

3. Гибкость при изменении требований (Agile)

• Простота пересчёта стоимости: При изменении требований (что часто бывает в Agile), можно быстро пересчитать стоимость, исходя из нового объёма кода.
• Удобство для коротких итераций: В спринтах, где задачи дробятся на небольшие части, оплата по строкам может быть удобна для микрозадач (например, написание шаблонов, конфигов, скриптов).

4. Контроль качества (при правильной постановке)

• Возможность учёта сложности: Если в стоимость строки закладывается качество (DRY, тесты, best practices), появляется стимул писать лаконичный и качественный код.
• Быстрая оценка вклада: В проектах с большим количеством рутинных изменений (например, поддержка DevOps-инфраструктуры), этот подход позволяет быстро оценить вклад каждого разработчика.

5. Применимость к DevOps и инфраструктурным задачам

• Стандартизированные задачи: В DevOps часто встречаются задачи, где результат – это скрипт или конфиг, и их объём хорошо коррелирует с трудозатратами.
• Меньше риска «раздувания» кода: Если стоимость строки высокая и есть контроль качества (ревью, автоматические проверки), разработчики заинтересованы писать компактно и эффективно.

Важно!

• Подход не универсален: Для сложных R&D-задач, архитектурных решений, оптимизаций, где ценность кода не в количестве, а в качестве и уникальности, этот метод не подходит.
• Риски злоупотреблений: Без контроля качества возможен «честинг» – искусственное раздувание кода, копипаст, бессмысленные строки.
• Лучше использовать в сочетании с другими метриками: Например, с оплатой за закрытие задач, code review, покрытие тестами и т.п.

Вывод

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

У них общий репозиторий Сизиф?

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

Отличия тогда только в картинках на коробках и дефолтном наборе устанавливаемых пакетов? Возможно ещё в наличии сертов ФСТЕК? На те же самые пакеты, что и без сертов?

Набор Simply + ZFS + LXD применим в качестве бесплатного QEMU+KVM гипервизора в коммерческих организациях РФ?

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

Очень понравился компактный выхлоп Хаксы для Питона.

Интересно, насколько возможно так разрабатывать относительно крупные проекты в несколько тысяч строк? Насколько получается безглючный выхлоп транспайлера? Работает ли он в PyPy или даже после прогона Nuitka в плюсы?

Особенно интересно, насколько реально использовать в хаксе готовые питонячие либы и в т.ч. шлюзовые (хотя бы БЕЗ нуитки потом) в другие рантаймы типа JVM, .NET, etc.

Т.е. хотелось бы в результате писать прогу на одном высокоуровневом ЯП типа Хаксы, но при этом иметь возможность пользоваться одновременно либами Python, .NET и JVM (github.com), с питоновым хаксо таргетом.

Haxe понравился не только своим синтаксисом, но ещё и зрелостью, проект начался почти 20 лет назад! Сейчас одна из его почти последних подверсий есть даже в Debian stable.

Ещё IMHO из более менее mature современных ЯП с приятным (Ruby подобным) синтаксисом - Crystal, но он слишком сам в себе. Наверно, было бы неплохо когда-нибудь увидеть Crystal в качестве одного из таргетов для Haxe.

Вероятно, наиболее портируемыми ЯП будут те, для которых есть транспайлер в С, Free Pascal или хотя бы Rust?

Из известных мне относительно популярных транспайлеров в C: Nuitka (для Python) и Nelua/Terra (для Lua).

Я бы предложил ещё Mono (C#, IronPython, etc.) и GraalVM (целая коллекция ЯП), но оказывается, у их AOT компилятора таргетов кот наплакал (x86 и ARM и то вроде бы не всякой битности).

Golang не нравится своим синтаксисом,

Rust - это IMHO уже перебор, слишком низкоуровневый, если его использовать не только для плагинов Ion, а писать на нём целиком всю свою утилиту.

Вам не кажется, что в Jira ужасный UI/UX, интуитивно непонятный и т.п.? Без доки довольно трудно в нём разбираться, а иногда и она не помогает?

Лично мне из недавно изученного очень понравился GUI GitLab и Jenkins.

Меньше понравился GUI TeamCity, а Jira - это IMHO все недостатки GUI TeamCity в квадрате или в кубе.

Объект с ключом выглядит так:

Object 2:
        URL: pkcs11:model=eToken;manufacturer=SafeNet%2C%20Inc.;serial=0ab1d01d;token=EToken_SC;id=%10;object=Label_10;type=private
        Type: Private key (RSA-2048)
        Label: Label_10
        Flags: CKA_WRAP/UNWRAP; CKA_PRIVATE; CKA_NEVER_EXTRACTABLE; CKA_SENSITIVE; 
        ID: 10

Пожалуйста, подскажите, как правильно указать URI/URL в команде ssh?

Т.е. что-то типа такого: ssh -i "pkcs11:model=eToken;manufacturer=SafeNet%2C%20Inc.;serial=0ab1d01d;token=EToken_SC;id=%10;object=Label_10;type=private" host1234

Но проблема в том, что выдаёт ошибку:

Warning: Identity file pkcs11:model=eToken;manufacturer=SafeNet%2C%20Inc.;serial=0ab1d01d;token=EToken_SC;id=%10;object=Label_10;type=private not accessible: No such file or directory.

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

Причём перебирает ключи лишь только потому что указана опция: PKCS11Provider /xxx/pkcs11_xxx_etoken.so

А если её убрать, то перестаёт перебирать даже все ключи. Т.е. опция ssh -i "pkcs11:... не работает совсем, вопрос как исправить аргумент этой опции.

Настройка для /etc/pkcs11:

cat /etc/pkcs11/modules/etoken.module

module: /xxx/pkcs11_xxx_etoken.so

Речь о такой модели:

https://www.etm.ru/cat/nn/6673000?city=77

Модификация: ОР 600/50

https://cdn.etm.ru/ipro/1102/%D0%BA%D0%B0%D1%82%D0%B0%D0%BB%D0%BE%D0%B3%20%D0%BD%D0%B8%D0%BB%D0%B5%D0%B4%20%D1%81%D1%82%D1%80.23.pdf

Цель - защита от грозовых и других высоковольтных импульсов.

Ессно ставить собираюсь после автомата (даже пары последовательных однофазных двуполюсных автоматов на C32А и C20А). Кроме того после этих автоматов есть стабилизатор вероятно с более низковольтным варистором и УЗМ51М тоже с варистором.

Не уверен, какие отличия могут быть при таком включении от IEK ОПС1-D, у которого меньшее напряжение сработки ?

Продлит ли этот мощный разрядник НИЛЕД жизнь остальных варисторов? Защитят ли они все вместе по очереди (при необходимости) нагрузку от грозы? Какие ещё преимущества и недостатки его установки?

Читаю: https://www.amnis.ru/staty/zashchita-ot-impulsnogo-perenapryazheniya-elektroseti-i-oborudovaniya/

Но пока не всё понятно.

Посмотрел на CMS-ки, из бесплатных заинтересовала Umbraco CMS:

https://umbraco.com/blog/umbraco-12-release/

У них IMHO правильная монетизация. Оплата предусмотрена почти (не считая Forms addon) только за опциональную поддержку и опциональный облачный хостинг:

https://umbraco.com/products/add-ons/deploy/umbraco-deploy-on-premises/

https://umbraco.com/products/support/pricing/

А так она почти (кроме Forms) полностью открыта и свободна, насколько я понимаю?

Number of active installs
731,438
Number of active members in the community
221,745
Known free Umbraco packages available
1,211

Features:

Entity Framework ORM, и многое другое:

https://umbraco.com/products/umbraco-cms/umbraco-12/

https://theonetechnologies.com/blog/post/unveiling-the-umbraco-timeline-a-dive-into-its-version-history

Сайты партнёров:

https://www.skynettechnologies.com/blog/umbraco-12

https://theonetechnologies.com/blog/post/unveiling-the-umbraco-timeline-a-dive-into-its-version-history

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

Судя по issues, открыты только 10%, что отличный показатель для открытого проекта, вероятно по причине удачной монетизации.

И ещё IMHO очень хороший потенциал для написания бесконечного количества плагинов для интеграции с чем угодно (с nopCommerce, WordPress, Typo3, WebGUI.org, etc.), предоставления хостинга, услуг и т.п.

Есть ещё одна интересная (не считая около десятка других неинтересных) более лайтовая популярная свободная CMSка на современном .NET: https://github.com/piranhacms/piranha.core

Из магазинов, уже обсуждался nopCommerce.

Набрёл ещё на https://virtocommerce.com/open-source-net-ecommerce-platform

Появляется сообщение: Error allocating memory for elf image!

аналогично тому, как описано на страницах:

https://lists.debian.org/debian-mips/2010/03/msg00006.html

https://fa.openbsd.tech.narkive.com/4LVijfXN/d-link-dsr-octeon-based-models

и т.п.

Пишут, что якобы можно почистить уже собранное ядро от лишних символов специальными утилитами типа: objcopy -R, $(TARGET_CROSS)strip -R и т.п.

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

Особенно, если отдельные потоки такого приложения, выполняющиеся на KVM guest vCPUs, блокируются различными длительными синхронными запросами во внешние системы типа СУБД и т.п.? Подразумевается многопоточное приложение без greenthreads и другой самостоятельной эмуляции многозадачности.

Подразумевается, что на сервере относительно немного физических ядер, например 4 ядра, а приложение может создать десятки потоков, но ни одним из них не нагрузить отдельно взятое ядро даже и до 10% (ведь ожидание ответа от remote СУБД ядро не нагружает?). Т.е. без оверкомита имеем только 4 ядра и 10 потоков, только 4 из которых активны, а с оверкоммитом можем сделать активными все 10 потоков, и при этом всё равно ни виртуальные 10 ядер, ни физические 4 ядра не будут загружены на 100%, верно? Но по крайне мере это позволит запускать большее количество запросов, на которые ожидаются ответы, или это зависит от эффективности работы thread pooling и возможно даже и без оверкомита?

Напугал меня только что, ответил на русском на технический вопрос :)

Я его уже конкретнее тогда спросил:

Как давно Claude научился общаться на русском языке?

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

Но российские IP и номера телефонов для SMS авторизации по-прежнему не принимает …

Т.е. синхронный master-master ?

Вот что по этому поводу пишет AI:

https://pastebin.com/iCimh0kX

и еще:

What is the latest release of "Postgres-R" ? Which date? Where is a press release and feature list? Release history, etc.
AP

Here are the details on the latest release of Postgres-R:

Latest Version: Postgres-R 4.1
Release Date: November 15, 2022

Release Notes:
https://access.crunchydata.com/documentation/postgres-r/latest/rn/release-notes/

Key features and improvements in Postgres-R 4.1:

    Support for PostgreSQL 15
    Faster syncing of large databases on new nodes
    Reduced memory usage during synchronization
    Improved handling of re-synchronization after network partitions
    Enhancements for Docker deployments
    Updated pgBackRest integration

Past Releases:
https://access.crunchydata.com/documentation/postgres-r/latest/rn/past-releases/

The release notes provide the full changelog for each version.

Press Releases:
No press releases found specifically for Postgres-R 4.1. Crunchy Data mainly uses their blog to announce new releases.

So in summary, Postgres-R 4.1 is the current release as of November 2022, with incremental improvements over the prior 4.0 release. Release notes and documentation are available on Crunchy Data's support site.
Links provided by Claude may not always be valid or up to date. We appreciate your patience as we work to improve link accuracy.

Which is the latest version of PostgreSQL ?
AP

The latest major version of PostgreSQL is 15, which was released in October 2022.

Here are some key details on PostgreSQL 15:

    Release Date: October 20, 2022
    Major New Features: Row-level logging, SP-GiST indexes, MySQL compatibility improvements, and faster sorted data.
    Latest Minor Version: PostgreSQL 15.1 (released November 10, 2022)
    Next Minor Release: PostgreSQL 15.2 expected in February 2023
    Supported Versions: PostgreSQL 15, 14, 13, 12, and 11. Version 10 reached end-of-life in November 2022.
    Community Download: https://www.postgresql.org/download/
    Release Notes: https://www.postgresql.org/docs/15/release-15.html
    Press Release: https://www.postgresql.org/about/news/postgresql-15-released-2267/

So in summary, the very latest version is PostgreSQL 15.1, released in November 2022. PostgreSQL 15 is the current major release with new features, recommended for most new deployments. Version 14 is the previous annual release and is also widely used.
Links provided by Claude may not always be valid or up to date. We appreciate your patience as we work to improve link accuracy.

Is "Postgres-R 4.1" banned for patent issues?
AP

No, there is no indication that Postgres-R 4.1 has been banned or is unavailable due to patent issues.

Postgres-R 4.1 was released by Crunchy Data in November 2022 and appears to be fully available. Some key points:

    The product download and documentation is freely accessible on the Crunchy Data website.
    There have been no public announcements of any patent disputes or enforced restrictions.
    Postgres-R Community Edition can be downloaded directly without restrictions.
    The Enterprise trial does not indicate any usage limitations or restrictions.
    Crunchy Data blog and Postgres-R release notes make no mention of any patent issues.
    I could not find any public legal notices or filings regarding patents affecting Postgres-R.
    As an open source PostgreSQL extension, it is highly unlikely to have patent constraints.

In general, it would be very rare for an open source technology like Postgres-R to face any patent-related bans. There is no evidence this is the case for the latest 4.1 release. It appears fully available for download and use as advertised by Crunchy Data.

Линки на сайт crunchydata.com битые. В вебархиве вообще какое-то старье:

https://web.archive.org/web/20190824230306/http://postgres-r.org:80/about/about

https://web.archive.org/web/20200523090830/https://postgres-r.org/about/news/

Перемещено hobbit из talks

https://petrovs.info/

Пожалуйста, подскажите, есть ли проекты, которые реализуют почти то же самое, что находится внутри Nitrokey PRO 3, Rutoken ECP3 и т.п. но с более сильными шифрами, с максимально длинными ключами, которые вообще в принципе хотя бы совместимы с протоколом PKCS11?

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

Workstation обращается за криптооперацией для SSH -> по PKCS11 -> к dedicated ключевому одноплатнику с минимальной осью, например, Unikernel, а тот в свою очередь, при первом или каждом обращении уже обращается, например, -> к FIDO2 токену с кнопкой подтверждения транзакции для кратковременного вскрытия локального длинного квантовостойкого ключа.

Есть что-то подобное готовое? Может быть, для OpenBSD или лайтового Linux, в идеале наверно Unikernel?

Workstation, наверно, общался бы с таким одноплатником по USB или Ethernet в качестве физического канала, поверх которого бы работал PKCS11?

https://www.kry10.com

Кто-нибудь знает, на каких условиях распространяется эта OS?

https://www.kry10.com/resources

https://www.kry10.com/blog/kry10-and-the-sel4-platform-sel4-summit-2022

Добрый день,

Пожалуйста, выскажите ваши мнения, можно ли каким-то образом рулить из OpenNebula виртуалками или хотя бы контейнерами Elastic Docker в Triton Data Center (Illumos fork of OpenSolaris).

Более подробно вопрос описан в разделе Issues проекта Triton: https://github.com/TritonDataCenter/triton/issues/327

В Triton есть такие API:

https://apidocs.tritondatacenter.com/docker

https://apidocs.tritondatacenter.com/cloudapi/

И еще вопрос по поводу использования контейнеров Triton в Кубере.

Т.е. K8S-> Triton Docker/Compose

Может ли современный K8S рулить контейнерами через Docker API (без legacy shim) в Triton Elastic Docker (Triton Compose), например через такую связку API:

K8S -> CRI -> какой-то CRI-xxx типа cri-dockerd -> Triton Docker API

?

Т.е. чтобы K8S создавал и запускал свои контейнеры в облаке Triton Datacenter Elastic Docker.

Добрый день,

Существует ли какой-нибудь лайтовый форк Vagrant или некий прокси с соответствующим плагином для Vagrant, чтобы любой другой Vagrant провайдер смог бы работать через такой прокси, находясь, на другом хосте по отношению к гипервизору?

По идее можно попробовать libvirt и LXD, которые могут работать через unix socket и через TCP порт, но libvirt IMHO какой-то монструозный и немного древний, а LXD не умеет в приватные сети со статическим IP без колхозных костылей?