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

Джарред Самнер (Jarred Sumner), создатель и основной разработчик серверной JavaScript-платформы Bun (bun.sh), создал Git-ветку, в которой приступил к переписыванию Bun с языка Zig на Rust. Переписывание ведётся с использование AI-ассистента Claude, для которого сформировано отдельное руководство по портированию. По словам Джарреда пока это лишь эксперимент, а не официальный порт, и высока вероятность, что дальше эксперимента дело не зайдёт и переписанный код не будет использован.

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

В декабре прошлого года проект Bun поглотила компания Anthropic, поэтому у Джарреда есть ресурсы для вовлечения в портирование передовых AI-моделей Claude. Платформа Bun применяется в продуктах Claude Code и Claude Agent SDK, и компания Anthropic заинтересована в повышении её качества и развитии. Bun является одним из самых успешных проектов на языке Zig, при этом у разработчиков Zig и Bun расходятся мнения в отношении применения AI в процессе разработки. В проекте Zig утверждён жёсткий запрет применения больших языковых моделей при подготовке pull-запросов, issue и комментариев (запрещён даже перевод через AI неанглоязычных комментариев).

Введение подобных ограничений объясняется разработчиками Zig негативным опытом в рецензировании созданных через AI pull-запросов, которые отнимают ресурсы и время (например, отмечаются бессмысленные изменения, AI-галлюцинации и раздутые коммиты в 10 тысяч строк). Кроме того, проект Zig позиционирует себя как ориентированный на участников, а не вносимый ими вклад в разработку - главной целью принятия pull-запросов называется не добавление нового кода, а помощь в развитии новых участников.

Автор Bun не согласен с запретом AI в Zig и полагает, что AI-слоп останется ностальгическим пережитком 2025 и 2026 годов, а разработка открытого ПО эволюционирует до запрета приёма кода от людей. Люди будут обсуждать проблемы, ставить задачи и расставлять приоритеты, а написание кода и отправка изменений в репозитории станет уделом AI. В качестве причины экспериментов с переписыванием на Rust также отмечается желание устранить проблемы в Bun, вызванные утечками памяти, и неприемлемая для крупных проектов политика Zig в отношении принятия в язык изменений, нарушающих совместимость.

Из-за запрета применения AI разработчики Bun вынуждены поддерживать собственный форк инструментария Zig, в котором благодаря применению AI удалось в 4 раза ускорить компиляцию за счёт распараллеливания семантического анализа и генерации кода. При этом судя по комментарию одного из разработчиков Zig причина отклонения патчей не в AI, а в том, что распараллеливание семантического анализа затрагивает не только компилятор, но и сам язык - чтобы реализовать предложенную функциональность без ошибок и несовместимостей, требуется внесение изменений в язык Zig. Вместо распараллеливания, разработчики Zig развивают инкрементальную компиляцию, которая по их предположению позволит на порядок повысить скорость компиляции.

JavaScript-платформа Bun развивается как высокопроизводительный аналог платформ Node.js и Deno. Проект разрабатывается с оглядкой на обеспечение совместимости с серверными приложениями для Node.js и поддерживает большую часть API Node.js. В состав платформы входит набор инструментов для создания и выполнения приложений на языках JavaScript и TypeScript, а также runtime для выполнения JavaScript-приложений без браузера, пакетный менеджер (совместимый с NPM), инструментарий для выполнения тестов, система сборки самодостаточных пакетов и прослойка для встраивания обработчиков, написанных на языке Си. По производительности Bun заметно обгоняет Deno и Node.js (в тестах на базе фреймворка React платформа Bun в 2 раза опережает Deno и почти в 5 раз Node.js). Для выполнения JavaScript задействован JavaScript-движок JavaScriptCore и компоненты проекта WebKit с дополнительными патчами.

https://notepad-plus-plus.org/news/npp-trademark-infringement:

2026-05-01
В последнее время несколько пользователей сообщили о сайте, который якобы предлагает официальную версию Notepad++ для macOS: notepad-plus-plus-mac.org.

Скажу прямо: Этот сайт не имеет абсолютно никакого отношения к Notepad++. Он не является авторизованным, не поддерживается и никоим образом не связан с проектом.

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

Это вводит в заблуждение, является неуместным и, честно говоря, неуважительным как по отношению к проекту, так и к его пользователям. Это уже ввело в заблуждение многих людей – в том числе и технические СМИ – заставив их поверить, что речь идёт об официальном выпуске.

Чтобы было абсолютно ясно: Notepad++ никогда не выпускал версию для macOS. Любой, кто утверждает обратное, просто пользуется известностью Notepad++.

Как я уже упоминал в своём посте на GitHub, я уже связался с владельцем поддельного «официального» сайта и до сих пор жду ответа.

А пока, если вы увидите, что кто-то публикует сообщение «Notepad++ наконец-то появился на Mac!» на Reddit, Twitter, Mastodon, Discord, StackOverflow или в каких-либо технических блогах/форумах, пожалуйста, ответьте следующим образом: «Это не официальный выпуск Notepad++. Это неавторизованный проект, незаконно использующий товарный знак Notepad++», и добавьте ссылку на это объявление.

Спасибо пользователям, которые сообщили об этом. Ваша бдительность помогает защитить проект от тех, кто считает, что может произвольно использовать бренд Notepad++.

Don Ho

https://github.com/goossens/ObjectTalk:

Welcome to ObjectTalk, a object-oriented Swiss Army Knife providing a Scripting Language, 2D/3D Graphics Engine, Node Based Programming, Audio Engine, an Entity Component System and an Integrated Development Environment to learn and have some fun.

Late 2020, I retired after a 40+ year career in the software and system development business. Starting as a programmer/analyst and later moving up the ladder to management, international standardization and geopolitics, I was exposed to lots of technologies including operating systems design, computer language development, military command and control systems, web application design, data science and what we now call artificial intelligence. You can read my full bio on my website.

After retirement, I dusted off some old projects to improve mental health (applying the «use it or loss it» principle like we do for physical health) and that’s how this repository came about. I started by revisiting a scripting language I wrote decades ago, modernizing it and learning things along the way. Once the language was stable, it needed a few use cases and I dusted off some 2D/3D graphic projects that I had laying around. This then led to including a graphics engine, an Entity Component System (ECS), Node Based programming and a custom Integrated Development Environment (IDE). The latest addition is an audio engine that will help with my musical interests as it provides Digital Signal Processing (DSP) based circuits that can be quickly connected together to create «musical» instruments or create sounds.

