Внимание! Cообщения отображаются точно так же, как
они будут выглядеть на главной странице. Если ваше сообщение отображается не так, как вы хотели, или
в нем не работают какие-либо ссылки, пожалуйста,
исправьте его.
Внимание модераторам! Не подтверждайте сразу
много скриншотов, дайте им повисеть на главной странице.
После шести месяцев разработки проект GNU представил свободную систему электронных платежей GNU Taler 1.1. Платформа признана готовой для внедрения рабочих платёжных сервисов и уже может законно применяться для продажи товаров в Швейцарии. Предприятиям, желающим наладить оплату продаж при помощи GNU Taler, достаточно иметь счёт в любом швейцарском банке и запустить предоставляемый платформой бэкенд для организации продаж.
Код GNU Taler написан на Си и распространяется под лицензиями AGPLv3 и LGPLv3. В состав входят базовые компоненты, позволяющие организовать работу банка, точки обмена, торговой площадки, кошелька и аудитора. Система позволяет идентифицировать продавцов для налоговой отчётности, но обеспечивает анонимность для покупателей. Финансирование разработки осуществляется на гранты Еврокомиссии и Государственного секретариата Швейцарии по образованию, исследованиям и инновациям (SERI).
Платёжная система GNU Taler не завязана на собственной криптовалюте и работает с уже существующими валютами, такими как доллары, евро и биткоины. Поддержка новых валют осуществляется через привязку к банку, выступающему финансовым гарантом производимых операций. Проект продвигает бизнес-модель, основанную на операциях обмена - деньги из традиционных систем совершения платежей, таких как BitCoin, Mastercard, SEPA, Visa, ACH и SWIFT, преобразуются в анонимные электронные деньги в той же валюте. Пользователь может передавать электронные деньги продавцам, которые затем могут на точке обмена поменять их обратно в реальные деньги.
Уже совершённые транзакции в GNU Taler сохраняют достоверность даже при утечке приватных ключей клиентов, продавцов и точек обмена - формат базы данных позволяет верифицировать все совершённые транзакции и подтверждения их непротиворечивости. Подтверждением платежа для продавцов является криптографическое доказательство перевода в рамках заключённого с клиентом контракта и криптографически подписанное подтверждение о наличии средств на точке обмена. Система не позволяет узнать куда клиент тратит деньги, но даёт возможность отследить поступление средств получателю, сохраняя анонимность отправителя. Подобный подход решает проблемы с налоговым аудитом, свойственные BitCoin.
Для организации работы точки продаж, управления платежами и обслуживания заказов предоставляется приложение для платформы Android, оптимизированное для расчёта с посетителями в ресторане. Имеется плагин для интеграции запускаемого платёжного сервиса с платформой для создания интернет-магазинов WooCommerce, а также плагин для платформы продажи билетов Pretix.
В новой версии:
Добавлена опция для саморазвертывания (self-provisioning) бэкенда merchant, обеспечивающего проведение платежей и настройку заказов в точках продаж.
В бэкенде merchant реализованы средства для управления токенами доступа.
Реализован расширенный новый формат контрактов (v1), позволяющий реализовывать различных варианты взаимодействия между продавцами и кошельками (wallet), включая донаты, подписки на услуги, купоны и обмен валют.
Добавлена экспериментальная поддержка приёма токенов, подтверждающих наличие подписок и предоставление скидок.
Реализована поддержка двухфакторной аутентификации при подтверждении сброса пароля, при подключении к бэкэнду продавца и при аутентификации обмена платёжной информацией при помощи утилиты libeufin-bank.
Добавлена поддержка классов комиссий на операции вывода денежных средств.
В приложениях для iOS и Android реализована возможность разблокировки кошелька, используя предоставляемые платформами функции разблокировки устройства.
Опубликован выпуск проекта uutils coreutils (Rust Coreutils) версии 0.4.0, развивающего аналог пакета GNU Coreutils, написанный на языке Rust. В состав coreutils входит более ста утилит, включая sort, cat, chmod, chown, chroot, cp, date, dd, echo, hostname, id, ln и ls. Целью проекта является создание кроссплатформенной альтернативной реализации Coreutils, среди прочего способной работать на платформах Windows, Redox и Fuchsia.
Rust Coreutils задействован по умолчанию в выпуске Ubuntu 25.10 и применяется в дистрибутивах AerynOS (Serpent OS) и Apertis (развивается компанией Collabora). В отличие от GNU Coreutils реализация на Rust распространяется под пермиссивной лицензией MIT, вместо копилефт-лицензии GPL. Дополнительно той же командой разработчиков развиваются написанные на Rust аналоги наборов утилит util-linux, diffutils, findutils и procps, а также программ sed и login.
В новой версии Rust Coreutils:
Улучшена совместимость с эталонным тестовым набором GNU Coreutils, при прохождении которого успешно выполнено 544 теста, что на 12 больше, чем в прошлой версии (532). 56 (68) тестов завершилось неудачей, а 33 (33) теста было пропущено. Заявлен уровень совместимости 85.80% (было 83.91%).
В утилите dateулучшена совместимость с GNU date при обработке часовых поясов (добавлена возможность указания сокращённых наименований часовых поясов в опции –set).
*В утилите factor задействован пакет num_prime для ускорения факторизации типов u64/u128.
*В утилите tsort реализация алгоритма обхода DFS переведена с рекурсивного на итеративный метод работы для предотвращения переполнения стека.
В утилите cksum реализована поддержка хэшей sha2 и sha3. Добавлены тесты для отслеживания изменения производительности cksum. Функциональность hashsum перенесена в cksum.
В утилите mkdir устранено переполнение стека, приводящее к аварийному завершению при создании большого (200+) числа вложенных каталогов.
В утилитах stdbuf и uptime реализована поддержка платформы OpenBSD.
Улучшена сборка и тестирование на платформе FreeBSD.
Внесены общие улучшения для повышения переносимости.
Расширены возможности, устранены проблемы и добавлены недостающие опции для утилит base64, cat, chown, chsum, date, dd, du, factor, hashsum, install, ls, mkdir, od, printenv, printf, readlink, stdbuf, timeout, truncate, tsort, uptime, uudoc.
Стоит отметить расхождение в поведении утилиты du из наборов uutils и GNU Coreutils, всплывшее после перехода Ubuntu 25.10 на uutils. Разработчики ещё не решили трактовать ли данное расхождение как ошибку, так как с одной стороны в поведении uutils есть логика и тестовый набор GNU Coreutils не выявляет проблем, но с другой стороны несовместимости с GNU Coreutils предписано обрабатывать как ошибки и поведение Busybox соответствует GNU Coreutils.
Разное поведение наблюдается при указании в числе аргументов утилиты du нескольких каталогов в ситуации, когда некоторые из каталогов являются подкаталогами других каталогов (например, /var и /var/log). Uutils показывает фактический размер каждого отдельного каталога, а в итоговой строке выводит суммарный размер всех указанных каталогов. GNU Coreutils показывает в итоговой строке фактический размер, который указанные каталоги занимают на диске, но в раздельном списке показывает размеры каждого каталога с вычетом вложенных каталогов, из-за чего их размер получается меньше фактического. Кроме того, значения, выводимые в GNU Coreutils и Busybox, меняются в зависимости от порядка указания каталогов.
Например, при проверке размера каталогов /var/log и /var, фактический размер которых 1540 и 35495 блоков (МБ).
В GNU Coreutils будет выведено:
du -smc /var/log /var
1540 /var/log
33955 /var # меньше фактического
35495 total
du -smc /var /var/log
35495 /var # показан только /var и не показан /var/log
35495 total
В uutils:
du -smc /var/log /var
1540 /var/log
35495 /var
37034 total # больше фактического, но соответствует сумме /var и /var/log
du -smc /var /var/log
35495 /var
1540 /var/log
37034 total # больше фактического, но соответствует сумме /var и /var/log
В Busybox:
du -smc /var/log /var
1540 /var/log
33955 /var # меньше фактического
35495 total
du -smc /var /var/log
35495 /var # показан только /var и не показан /var/log
35495 total
При эксплуатации конвекционных ротационных печей возникла проблема с ремонтом шкафов управления и панелей оператора. Во-первых стоят дорого, во-вторых, после ввода санкций, многие компоненты официально перестали поставляться и стали еще дороже… Поэтому возникла идея собрать свой шкаф управления с панелью оператора. Есть готовое решение от КИП-Сервис - BakeControl https://kipservis.ru/control_box/BakeControl.htm. Уверен, что их решение прекрасно работает. Но использованный контроллер явно не позволяет хранить большое количество данных с прорисовкой режимов работы в виде графиков и возможностью удаленного подключения для редактирования рецептов и режимов печи. А самое главное — нет возможности самим изменить программу для своих специфических задач. Поэтому решил сделать свою систему управления на доступных устройствах, что вдобавок к указанным преимуществам, снимает зависимость от производителя и уменьшает стоимость.
Trim / Over Provisioning: Всё, что мне известно про SSD в Linux
Все вы, наверное, слышали про то, что для долгой службы SSD на нём следует держать 10%-20% свободного места; и почти все слышали, что самый эффективный метод — держать на SSD неразмеченное пространство. — Данный метод называется «Over Provisioning» (что-то вроде «Сверх Обеспечение»). Но Овер-Провиз. одним только оставлением свободного пространства — чаще всего не заведётся, так как для этого требуется Discard ячеек. Я очень подробно распишу всё ниже.
Сейчас лишь добавлю, что и про Trim напишу.
Критическое замечание про SSD
Если у вас примонтирован виндовый SSD через NTFS-3G, то fstrim.timer будет вешать в ОС всю дисковую подсистему на 10-15 минут в состояние паузы/ожидания. Ни за что не жмите кнопку «RESET» — смотрите на индикатор работы дисков на вашем системнике, и просто подождите, пока ОС «отлипнет».
Over Provisioning
Что очень интересно, что двумя кликами включить Овер-Провиз. можно только под виндой и для винды, с помощью фирменных приложений вендоров. Но этот софт не работает для линуксовых SSD.
Линуксовые-же мануалы, предлагают зачастую использовать blkdiscard с байтовыми диапазонами (позиция начала неразмеченного пространства и длина). — НИКОГДА НЕ ДЕЛАЙТЕ НИЧЕГО ПО ЭТИМ МАНАМ, т.к. вы можете запороть последнюю запись GUID Partition Table и/или хвост Swap (или другого последнего своего раздела).
Я придумал более простой, универсальный, надёжный и безопасный метод. Всё очень просто: создаём с помощью GParted раздел БЕЗ ФС во всей неразмеченной области (Нам не нужны там иноды, экстенты, журналы, FAT или MFT). СОХРАНЯЕМ. Теперь натравливаем на этот раздел sudo blkdiscard /dev/sdXY … таким образом, ячейки находящиеся в пределах раздела обнулились и об этом был оповещён контроллер, — МЫ ПОДАРИЛИ МНОГО СВОБОДНОГО МЕСТА КОНТРОЛЛЕРУ, ДЛЯ РОТАЦИИ.
Чем хорош этот метод??? — ОН ВЕНДОРО-НЕЗАВИСИМ, идеально работает в линукс, нет шанса напортачить.
Trim
Вы всё знаете про fstrim.timer, который выполняется раз в неделю. Но не факт, что вы знаете про Swap-Trim…
Swap-Trim
Свопу в /etc/fstab нужно вписать одну из этих опций:
discard=once — Срабатывает однажды при загрузке. Нет оверхэда записи свопа. Не подходит для машин с большим ап-таймом.
discard=pages — Обрабатывает на лету. Подходит для машин с большим аптаймом, но вызывает оверхэд на свопе.
discard — (без опции) объединяет в себе эти 2 режима. Я выбрал это, потому что я шланг.
Зачем это нужно в Свопе??!! — Всё дело в том, что если нет дискарда для свопа, то мусолятся одни и те-же ячейки без ротации, пока в них не протрётся дыра. Согласитесь, если в свопе протереть дырку — стабильность системы упадёт.
Базовые Рекомендации
Держите папки Загрузки, Видео и Музыка на HDD, а на SSD делайте лишь симлинк на них. Так вы ещё немножко сэкономите ресурс вашего «SSD-Диска».
ИТОГ
Вот вы и узнали достаточно про эксплуатацию SSD в Linux. Даже при самых пессимистичных прогнозах, — диск в теории прослужит не меньше 15 лет.
Речь в данном опросе именно о том, что используется дома. Если на работе или на ноутбуке в кафе или парке вы используете другой способ, это не имеет значения.
Мультивыбор, но просьба выбирать только то, что регулярно используется, а не по особым случаям.
Ноутбучный встроенный тоже считается. То есть, если у вас ноутбук, к которому вы подключаете ещё и монитор, но встроенный дисплей тоже продолжаете использовать — это 2. Телевизор тоже считается, если подключен к компу и выводит картинку с него.
Представим гипотетическую ситуацию, что вам на д.р. (без вашего предварительного сговора и вашим нулевым финансовым участием) презентуют новый «сильный» комп в ваше единоличное употребление. Вы рады. С него символически сдёргивают праздничную занавеску и вы видите, что в компе прозрачная боковая стенка. Ваши мгновенные ощущения от наличия прозрачности?
Интересно посмотреть статистику использования по рунету.
ИИ их классифицирует так:
Для блога или простого сайта → Jekyll, Hugo, Eleventy, Hakyll
Для документации → Docusaurus, Hugo, Hakyll
Для современного сайта с интерактивом → Astro, Gatsby, Next.js
Если вы разработчик на Python → Pelican
Если важна скорость сборки → Hugo, Astro
Если хотите использовать React → Gatsby, Next.js, Astro
В нём выяснилось, что более двух третей посетителей проводят за компом больше 50% времени бодрствования.
В данном же опросе хочется узнать, как это время разделяется между разными активностями на разных девайсах, особенно учитывая, что как раз в последние 5-10 лет люди достаточно массово начинают пользоваться телефонами больше, а компьютерами меньше.
P.S. У кого всё сложно и постоянно меняется — пусть будет среднее арифметическое за последний год.
Смысл в том, что обычно первичный ключ таблицы делается в виде целого числа, которое увеличивается при вставке строки с данными на единичку. Во многих СУБД есть встроенные генераторы типа AUTOINCREMENT, SERIAL и так далее, однако это привязывает схему к конкретной СУБД плюс возможны сбои при миграциях.
Альтернатива — делать первичный ключ просто как целое число и вешать на таблицу функцию, которая увеличивает это число при вставке строки.
