https://www.opennet.ru/opennews/art.shtml?num=62378
Хотят переписать пакетный менеджер Arch Linux на Rust, за много денег.
В Arch самый всратый пакетный менеджер, который вообще себе можно представить, и зачем нужна эта "гальванизация трупа" - совсем непонятно.
Хотят переписать пакетный менеджер Arch Linux на Rust, за много денег.
В Arch самый всратый пакетный менеджер, который вообще себе можно представить, и зачем нужна эта "гальванизация трупа" - совсем непонятно.
www.opennet.ru
Фонд Sovereign инвестировал 562 тысячи евро в модернизацию управления пакетами в Arch Linux
Разработчики дистрибутива Arch Linux объявили о получении инвестиций в размере 562 тысяч евро от фонда STF (Sovereign Tech Fund), учреждённого в Германии для стимулирования развития открытой цифровой инфраструктуры и экосистем с открытым исходным кодом. Фонд…
Forwarded from Технологический Болт Генона
Всех поздравляю
Глава "Ростелекома" заявил о полном импортозамещении серверов в РФ
https://tass.ru/ekonomika/22637251
В России полностью решена проблема с импортозамещением мощных вычислительных ресурсов, заявил глава "Ростелекома" Михаил Осеевский, выступая в Совете Федерации.
"Хочу доложить, что сегодня страна чувствует себя достаточно уверенно. У нас полностью решена проблема импортозамещения мощных вычислительных ресурсов, серверов, систем хранения [данных]", - сказал топ-менеджер.
Глава "Ростелекома" заявил о полном импортозамещении серверов в РФ
https://tass.ru/ekonomika/22637251
https://www.mail-archive.com/devel-announce@lists.fedoraproject.org/msg03423.html
Видимо, у btrfs дела настолько плохи, что ей нужна отдельная Special Interest Group в составе Fedora:
"As Michel Lind mentioned back in August[1], we wanted to form a Special Interest Group to further the development and adoption of Btrfs in Fedora. As of yesterday, the SIG is now formed"
Скорее бы уже #bcachefs!
Видимо, у btrfs дела настолько плохи, что ей нужна отдельная Special Interest Group в составе Fedora:
"As Michel Lind mentioned back in August[1], we wanted to form a Special Interest Group to further the development and adoption of Btrfs in Fedora. As of yesterday, the SIG is now formed"
Скорее бы уже #bcachefs!
https://www.opennet.ru/opennews/art.shtml?num=62402
"mergiraf - AST-ориентированный инструмент для трёхстороннего слияния в Git"
Божечки, какой классный норкоманский текст:
"Ниже представлено подробное описание проблем, решаемых при помощи mergiraf:
Программное обеспечение является ярким примером чрезвычайно сложной системы. Сложные системы имеют одно общее свойство - они СЛОЖНЫ - и вы не можете ожидать, что нужное сложное поведение возникнет само собой, случайно"
Инструмент не использовал, выглядит дико.
UPD: дико потому что
"Текст написан в субъективном и неформальном стиле. Как автор текста - мне и решать. Не казённым же официозом писать?
В тексте присутствуют некоторые проблемы. В частности "направленный граф" по-русски будет ориентированным. Это потому, что я написал текст сначала на английском, потом дал задание нейросети улучшить его стиль, сохраняя контент, а потом дал ей же задание перевести на русский"
"mergiraf - AST-ориентированный инструмент для трёхстороннего слияния в Git"
Божечки, какой классный норкоманский текст:
"Ниже представлено подробное описание проблем, решаемых при помощи mergiraf:
Программное обеспечение является ярким примером чрезвычайно сложной системы. Сложные системы имеют одно общее свойство - они СЛОЖНЫ - и вы не можете ожидать, что нужное сложное поведение возникнет само собой, случайно"
Инструмент не использовал, выглядит дико.
UPD: дико потому что
"Текст написан в субъективном и неформальном стиле. Как автор текста - мне и решать. Не казённым же официозом писать?
В тексте присутствуют некоторые проблемы. В частности "направленный граф" по-русски будет ориентированным. Это потому, что я написал текст сначала на английском, потом дал задание нейросети улучшить его стиль, сохраняя контент, а потом дал ей же задание перевести на русский"
www.opennet.ru
mergiraf - AST-ориентированный инструмент для трёхстороннего слияния в Git
Опубликован релиз проекта mergiraf 0.4, развивающего драйвер для Git с реализацией возможности трёхстороннего слияния. Mergiraf поддерживает разрешение различных видов конфликтов при слиянии и может использоваться для различных языков программирования и форматов…
Будни #bootstrap
Я как-то писал про устройство хеша в своем cas - https://www.tgoop.com/itpgchannel/575
После https://www.tgoop.com/itpgchannel/2477 я решил, что хватит экономить на спичках, и взял в путь не 16 символов от хеша, а 22 (вот так вот странно, потому что у меня там base62) - https://github.com/pg83/ix/commit/d4c1c6cb2b0438d918715f73301848f6408531f1 https://github.com/pg83/ix/commit/8bb1e74c10b7185cda6d4092c0d6553d0fafc919
Решил и решил, но, после этого, у меня начала падать в CI сборка
Падать с одной и той же ошибкой - E2BIG, она же https://github.com/pg83/ix/commit/d4c1c6cb2b0438d918715f73301848f6408531f1, она же "Argument list too long".
Это довольно известная ошибка, она связана с тем, как ядро запускает новый процесс (argc, argv, env передаются через стек вызвающего процесса). Ну и если стека не хватает, то получается вот такая вот хтонь.
То есть, падать стало довольно закономерно - пути стали длиннее, и перестали помещаться в размер стека.
Я про эту проблему знал, поэтому просто увеличил
Но нифига, ошибка продолжила иметь место быть. И, что самое, СУКА, интересное, если я локально запускал в shell ту же команду, что падала в CI, то, после
Не буду утомлять вас подробностями дебага, тем, как я запускал strace в сборочных нодах, и тем, как я думал, что ошибка в
В итоге, все оказалось довольно просто - make просто брал команду, и запускал ее через /bin/sh -c "very long command".
Понимаете, да?
Я напоролся на ограничение размера одного аргумента командной строки, а не на суммарную длину всех аргументов.
Второе лечится через
Тут же стало понятно, почему локально "все работало".
Потому что интерактивный sh токенизировал эту очень длинную команду, и делал
Для
А вот
Я как-то писал про устройство хеша в своем cas - https://www.tgoop.com/itpgchannel/575
После https://www.tgoop.com/itpgchannel/2477 я решил, что хватит экономить на спичках, и взял в путь не 16 символов от хеша, а 22 (вот так вот странно, потому что у меня там base62) - https://github.com/pg83/ix/commit/d4c1c6cb2b0438d918715f73301848f6408531f1 https://github.com/pg83/ix/commit/8bb1e74c10b7185cda6d4092c0d6553d0fafc919
Решил и решил, но, после этого, у меня начала падать в CI сборка
ya
, и nix
.Падать с одной и той же ошибкой - E2BIG, она же https://github.com/pg83/ix/commit/d4c1c6cb2b0438d918715f73301848f6408531f1, она же "Argument list too long".
Это довольно известная ошибка, она связана с тем, как ядро запускает новый процесс (argc, argv, env передаются через стек вызвающего процесса). Ну и если стека не хватает, то получается вот такая вот хтонь.
То есть, падать стало довольно закономерно - пути стали длиннее, и перестали помещаться в размер стека.
Я про эту проблему знал, поэтому просто увеличил
ulimit -s
, и стал ждать того, что мой CI добежит до конца.Но нифига, ошибка продолжила иметь место быть. И, что самое, СУКА, интересное, если я локально запускал в shell ту же команду, что падала в CI, то, после
ulimit -s unlimited
, локально все работало, а в CI - нет.Не буду утомлять вас подробностями дебага, тем, как я запускал strace в сборочных нодах, и тем, как я думал, что ошибка в
gnu make
, потому что там были манипуляции с max stack size (которые я тоже очень элегантно отключил - https://github.com/pg83/ix/blob/main/pkgs/bin/make/proper/ix.sh).В итоге, все оказалось довольно просто - make просто брал команду, и запускал ее через /bin/sh -c "very long command".
Понимаете, да?
Я напоролся на ограничение размера одного аргумента командной строки, а не на суммарную длину всех аргументов.
Второе лечится через
ulimit -s
, первое - нет.Тут же стало понятно, почему локально "все работало".
Потому что интерактивный sh токенизировал эту очень длинную команду, и делал
exec('very', 'long', 'command')
, а не exec('sh', '-c', 'very long command')
!Для
ya
я это починил очень изящно - сделал так, что переменные в команде раскрывал не make, а сам shell, для этого оказалось достаточно заменить несколько переменных из $(A)
-> $${A}
. https://github.com/pg83/ix/blob/main/pkgs/bin/ya/0/preproc.py#L3-L11А вот
nix
пока так и не починил, там все очень печально.Telegram
commit -m "better"
Я, на самом-то деле, с какой-то частью этой критики согласен.
1) Совершенно не понимаю похвальбу "функциональным пакетным менеджером". Функциональный язык без side effect для построения описания сборки пакета - это не достижение, а какой-то трешак, как по…
1) Совершенно не понимаю похвальбу "функциональным пакетным менеджером". Функциональный язык без side effect для построения описания сборки пакета - это не достижение, а какой-то трешак, как по…
https://repology.org/tools/important_updates
Прилетело кучу обновлений библиотек от Xorg, вангую, что опять ведро CVE пофиксили.
Прилетело кучу обновлений библиотек от Xorg, вангую, что опять ведро CVE пофиксили.
repology.org
Important updates - Repology
Multiple package repositories analyzer
https://discourse.llvm.org/t/survey-mlir-project-charter-and-restructuring-survey/82996
Проект #LLVM решил провести опрос (тема не столь важна), и использовал для этого платформу Google Docs:
"Following up our long discussion on the MLIR project governance and charter, we decided to create a survey to understand how MLIR developers and users connect to the upstream infrastructure"
Результат убил:
"Apparently the survey is in “violation of Google’s Terms of Service”, and requesting a review brings a 404 page. Luckily, they didn’t delete the spreadsheet results, so I’ll still be able to extract information from it, just not as quick as I hoped. I also made copies, in case the sheets also get deleted.
This means the survey is now closed"
Я так понимаю, Google (контора пидорасов!) теперь будет пилить свой компилятор, ага.
Проект #LLVM решил провести опрос (тема не столь важна), и использовал для этого платформу Google Docs:
"Following up our long discussion on the MLIR project governance and charter, we decided to create a survey to understand how MLIR developers and users connect to the upstream infrastructure"
Результат убил:
"Apparently the survey is in “violation of Google’s Terms of Service”, and requesting a review brings a 404 page. Luckily, they didn’t delete the spreadsheet results, so I’ll still be able to extract information from it, just not as quick as I hoped. I also made copies, in case the sheets also get deleted.
This means the survey is now closed"
Я так понимаю, Google (контора пидорасов!) теперь будет пилить свой компилятор, ага.
LLVM Discussion Forums
[Survey] MLIR Project Charter and Restructuring Survey
Following up our long discussion on the MLIR project governance and charter, we decided to create a survey to understand how MLIR developers and users connect to the upstream infrastructure. Thanks @stellaraccident @mehdi_amini @jpienaar @ftynse for the…
Forwarded from Programmer memes
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
https://www.tgoop.com/banksta/62419
Новый способ потроллить Озон - заказать Камаз в соседний пункт выдачи, а потом отказаться, и всего за 150 рублей!
Новый способ потроллить Озон - заказать Камаз в соседний пункт выдачи, а потом отказаться, и всего за 150 рублей!
Telegram
Банкста
Грузовики «КамАЗ» начали продаваться на Ozon. Появление товара подтвердили на заводе, отметив, что «разрушают стереотип о сложной покупки грузовика». Первый грузовик, доступный для покупки на маркетплейсе – седельный тягач, стоимостьб 8,35 млн руб. Ozon начал…