So today, this project contains a lot of code, compiles into a single executable with no runtime dependencies and is functional on MacOS, Linux and Windows. It basically is a playground to learn and have fun. Think of it as a educational jack of all trades, master of none.

…

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

Компания Microsoft опубликовала под лицензией MIT исходный код операционных систем 86-DOS 1.00 и PC-DOS 1.00, а также runtime-библиотеки компилятора Microsoft BASIC-86, ассемблер SCP, утилиты CHKDSK и EDLIN. PC-DOS 1.00 примечателен тем, что был первым выпуском DOS для компьютеров IBM PC. Код был восстановлен в рамках проекта по реконструкции кода первых версий DOS для CPU 8086, путём сканирования и транскрибирования архивных бумажных распечаток, созданных в 1981 и 1982 годах.

https://github.com/llvm/llvm-project/pull/191363:

These should use O2 with the optsize or minsize attributes instead.

This enforces that there is no divergence between pipeline-level Os/Oz and function-level Os/Oz at an architectural level.

For the purpose of testing IR that does not have optsize/minsize itself, it’s possible to use -force-attribute=optsize etc.

И $ clang-23 --help | ugrep -i ofast:

1675: -Ofast Deprecated; use ‘-O3 -ffast-math’ for the same behavior, or ‘-O3’ to enable only conforming optimizations

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

Джон Сигер (Jon Seager), вице-президент компании Canonical по инжинирингу и технический лидер проекта Ubuntu, обобщил планы по интеграции в дистрибутив функциональности на основе больших языковых моделей. На первом этапе разработчики Ubuntu намерены задействовать AI-модели для улучшения существующей функциональности дистрибутива, после чего добавить в дистрибутив отдельные AI-возможности и рабочие процессы для пользователей, заинтересованных в использовании AI. AI-возможности будут интегрироваться в дистрибутив постепенно в течение 2027 года, без принуждения и по мере доведения их до готовности.

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

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

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

Для обеспечения безопасности и упрощения установки AI-модели решено поставлять вместе с инструментарием для их выполнения в форме snap-пакетов, оптимизированных для различных аппаратных платформ. Модели будут выполняться в изолированном окружении, не имеющем прямого доступа к остальной системе, а AI-агенты будут функционировать в соответствии с существующими механизмами разграничения доступа и аудита.

Внутри компании Canonical решено не отталкиваться изначально от определённого AI-стека, а в течение следующих 6 месяцев предоставить командам возможность углубиться в тему, попробовать разные AI-стеки, выбрать оптимальные для их задач AI-решения, понять сильные стороны AI-инструментов и их ограничения. Сотрудники компании по-прежнему будут оцениваться по тому, как хорошо они выполняют свои задачи, а не по тому, используют ли они AI.

https://www.comss.ru/page.php?id=19901:

Разработка Manjaro парализована из-за конфликта с руководством. Мейнтейнеры опубликовали манифест о переходе на новую модель управления и приостановили поддержку дистрибутива.

Мейнтейнеры Manjaro инициировали масштабную реструктуризацию проекта с целью отделения от коммерческой структуры и создания независимого некоммерческого общества Manjaro Project e.V. За последнее десятилетие операционная система столкнулась с системным упадком, потерей контрибьюторов и финансовым кризисом. В настоящий момент объявлена забастовка, а часть процессов по поддержке дистрибутива полностью парализована.

Предпосылки к реорганизации
Несмотря на сохранение крупной пользовательской базы, разработка Manjaro стагнирует. Технические инциденты, включая несвоевременное продление TLS-сертификатов, остаются без внимания руководства, даже при наличии готовых инструментов автоматизации от энтузиастов.

Приоритеты текущего лидера радикально расходятся с интересами сообщества. Управление процессами осуществляется единолично, доступ к ключевой инфраструктуре закрыт для остальных специалистов, а попытки монетизации потерпели неудачу. Бренд эксплуатируется исключительно ради популярности, пользователи выполняют роль бесплатных тестировщиков, а средства команды Manjaro GmbH & Co KG не инвестируются в развитие. Бюджет полностью исчерпан, из-за чего единственный профильный разработчик, трудившийся на полную ставку, лишился источника дохода.

Новая модель управления
Для восстановления доверия и привлечения новых кадров проект выделяется в зарегистрированное некоммерческое общество (e.V.). Руководить организацией будут действующие участники, выразившие интерес к инициативе, с равными долями владения.

Прием новых лиц осуществляется по результатам голосования при наличии двух рекомендаций от действующего состава. Для узкопрофильных специалистов без истории участия в дистрибутиве требование снижается до одной рекомендации, а кандидатура оценивается исключительно по профессиональным навыкам. Любой участник может покинуть структуру по своему желанию. Принудительное исключение применяется только после 12 месяцев полного отсутствия связи. Допускается временная приостановка активности с заморозкой права голоса, что увеличивает допустимый период отсутствия до 36 месяцев.

Традиционная иерархия уступает место плоской структуре. Обязанности распределяются добровольно, однако финансовые операции требуют строгого одобрения казначея, а официальное представительство - согласования с комьюнити-менеджером. Решения принимаются общим голосованием продолжительностью от двух до четырех недель. Базовые вопросы утверждаются простым большинством, тогда как критические изменения требуют поддержки свыше 70% состава (минимум 5 из 7 человек).

Инфраструктура и активы
Коммерческая структура поэтапно перейдет в статус потребителя (downstream) решений некоммерческой организации. Бизнесу предоставляется исчерпывающая лицензия на торговую марку до конца 2029 года для выпуска неконфликтующих продуктов, после чего бренд будет выкуплен обществом за один евро.

Вся ключевая инфраструктура переходит под контроль некоммерческой организации. В перечень активов входят:

• Организации на GitHub (Manjaro Linux, Manjaro-Kernels, Manjaro-ARM).
• Собственный сервер GitLab и профильные Git-репозитории.
• Домен manjaro.org и официальный форум.
• Облачные ресурсы, включая хостинг Hetzner.
• Сеть доставки контента (CDN).
• Финансовые площадки уровня OpenCollective. Бизнес-подразделение сохранит доступ к мощностям при условии полной компенсации затрат на облако, пропускную способность и администрирование систем. Одновременно запускается процесс миграции коммерческих сервисов на независимые серверы.

Текущий статус и забастовка
При отсутствии компромиссных решений вступает в силу жесткий план действий. Нулевая стадия предусматривала ожидание ответа. На первой стадии публикуется манифест и начинается забастовка с остановкой второстепенных задач. Вторая стадия допускает форк дистрибутива или массовый уход мейнтейнеров.

Владелец бизнеса дважды проигнорировал запросы и увеличенные сроки на предоставление ответа. В результате активирована первая стадия, разделенная на три этапа. Сейчас идет начальный этап - публикация документа во внутренних каналах. Если игнорирование продлится еще 48 часов, запустится второй этап с переносом темы в раздел для участников. Спустя дополнительные 48 часов наступит третий этап: публикация в публичных анонсах и полная блокировка форума в режим чтения.

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

Чтобы внести предельную ясность: цель состоит НЕ в том, чтобы кого-то отстранить, мы лишь надеемся на смену руководства и возвращение к формату здорового проекта сообщества. Разработка умирает, для спасения требуются радикальные перемены. Написанное выше не высечено в камне, если есть отзывы - делитесь. @philm получил копию этого документа 2 недели назад и до сих пор не ответил. Поэтому сейчас мы публикуем его во внутренних каналах.

Тот редкий случай, когда обновление Devuan/Ceres сильно удивило. :)

https://gcc.gnu.org/gcc-16/changes.html#cxx:

• Several C++26 features have been implemented:
  • P2996R13, Reflection (PR120775, enabled by -std=c++26 -freflection)
  • P3394R4, Annotations for Reflection
  • P3293R3, Splicing a base class subobject
  • P3096R12, Function Parameter Reflection
  • P3491R3, define_static_{string,object,array} (PR120783)
  • P3560R2, Error Handling in Reflection
  • P1306R5, Expansion statements (PR120776)
  • P2795R5, Erroneous behavior for uninitialized reads (PR114457)
  • P1061R10, Structured bindings can introduce a pack (PR117783)
  • P3068R5, constexpr exceptions (PR117785)
  • P3533R2, constexpr virtual inheritance (PR120777)
  • P1494R5, Partial program correctness (PR119060)
  • P3618R0, Allow attaching main to the global module (PR120773)
  • P2843R3, Preprocessing is never undefined (PR120778)
  • P2686R4, constexpr structured bindings and references to constexpr variables (PR117784, only partially, structured bindings can be constexpr but references to constexpr automatic variables still not allowed)
• Several C++23 features have been implemented:
  • P2036R3, Change scope of lambda trailing-return-type (PR102610)
  • P2590R2, Explicit lifetime management (PR106658)
  • P2246R1, Character encoding of diagnostic text (PR102613)

clang 23.0 пока отстаёт. :)

Salvatore Sanfilippo тоже увлёкся нейросетями.

https://github.com/antirez/iris.c:

Iris is an inference pipeline that generates images from text prompts using open weights diffusion transformer models. It is implemented entirely in C, with zero external dependencies beyond the C standard library. MPS and BLAS acceleration are optional but recommended. Under macOS, a BLAS API is part of the system, so nothing is required.

The name comes from the Greek goddess Iris, messenger of the gods and personification of the rainbow.

Supported model families:

• FLUX.2 Klein (by Black Forest Labs):
  • 4B distilled (4 steps, auto guidance set to 1, very fast).
  • 4B base (50 steps for max quality, or less. Classifier-Free Diffusion Guidance, much slower but more generation variety).
  • 9B distilled (4 steps, larger model, higher quality. Non-commercial license).
  • 9B base (50 steps, CFG, highest quality. Non-commercial license).
• Z-Image-Turbo (by Tongyi-MAI):
  • 6B (8 NFE / 9 scheduler steps, no CFG, fast).

https://github.com/antirez/qwen-asr:

This is a C implementation of the inference pipeline for Qwen3-ASR speech-to-text models (both 0.6B and 1.7B). It has zero external dependencies beyond the C standard library and a BLAS implementation (Accelerate on macOS, OpenBLAS on Linux). Tokens stream to stdout as they are generated. The implementation runs at speed multiple of the file length even in very modest hardware, like low end Intel or AMD processor.

Important: this implementation explicitly avoids implementing support for MPS. Transcription systems are very important pieces of infrastructure, and are often run on remote Linux servers. Adding the MPS target would focus the efforts too much on Apple hardware, so for now I’m skipping it. The code runs very well anyway on Apple hardware (NEON optimized). Please, don’t send pull requests about this feature, fork the code instead, in order to add MPS support. I’ll add it much later when the other optimizations are already mature.

Supported modes and models

Both normal (offline) and streaming (online) modes are supported. Normal mode defaults to full offline decode (-S 0), so the whole audio is encoded at once. Streaming mode processes audio in 2-second chunks with prefix rollback (it keeps the last few decoded tokens as context for the decoder/LLM when transcribing the next chunk).

Important practical note: in this implementation, interactive --stream prioritizes incremental token stability over throughput and can be much slower than normal mode when you process an already-recorded file end-to-end.

Audio can be piped from stdin (--stdin), making it easy to transcode and transcribe any format via ffmpeg. Language is usually auto-detected from audio, and can be forced with --language. A system prompt can bias the model toward specific terms or spellings.

Both the 0.6B and 1.7B parameters models are supported. While the 1.7B model is generally more powerful, the 0.6B model seems the sweet spot for CPU inference, however the speed difference is not huge, so you may want to try both and decide what to use depending on your use case.

https://github.com/antirez/voxtral.c:

This is a C implementation of the inference pipeline for the Mistral AI’s Voxtral Realtime 4B model. It has zero external dependencies beyond the C standard library. The MPS inference is decently fast, while the BLAS acceleration is usable but slow (it continuously convert the bf16 weights to fp32).

Audio processing uses a chunked encoder with overlapping windows, bounding memory usage regardless of input length. Audio can also be piped from stdin (--stdin), or captured live from the microphone (--from-mic, macOS), making it easy to transcode and transcribe any format via ffmpeg. A streaming C API (vox_stream_t) lets you feed audio incrementally and receive token strings as they become available.

More testing needed: please note that this project was mostly tested against few samples, and likely requires some more work to be production quality. However the hard part, to understand the model inference and reproduce the inference pipeline, is here, so the rest likely can be done easily. Testing it against very long transcriptions, able to stress the KV cache circular buffer, will be a useful task.

Motivations (and some rant)

Thank you to Mistral for releasing such a great model in an Open Weights fashion. However, the author of this project believes that limiting the inference to a partnership with vLLM, without providing a self-contained reference implementation in Python, limits the model’s actual reach and the potential good effects it could have. For this reason, this project was created: it provides both a pure C inference engine and a simple, self-contained Python reference implementation (python_simple_implementation.py) that anyone can read and understand without digging through the vLLM codebase.

https://github.com/antirez/gguf-tools:

This is a work in progress library to manipulate GGUF files. While the library aims to be useful, one of the main goals is to provide an accessible code base that as a side effect documents the GGUF files used by the awesome llama.cpp project: GGUF files are becoming increasingly more used and central in the local machine learning scene, so to have multiple implementations of parsers and files generators may be useful.

The program gguf-tools uses the library to implement both useful and useless stuff, to show the library usage in the real world. For now the utility implements the following subcommands:

gguf-tools show file.gguf

shows detailed info about the GGUF file. This will include all the key-value pairs, including arrays, and detailed tensors informations. Tensor offsets will be relative to the start of the file (so they are actually absolute offsets), not the start of the data section like in the GGUF format.

gguf-tools compare file1.gguf file2.gguf

This tool is useful to understand if two LLMs (or other models distributed as GGUF files) are related, for instance if one is the finetune of another, or if both are fine-tuned from the same parent model.

For each matching tensor (same name and parameters count), the command computes the average weights difference (in percentage, so that a random distribution in the interval -N, +N would be on average 100% different than another random distribution in the same interval). This is useful to see if a model is a finetune of another model, how much it was finetuned, which layers were frozen while finetuning and so forth. Note that because of quantization, even tensors that are functionally equivalent may have some small average difference.

gguf-tools inspect-tensor file.gguf tensor.name [count]

Show all (if count is not specified, otherwise only the first count) weights values of the specified tensor. This is useful for low level stuff, like checking if quantization is working as expected, see the introduced error, model fingerprinting and so forth.

gguf-tools split-mixtral 65230776370407150546470161412165 mixtral.gguf out.gguf

Extracts a 7B model out.gguf from Mixtral 7B MoE using the specified MoE ID for each layer (there are 32 digits in the sequence 652…).

Note that split-mixtral is quite useless as models obtained in this way will not perform any useful work. This is just an experiment and a non trivial task to show how to use the library. Likely it will be removed soon, once I have more interesting and useful examples to show, like models merging.

Python 0.9.1 part 01/21:

Guido van Rossum guido at cwi.nl
Wed Feb 20 04:35:26 AEST 1991
Previous message (by thread): unbatcher out of sync?
Next message (by thread): Python 0.9.1 part 03/21
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

: This is a shell archive.
: Extract with 'sh this_file'.
: Extract this part first since it makes all directories
echo 'Start of pack.out, part 01 out of 21:'
echo -n 'Making directories ... '
err="no"
test -d 'demo' || mkdir 'demo' || err="yes"
test -d 'demo/scripts' || mkdir 'demo/scripts' || err="yes"
test -d 'demo/sgi' || mkdir 'demo/sgi' || err="yes"
test -d 'demo/sgi/audio' || mkdir 'demo/sgi/audio' || err="yes"
test -d 'demo/sgi/audio_stdwin' || mkdir 'demo/sgi/audio_stdwin' || err="yes"
test -d 'demo/sgi/gl' || mkdir 'demo/sgi/gl' || err="yes"
test -d 'demo/sgi/gl_panel' || mkdir 'demo/sgi/gl_panel' || err="yes"
test -d 'demo/sgi/gl_panel/apanel' || mkdir 'demo/sgi/gl_panel/apanel' || err="yes"
test -d 'demo/sgi/gl_panel/flying' || mkdir 'demo/sgi/gl_panel/flying' || err="yes"
test -d 'demo/sgi/gl_panel/nurbs' || mkdir 'demo/sgi/gl_panel/nurbs' || err="yes"
test -d 'demo/sgi/gl_panel/twoview' || mkdir 'demo/sgi/gl_panel/twoview' || err="yes"
test -d 'demo/stdwin' || mkdir 'demo/stdwin' || err="yes"
test -d 'doc' || mkdir 'doc' || err="yes"
test -d 'lib' || mkdir 'lib' || err="yes"
test -d 'src' || mkdir 'src' || err="yes"
echo 'done'
if test "$err" = "yes"
then echo "didn't make it."
fi
if test -s 'README'
then echo '*** I will not over-write existing file README'
else
echo 'x - README'
sed 's/^X//' > 'README' << 'EOF'
This is Python, an extensible interpreted programming language that
combines remarkable power with very clear syntax.

This is version 0.9 (the first beta release), patchlevel 1.

Python can be used instead of shell, Awk or Perl scripts, to write
prototypes of real applications, or as an extension language of large
systems, you name it.  There are built-in modules that interface to
the operating system and to various window systems: X11, the Mac
window system (you need STDWIN for these two), and Silicon Graphics'
GL library.  It runs on most modern versions of UNIX, on the Mac, and
I wouldn't be surprised if it ran on MS-DOS unchanged.  I developed it
mostly on an SGI IRIS workstation (using IRIX 3.1 and 3.2) and on the
Mac, but have tested it also on SunOS (4.1) and BSD 4.3 (tahoe).

Building and installing Python is easy (but do read the Makefile).
A UNIX style manual page and extensive documentation (in LaTeX format)
are provided.  (In the beta release, the documentation is still under
development.)

Please try it out and send me your comments (on anything -- the
language design, implementation, portability, installation,
documentation) and the modules you wrote for it, to make the first
real release better.  If you needed to hack the source to get it to
compile and run on a particular machine, send me the fixes -- I'll try
to incorporate them into the next patch.  If you can't get it to work
at all, send me a *detailed* description of the problem and I may look
into it.

If you want to profit of the X11 or Mac window interface, you'll need
STDWIN.  This is a portable window system interface by the same
author.  The versions of STDWIN floating around on some archives are
not sufficiently up-to-date for use with Python.  I will distribute
the latest and greatest STDWIN version at about the same time as Python.

I am the author of Python:

	Guido van Rossum
	CWI, dept. CST
	Kruislaan 413
	1098 SJ  Amsterdam
	The Netherlands

	E-mail: guido at cwi.nl

The Python source is copyrighted, but you can freely use and copy it
as long as you don't change or remove the copyright:

/***********************************************************
Copyright 1991 by Stichting Mathematisch Centrum, Amsterdam, The
Netherlands.

# Fancy NURBS demo.  Require Z buffer and Panel Library.

from gl import *
from GL import *
from DEVICE import *
from nurbsdata import *
import panel

#
# flags = trim_f, invis_f, cpvis_f, tpvis_f, axvis_f, freeze_f
#
TRIM	= 0
VIS	= 1
CPVIS	= 2
TPVIS	= 3
AXVIS	= 4
FREEZE	= 5
flags = [0, 1, 0, 0, 0, 0]

def draw_axis () :
	cpack (0x0)
	zero = (0.0, 0.0, 0.0)
	#
	one = (1.0, 0.0, 0.0)
	smallline (zero, one)
	cmov (1.0, 0.0, 0.0)
	charstr ('x')
	#
	one = (0.0, 1.0, 0.0)
	smallline (zero, one)
	cmov (0.0, 1.0, 0.0)
	charstr ('y')
	#
	one = (0.0, 0.0, 1.0)
	smallline (zero, one)
	cmov (0.0, 0.0, 1.0)
	charstr ('z')

DELTA = 0.1

def cross (p) :
	p0 = [p[0], p[1], p[2]]
	p1 = [p[0], p[1], p[2]]
	for i in range (0, 3) :
		p0[i] = p0[i] + DELTA
		p1[i] = p1[i] - DELTA
		smallline (p0, p1)
		p0[i] = p0[i] - DELTA
		p1[i] = p1[i] + DELTA

def smallline (p0, p1) :
	bgnline ()
	v3f (p0)
	v3f (p1)
	endline ()

def draw_pts (pnts, color) :
	linewidth (2)
	cpack (color)
	for i in pnts :
		cross (i)

def init_windows():
	foreground()
	wid = winopen('nurbs')
	wintitle('NURBS Surface')
	doublebuffer()
	RGBmode()
	gconfig()
	lsetdepth(0x000, 0x7fffff)
	zbuffer( TRUE )

def init_view():
	mmode(MPROJECTION)
	ortho( -5., 5., -5., 5., -5., 5. )
	#
	mmode(MVIEWING)
	loadmatrix(idmat)
	#
	lmbind(MATERIAL, 1)

def set_scene(flags):
	#
	lmbind(MATERIAL, 0)
	RGBcolor(150,150,150)
	lmbind(MATERIAL, 1)
	clear()
	zclear()
	#
	if not flags[FREEZE] :
		rotate( 100, 'y' )
		rotate( 100, 'z' )

def draw_trim_surface(flags):
	pnts = ctlpoints
	if flags[VIS] :
		bgnsurface()
		nurbssurface(surfknots,surfknots,pnts,ORDER,ORDER,N_XYZ)
		if flags[TRIM]:
			bgntrim()
			nurbscurve(trimknots,trimpoints,ORDER-1,N_STW)
			endtrim()
		endsurface()
	#
	if flags[CPVIS] :
		for i in pnts :
			draw_pts (i, RED)
	#
	if flags[TPVIS] :
		tpts = trimpoints
		draw_pts (tpts, YELLOW)
	#
	if flags[AXVIS] :
		draw_axis ()
	#
	swapbuffers()

def make_lights():
	lmdef(DEFLMODEL,1,[])
	lmdef(DEFLIGHT,1,[])
	#
	# define material #1
	#
	a = []
	a = a + [EMISSION, 0.0, 0.0, 0.0]
	a = a + [AMBIENT,  0.1, 0.1, 0.1]
	a = a + [DIFFUSE,  0.6, 0.3, 0.3]
	a = a + [SPECULAR,  0.0, 0.6, 0.0]
	a = a + [SHININESS, 2.0]
	a = a + [LMNULL]
	lmdef(DEFMATERIAL, 1, a)
	#
	# turn on lighting
	#
	lmbind(LIGHT0, 1)
	lmbind(LMODEL, 1)

def main():
	init_windows()
	make_lights()
	init_view()
	#
	panel.needredraw()
	panels = panel.defpanellist('nurbs.s')
	p = panels[0]
	#
	def cbtrim (a) :
		flags[TRIM:TRIM+1] = [int (a.val)]
	p.trim.upfunc = cbtrim
	#
	def cbquit (a) :
		import sys
		sys.exit (1)
	p.quit.upfunc = cbquit
	#
	def cbmotion (a) :
		flags[FREEZE:FREEZE+1] = [int (a.val)]
	p.motion.upfunc = cbmotion
	#
	def cbxyzaxis (a) :
		flags[AXVIS:AXVIS+1] = [int (a.val)]
	p.xyzaxis.upfunc = cbxyzaxis
	#
	def cbtrimpnts (a) :
		flags[TPVIS:TPVIS+1] = [int (a.val)]
	p.trimpnts.upfunc = cbtrimpnts
	#
	def cbcntlpnts (a) :
		flags[CPVIS:CPVIS+1] = [int (a.val)]
	p.cntlpnts.upfunc = cbcntlpnts
	#
	def cbnurb (a) :
		flags[VIS:VIS+1] = [int (a.val)]
	p.nurb.upfunc = cbnurb
	#
	set_scene(flags)
	setnurbsproperty( N_ERRORCHECKING, 1.0 )
	setnurbsproperty( N_PIXEL_TOLERANCE, 50.0 )
	draw_trim_surface(flags)
	#
	while 1:
		act = panel.dopanel()
		#
		wid =  panel.userredraw ()
		if wid :
			winset (wid)
			reshapeviewport()
			set_scene(flags)
			draw_trim_surface(flags)
		#
		set_scene(flags)
		draw_trim_surface(flags)

main()

https://www.zenc-lang.org
https://github.com/z-libs/Zen-C
https://github.com/z-libs/Zen-C/blob/main/translations/README_RU.md:

Современная эргономика. Никаких накладных расходов. Чистый Си.
Пишите как на высокоуровневом языке, запускайте как Си.
Zen C — это современный язык системного программирования, который компилируется в человекочитаемом GNU C/C11. Он предоставляет богатый набор возможностей, включая вывод типов, сопоставление с паттернами, генерику, трейты, async/await и ручное управление памятью с возможностями RAII, при этом поддерживая 100% совместимость с ABI Си.

Портативная сборка (APE)
Zen C можно скомпилировать как Actually Portable Executable (APE) с помощью Cosmopolitan Libc. Это создаёт один исполняемый файл (.com), работающий нативно на Linux, macOS, Windows, FreeBSD, OpenBSD и NetBSD на архитектурах x86_64 и aarch64.

https://github.com/z-libs/Zen-C/blob/main/examples/features/comptime_fib.zc:

fn main() {
    comptime {
        let N = 20;
        let fib: long[20];
        fib[0] = (long)0;
        fib[1] = (long)1;
        for let i=2; i<N; i+=1 {
            fib[i] = fib[i-1] + fib[i-2];
        }

        printf("// Generated Fibonacci Sequence\n");
        printf("let fibs: int[%d] = [", N);
        for let i=0; i<N; i+=1 {
            printf("%ld", fib[i]);
            if (i < N-1) printf(", ");
        }
        printf("];\n");
    }

    print "Compile-time generated Fibonacci sequence:\n";
    for i in 0..20 {
        print f"fib[{i}] = {fibs[i]}\n";
    }
}

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

Кристиан Хергерт (Christian Hergert), автор интегрированной среды разработки GNOME Builder, эмулятора терминала Ptyxis и текстового редактора GNOME Text Editor, объявил, что в связи с переездом из США во Францию и изменением приоритетов в жизни, больше не сможет уделять должное внимание разработке GNOME. Кристиан являлся почти единственным активеным сопровождающим 16 модулей GNOME и более сорока часов в неделю уделял поддержке и развитию стека GNOME. Отмечается, что после переезда его возможности по участию в разработке будут сильно ограничены и основное время он будет уделять семье, новой деятельности и налаживанию быта на новом месте.

В качестве причины переезда упоминается новая эммиграционная политика США (у Криса жена родом из Тибета). Крис был трудоустроен в Red Hat, но данная компания отклонила его просьбу сохранить должность после переезда во Францию, несмотря на предоставление доказательства наличия рисков для его семьи.

Cписок модулей, сопровождением и разработкой которых занимался Крис:

• GtkSourceView - библиотека для встраивания в приложения виджета многострочного редактирования текста, применяется во многих редакторах на базе GTK.
• Text Editor - основной текстовый редактор GNOME.
• Ptyxis - эмулятор терминала, по умолчанию используется в Fedora, Debian, Ubuntu, RHEL/CentOS/Alma/Rocky.
• libspelling - библиотека для использования в GTK-приложениях проверки правописания на базе пакета enchant2.
• Sysprof - система профилирования, интегрируемая с Linux perf, Mesa, GTK, Pango, GLib, WebKit, Mutter.
• Builder - интегрированная среда разработки.
• template-glib - шаблонизатор для GObject.
• jsonrpc-glib - библиотека для взаимодействия через JSON-RPC.
• libpeas - движок для создания плагинов на C, C++, Rust, Lua, Python и JavaScript.
• libdex - библиотека для отложенного выполнения задач и интеграции с io_uring.
• GOM (gnome.org) - маппинг объектов GObject в SQLite.
• Manuals - просмотрщик документации.
• Foundry - реализация функциональности GNOME Builder для использования из командной строки и в форме библиотеки.
• d-spy - утилита для анализа соединений D-Bus.
• libpanel - виджеты для создания сложных IDE-подобных приложений на базе GTK и libadwaita.
• libmks - GTK-компоненты для отображения экрана и передачи событий мыши/клавиатуры при взаимодействии с виртуальными машинами на базе QEMU.

Прилетело обновление в Devuan/Ceres (ну и в Debian/sid, конечно), ну и вот.

https://codeberg.org/sox_ng:

The SoX_ng project aims to sanitize the Swiss Army Knife of sound processing utilities by unifying commits in the fifty-odd development forks and patches in the fifty-odd distros that package SoX and by making regular time-based releases every six months.

https://codeberg.org/sox_ng/sox_ng:

The SoX_ng project imports, compares and refines bug fixes and new work from the 50-odd software distributions that package SoX and from the plethora of forks on github and elsewhere and makes regular releases with a six-monthly cadence for each of the micro (bug fixes) and minor (new features) releases. A major release (non-backwards-compatible changes) is not planned.

The next micro release is scheduled for the 18th February 2026.
The next minor release is scheduled for the 18th May 2026.

Такие дела.

https://ru.wikipedia.org/wiki/Википедия:25_лет:

15 января 2026 года Википедия отметит 25-летие со дня своего основания в 2001 году. Серебряный юбилей Википедии отмечается во всём мире в течение года.

Девиз: прославление знаний, гуманизма и сотрудничества в лучшем их проявлении.

Википедия начиналась с амбициозной идеи создания свободной энциклопедии, написанной волонтёрами для людей во всём мире. Это казалось невозможным, но за два с половиной десятилетия Википедия стала самым популярным хранилищем знаний. Как это произошло? (1 мин. 30 сек.)

https://ru.wikipedia.org/wiki/Википедия:Обзор:

25 лет назад Википедия была мечтой, амбициозной и, как казалось, несбыточной. Перенесёмся в наше время — и увидим миллиарды читателей, сотни тысяч редакторов: простых любителей, писателей, учителей, специалистов разных направлений и учёных. Википедия стала мировым источником информации № 1. Если вы ищете какую-то информацию, то скорее всего найдёте её здесь. Википедия может поделиться с вами знаниями из самых разных областей, от истории маленьких деревень и биографий отдельных людей до шоу-бизнеса, мировой политики и передовых научных достижений. Искусственный интеллект обучается на основе Википедии. Поисковые системы приводят её в первых строках. Ваш умный помощник говорит: «Вот что я нашёл в Википедии…». В мире, где платные подписки и реклама кажутся нормой, Википедия по-прежнему бесплатна, нейтральна, открыта и человечна. Это тот интернет, который нам обещали: 25 лет знаний, сотрудничества, консенсуса и гуманизма в лучшем его проявлении. За всем этим стоят простые волонтёры, редактирующие статьи, спорящие и приходящие к согласию. Вы можете принять участие в редактировании в любое время. Сохранение и развитие знаний зависит от каждого из нас.

24 года достижений

Идея объединить мировые знания в одном месте восходит к античным библиотекам и древним всеобщим энциклопедиям, таким как «Естественная история» Плиния Старшего. Концепция универсальной, широко распространённой печатной энциклопедии берёт своё начало с Дени Дидро и французских энциклопедистов XVIII века. Концепция всемирной машинной энциклопедии получила развитие в сборнике эссе фантаста Герберта Уэллса «Мировой мозг» (1938) и других сочинениях. В начале XXI века эта фантастическая идея стала реальностью.

Википедия выросла из Nupedia, более профессиональной бесплатной онлайн-энциклопедии. В 2001 году Джимми Уэйлс и Ларри Сангер запустили Wikipedia в качестве дополнительного проекта, используя движок вики (откуда и название Википедии) как инструмент для совместного составления документов. Хотя изначально Википедия задумывалась как место для черновиков статей, которые впоследствии предполагалось доработать в Nupedia, она быстро превзошла свою предшественницу, став глобальным проектом и вдохновив широкий спектр других справочных онлайн-проектов.

Первые месяцы Википедия писалась только на английском языке. Первым неанглийским языковым разделом стал немецкий, созданный 16 марта 2001 года. Раздел на русском языке основан 11 мая 2001 года.

На начало 2026 года Википедия содержит более 66 миллионов статей на более чем 340 языках мира. Википедия является седьмым или девятым по посещаемости веб-сайтом в мире (согласно различным источникам данных об интернет-трафике) и единственным некоммерческим сайтом с такой высокой посещаемостью. В Википедии пишут, редактируют и проверяют факты почти 250 000 человек со всего мира. Википедия стала самым крупным и наиболее читаемым справочником, а также самой полной энциклопедией из когда-либо создававшихся за всю историю человечества.

Русскоязычный раздел к настоящему времени входит в десятку крупнейших языковых разделов Википедии по всем основным показателям и включает 2 080 229 статей.

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

Как она работает?

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

Работоспособность серверов Википедии обеспечивает американская некоммерческая организация «Фонд Викимедиа», которая, однако, не определяет конкретную политику языковых разделов Википедии и содержание статей. О Википедии существует много стереотипов. Википедия не управляется американским или любым другим правительством. Википедия не имеет редакционного совета или главного редактора. В Википедии нет «модераторов» и «сотрудников на зарплате», которые могут отредактировать статьи в «нужную» сторону. В Википедии нет рекламы и подписок. Большая часть финансирования «Фонда Викимедиа» — частные пожертвования. Википедия пишется, редактируется, поддерживается и управляется на добровольной основе участниками со всего мира, не получающими за это оплаты.

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

Создание и редактирование Википедии — непрерывный процесс, которому в ближайшей перспективе не может быть конца. Если вы напишете что-то полезное для энциклопедии, ваш вклад может существовать годами и быть прочитанным по всему миру. Ваш текст может быть улучшен и обновлён другими редакторами.

https://pikabu.ru/story/sekret_kokakolyi__bolshe_ne_sekret_beri_i_delay_13591787:

Ютубер Зак Армстронг с канала LabCoatz потратил почти год на изучение и воспроизведение секретной формулы Coca-Cola — одного из самых тщательно охраняемых коммерческих секретов в мире. Как он отмечает в начале видео, компания принимает экстремальные меры защиты: демонстрирует гигантское стальное хранилище на экскурсиях, а ингредиенты доставляются без маркировки с разных производств, сотрудники которых не знают, что именно они производят.

TL;DR

Винс с канала Neptunium и Бен с канала Aspect Everything исследовали Coca-Cola, ингредиенты Зака и похожие напитки (включая Pepsi) на масс-спектрометрах.

Рецепт Lab Cola

Оборудование:

• Точные весы
• Регулируемая микропипетка (до 1000 мкл)
• Мерный цилиндр на 50 мл
• Литровые бутылки для хранения
• Термостойкая стеклянная посуда (не металлическая — фосфорная кислота разъедает металл)
• Магнитная мешалка и мерная колба на 1 л (по желанию)

Ингредиенты:

Эфирные масла, сахар, газированная вода, кофеин, карамельный краситель, пищевой спирт, 85%-ная фосфорная кислота, глицерин, винные танины, 5%-ный уксус, ванильный экстракт, фенхол.

Смесь A — ароматизатор «7X»:

• 45,8 мл лимонного масла
• 36,5 мл лаймового масла
• 1,2 мл апельсинового масла
• 8 мл масла чайного дерева
• 4,5 мл масла кассии (корицы)
• 2,7 мл мускатного масла
• 0,7 мл кориандрового масла
• 0,6 мл фенхола

Смесь желательно выдержать один-два дня. Затем 20 мл ароматической основы разводят пищевым спиртом до одного литра. Этого хватит более чем на 5000 литров газировки.

Смесь B — водорастворимые компоненты:

В примерно 200 мл горячей воды растворить:

• 10 мл 5%-ного уксуса
• 9,65 г кофеина
• 175 г глицерина
• 45 мл 85%-ной фосфорной кислоты
• 8 г винных танинов
• 10 мл ванильного экстракта
• 320 мл карамельного красителя

Довести объём водой до одного литра.

Приготовление напитка:

1. Растворить 104 г сахара в небольшом количестве воды (не 110 г — фосфорная кислота гидролизует сахарозу).

2. Влить 10 мл смеси B и 1 мл смеси A (7X).

3. Нагреть почти до кипения и накрыть крышкой.

4. Остудить и довести холодной газированной водой до одного литра.

5. Для лучшего вкуса дать постоять в холодильнике сутки.

Зак организовал для своей колы слепые и открытые дегустации. Участники с трудом отличали Lab Cola от настоящей Coca-Cola.

Те, кто регулярно пьёт Coca-Cola, чаще угадывали реплику, но общий вывод таков: Lab Cola можно спутать с Coca-Cola (но не с Pepsi). Когда напиток пробовали отдельно, без прямого сравнения, его принимали за оригинал — в отличие от рецепта Пембертона, Open Cola и прочих клонов.

Актуальную версию рецепта автор обещает поддерживать в описании под видео.

1. https://syscalls.mebeim.net – всегда свежие данные; есть сигнатура вызова; JSON для отдельных версий ядра.

2. https://syscalls.defoy.tech – еженедельное обновление; syscalls.tar.gz всех CSV.

3. https://x64.syscall.sh – только arm, arm64, x86; есть сигнатура вызова; есть API сайта.

4. https://filippo.io/linux-syscall-table – Linux 6.16-rc1; нечёткий поиск по имени; исходники этого HTML на Go.

Enjoy!

Александр Веденеев пишет:

https://cex-c.org

Cex.C - Comprehensively Extended C Language
No dependency, cross-platform, single header C language extension. Making old C cexy again!

https://github.com/alexveden/cex

Cex.C (officially pronounced /ˈtsɛk.si/ «tsek-see») was born as alternative answer to a plethora of brand new LLVM based languages which strive to replace old C. Cex.C still remains C language itself, with small, but important tweaks that bring a completely different development experience.

LEGAL NOTICE: Any intentional mispronunciation of Cex.C or cexy$ (build system), officially pronounced /ˈtsɛk.si/ («tsek-see»), into an incorrect form may be considered intentional tseksual harassment of the project — which identifies itself with the code gender (it/its) — and may be subject to legal action under the MIT License. /LOL/

$ stat cex.h:

Size: 680288

#define CEX_IMPLEMENTATION
#include "cex.h"

int
main(int argc, char** argv)
{
    io.printf("MOCCA - Make Old C Cexy Again!\n");
    return 0;
}

https://www.exdupe.net.

Исходный код на C и C++: https://github.com/rrrlasse/eXdupe, GNU GPL 2.0+.

Версия 3.0.0 от 30 июня:

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

https://naked-science.ru/article/astronomy/new-interior-models-of-ur

По общепринятой и незыблемой до сих пор версии, Уран и Нептун — ледяные гиганты: основную часть их массы составляют летучие вещества в особом состоянии «горячих льдов». Теперь у планетологов появилась альтернативная гипотеза: они подозревают, что никаких «горячих льдов» внутри них может не быть, а вместо этого есть крупные каменные ядра, окруженные легкой газовой оболочкой.

Плотность Юпитера на самом деле даже немного выше плотности Урана — 1,33 грамма на кубический сантиметр. Тем не менее пока что никто не сомневается в том, что крупнейшая планета Солнечной системы — газовый гигант: состоит он почти целиком из водорода, но его огромная масса (318 масс Земли) создает внутри настолько экстремальное давление, что водород в самом центре переходит в «металлическое» состояние. 

Уран заключает в себе лишь около 14 масс Земли, а Нептун — 17, но при этом их плотности составляют 1,27 и 1,64 грамма на кубический сантиметр соответственно. Такого сильного давления, как внутри Юпитера, в них быть не может. Поэтому планетологи и пришли к выводу, что водород и гелий составляют лишь примерно треть их общей массы, а под этой легкой оболочкой должно скрываться нечто более тяжелое. 

До сих пор считалось, что это в основном «льды» — вода, аммиак и метан в совершенно особом состоянии, возможном только при очень сильном давлении и нагреве. Впрочем, в центрах обеих планет все же предполагается твердое ядро из камня и металла размерами и массой ориентировочно с Землю.

Недавно ученые из Университета Цюриха (Швейцария) поставили эту устоявшуюся концепцию под сомнение и поделились собственными расчетами в статье, доступной (1) на сервере препринтов arXiv.org. Они заверили, что собранных на сегодня данных об Уране и Нептуне недостаточно для того, чтобы уверенно называть их ледяными гигантами. 

Исследователи смоделировали разные варианты внутреннего строения этих планет так, чтобы оно одновременно соответствовало и всем их наблюдаемым параметрам, и вообще законам физики. Как выяснилось, и Уран, и Нептун с таким же успехом могут оказаться не ледяными, а «каменными» гигантами — содержать в себе твердые ядра размерами и массой до половины всей планеты и даже больше. Напомним, диаметр Урана и Нептуна — примерно 51 и 49 тысяч километров соответственно.

Ученые задались вопросом: как в таком случае должны генерироваться магнитные поля двух планет? У Урана и Нептуна они намного слабее, чем у Земли, а устроены гораздо сложнее. По основной версии, они формируются не в ядре, а в мантии — там вода от давления распадается на ионы, становится гораздо более электропроводной, и ее интенсивное перемешивание создает магнитное динамо. Как пишут планетологи, даже в качестве «каменных гигантов» Уран и Нептун не лишаются этого электропроводящего слоя, хотя он и должен быть тоньше, чем в классической модели их внутреннего строения.

(1) https://arxiv.org/abs/2510.00175

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

Команда модераторов, отвечавшая за поддержание порядка в форумах и репозиториях проекта NixOS, объявила о снятии с себя полномочий в знак протеста против действий управляющего комитета (SC - Steering Committee), вмешивающегося в работу модераторов и пытающегося влиять на принимаемые решения. Действия комитета рассматриваются модераторами как превышение полномочий и, так как правила проекта не регламентируют подобные ситуации, команда модераторов решила, что в сложившихся условиях не может добросовестно выполнять свою работу.

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

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

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

Дополнение: Роберт Хенсинг (Robert Hensing) из управляющего комитета пояснил, что комитет пытался сотрудничать с командой модераторов для понимания модераторских решений, чтобы направить поведение модераторов в объективное русло, а также сделать модерацию справедливой. Основное недовольство модераторами было связано с тем, что модерация проводилась не на основе кодекса поведения, а на личных мнениях и компромиссах. Более решительные меры были предприняты так как модераторы не хотели отчитываться перед управляющим комитетом, которому они напрямую подчинены в иерархии проекта.