Hacker News Digest

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

Инициатива i4is объявила победителей международного конкурса дизайна поколенческого корабля для 250‑летнего перелета к обитаемой планете. Междисциплинарные команды проектировали среду, способную поддерживать и развивать общество при жестких ресурсных ограничениях.

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

• Обитаемость для 1 000 ± 500 человек
• Искусственную гравитацию за счет вращения
• Достойные условия жизни и базовые потребности
• Надежные контуры жизнеобеспечения: пища, вода, отходы, атмосфера
• Механизмы передачи знаний и культуры

Подробнее о требованиях — по ссылке на документ.

Благодарности жюри

Работы оценивали эксперты из архитектуры, инженерии и социальных наук (Университет Хьюстона; NASA‑JPL; Университет штата Аризона; Университет штата Орегон; Университет Южной Калифорнии).

1 место

Команда: Giacomo Infelise, Veronica Magli, Guido Sbrogio', Nevenka Martinello, Federica Chiara Serpe

Отзыв жюри

Chrysalis выделился системной целостностью и инновационной модульной архитектурой, глубокой проработкой (включая производство в космосе и подготовку экипажа в Антарктике). Модульная оболочка гибка и масштабируема; большой Купол придает выразительность. Сильны планирование строительства корабля и защита от радиации; конструктив реалистичен. Культурный блок можно развить, но концепт убедителен и зрелищен, отсылает к «Раме» и мировым кораблям 1980‑х.

2 место

Команда: Julia Biernacik, Jakub Kot, Aleksandra Wróbel, Jacek Janas, Michał Kucharski, Wiktoria Kuchta, Natalia Łakoma, Katarzyna Śliwa Наставник: д-р хаб. Michał Kracik Факультет промышленного дизайна (студия «Дизайн для экстремальных сред»), Академия изящных искусств в Кракове

Отзыв жюри

WFP Extreme отмечен за общий уровень и акцент на культуре и обществе: одежда, духовные пространства, «такси‑капсула», персонализированная униформа, защита от радиации. Системная целостность и интерьер при искусственной гравитации требуют доработки, но конструктив уместен для орбитальных применений. Балансирует технические амбиции с тонким видением будущей космической жизни.

• Обсуждение крутится вокруг концепции поколенческих звездолётов и конкурса дизайнов: многие впечатлены идеями и визуалами, но сомневаются в реализуемости.
• Критика охватывает социальные аспекты (учёт женщин, психическое здоровье, подростки на борту, эвтаназия как TBD), управляемость общества и этику многовекового эксперимента.
• Технические возражения: неверные расчёты скорости/времени, колоссальные энергетические и финансовые затраты, ненадёжность замкнутых экосистем (пример Biosphere 2), проблемы с воспроизводством без защиты магнитного поля.
• Обсуждают минимально жизнеспособную популяцию и варианты расширения генетического пула (замороженные эмбрионы), а также альтернативы: замороженные экипажи/эмбрионы, нанобот-/фон-Нейман‑зонды, рельсовые ускорители и орбитальные суперструктуры.
• Скептики ссылаются на художественные и научно-популярные примеры (KSR “Aurora”, “Aniara”, Хайнлайн) как иллюстрации «неизвестных неизвестных» и социальной деградации на пути.
• Есть и прагматики: «реальность» как единственный тест — не один «ковчег», а множество разных подходов; сначала нужно решить земные проблемы и освоить замкнутые биосистемы.
• Итоговый тон смешанный: от воодушевления образовательной ценностью и дизайном до убеждённости, что при нынешних технологиях поколенческие корабли — красивая, но несостоятельная фантазия.

• Несколько лет назад мне выпал шанс выбрать async‑first, типизированный Python‑фреймворк для веба. Я взял Litestar — без хайпа и ракет в твитах — и не пожалел: уже около 18 месяцев все мои новые рабочие проекты на нём.

• Даже если вы пишете асинхронные веб‑приложения на Python, вы могли пройти мимо Litestar. Хочу это исправить.

• Вкус демо: простой файл

  from litestar import Litestar, get
  
  @get("/greet")
  async def greet(name: str) -> str:
      return f"Hi, {name}!"
  
  app = Litestar([greet])
  

  Запускаете через litestar run или любой ASGI‑сервер. /greet?name=Bob вернёт «Hi, Bob!». Без name — HTTP 400: параметр обязателен. Да, похоже на FastAPI и на знакомые по Spring/ASP.NET MVC подходы с аннотациями — и FastAPI тоже так умеет. Но у Litestar есть свои сильные стороны.

• Про название: раньше проект назывался Starlite, потому что изначально строился на Starlette (как и FastAPI). Позже зависимость убрали, а чтобы не путать со Starlette, в релизе 2.0 (2023) переименовали в Litestar.

• Масштабирование кода, а не трафика:

  • Django плохо «масштабируется вниз»: «правильный» старт быстро разрастается в десяток файлов и папок. Однофайловые трюки работают, но против шерсти.
  • Микрофреймворки — наоборот: стартуют в одном файле, но по мере роста кода расползаются и начинают мешать.
  • В FastAPI маршруты обычно вешаются декораторами на объект приложения. Это удобно в одном файле, но при разбиении на модули ведёт к циклическим импортам. Решение — «вторичные» реестры маршрутов (APIRouter, blueprint): нужны, потому что декораторы привязаны к app. Litestar же позволяет описывать обработчики отдельно и передавать их приложению списком, что естественно масштабируется от одного файла к структуре проекта без костылей.

• Обсуждение сравнивает FastAPI, Litestar, Starlette и Django для построения бекендов: многие отмечают, что FastAPI удобен для простых сервисов, но усложняется в больших кодовых базах, тогда как Litestar воспринимается более продуманным и быстрым для сложных API.
• Несколько участников хвалят Litestar: высокая скорость, асинхронность, first-class msgspec, контроллеры для вложенных роутов, кеширование, плагины (в т.ч. для HTMX), и развивающийся Advanced Alchemy; отмечают, что у него больше одного мейнтейнера.
• Часть разработчиков предпочитает Starlette как легковесную основу без «всей кухни», а Django ценят за ORM; обсуждают плюсы/минусы SQLAlchemy и альтернативы (peewee), а также идею разделять модели API и БД с самого начала.
• Критика FastAPI касается структуры кода, управления зависимостями и разрыва между туториалами и реальными практиками; при этом приводят ссылки на репозитории-референсы, где показано, как масштабировать FastAPI.
• Запросы и сомнения: как обрабатывать ошибки при стриминге, как деплоить (NGINX Unit упоминался как «капризный»), и нужен ли референс-проект Litestar; приводят litestar-fullstack как пример.
• В целом тон дискуссии: многие либо мигрируют с FastAPI на Litestar, либо довольны Starlette; документацию нового поколения фреймворков часто критикуют за недостаток строгого API-референса и переизбыток туториалов.

• В 70‑х некоторые системы (например, PDP‑10) имели 9‑битовые байты, но стандарт закрепился за 8 битами. Если бы байт был 9‑битным, ряд исторических случайностей сыграли бы нам на руку.

• IPv4: при 9‑битовых байтах адрес IPv4 был бы 36‑битным (~64 млрд адресов). Этого хватило бы до 2030‑х без массового NAT и тормозов с IPv6; позже проблему решили бы мягкими рыночными механизмами.

• UNIX time: 32‑битные метки ломаются в 2038, а 36‑битные прожили бы до 3058. Отрицательные охватывали бы времена с 882 года — достаточно для исторических нужд.

• Юникод: вместо 16‑битных 65 тыс. символов было бы 18‑битных 262 тыс. — хватило бы без болезненной унификации CJK; сейчас всех символов ~155 тыс. UTF‑9 стал бы скорее компрессией и уступил бы GZip; либо однобайтно‑двухбайтная схема при умеренной экономии на эмодзи.

• Указатели и память: 36‑битные ОС дали бы до 32 ГБ на процесс (вместо 2 ГБ у 32‑битных). Серверы всё равно виртуализируют; меньшие указатели экономят память и ускоряют код, хотя строки стали бы длиннее — общий баланс близок к нулю.

• Прочие выигрыши:

  • 18‑битные AS‑номера не иссякли бы; порты/PID/UID просторнее.
  • Кодирование инструкций x86/A64 чуть опрятнее; Thumb работал бы лучше.
  • Полуточные 18‑битные числа прижились бы раньше; экзотика 4–5 бит не взлетела бы.
  • Расширенный ASCII влез бы с греческим и стал бы «натовской» кодовой страницей; UTF‑9 привилегировал бы почти всю Западную Европу.
  • Права Unix умещались бы в один байт (без «липких» битов). Оctal стал бы нормой вместо hex.
  • 18‑битный цвет 6/6/6 даёт различия на грани восприятия; потеря альфа‑канала неприятна.

• Издержки? Существенных нет: адресация по битам не используется; деления на девять не требуется; размеры страниц/блоков ОС могли бы остаться прежними, ядру не пришлось бы менять основы работы.

• Обсуждение крутится вокруг гипотетического мира с 9-битными байтами: часть участников отмечает аппаратную неудобность непоказательных (не 2^n) размеров и сложность для мультипликаторов, адресации и сдвигов.
• Скептики считают аргументы «добавим по одному биту и всё станет лучше» натянутыми: решения о размерах всё равно принимались бы иначе, а выигрыш в 12.5% не компенсирует издержки и усложнение.
• Приводятся исторические примеры: PDP-8/10 с 12/36-битными словами, 6-битные коды, термин «octet» для однозначности; упоминается даже N64 с «внутренними» 9-битными байтами для GPU.
• По сетям: 36-битный IPv4 дал бы ~64 млрд адресов, но это лишь отсрочка дефицита; проблемы ASLR и безопасности 32-битной адресации 36 битами решаются слабо, переход на 64 бита всё равно был бы.
• Есть идеи альтернатив: 10-битные байты, тернарные системы, 9-й бит как признак продолжения для варинтов/инструкций, либо как служебный (ECC/контроль/метка данных).
• Отмечают экономику кремния: лишние провода/логика удорожают дизайн; если уже расширять шину, логичнее идти к степеням двойки (например, к 16 битам на «байт»).
• Итоговый тон дискуссии: 9 бит могли бы немного смягчить отдельные «почти-не-хватает» пороги (16/32-бит), но в целом это привнесло бы больше сложностей, чем пользы; ключ — лучше прогнозировать размеры, а не «маскировать» ошибки лишним битом.

MS used to have uservoice pages. They ignored issues, no matter how highly-voted they were. I once asked someone at MS about this, and they said they take their cues from other sources, like what industry partners ask them to fix at conferences.What a waste of time to have uservo

In my 20s I did a year long internship in Japan and lived in a dorm owned by the company I worked for.Single room with bed and desk, bathroom down the hall, shared cafeteria on the first floor with breakfast and dinner served every day (lunch expected to be eaten at the office).N

Моя предыдущая статья о обобщённых структурах данных в C готовила почву к теме: структура, которая заменяет динамические массивы, даёт стабильные указатели и хорошо работает с аренными аллокаторами. Её переоткрывали много раз под разными именами: “levelwise-allocated pile” (2001), в Zig — Segmented List, частично похожая на C++ std::deque. Мне нравится название Per Vognsen — Segment Array.

Скачать мой однофайловый заголовок segment_array.h можно, подписавшись на рассылку.

Идея проста: фиксированный массив указателей на сегменты; каждый следующий сегмент вдвое больше предыдущего; новые сегменты выделяются по мере необходимости. Поскольку элементы не двигаются, указатели на них стабильны, не остаются “дыры” в арене, а доступ по индексу — за O(1).

Реализация

Структура на C:

typedef struct { u32 count; int used_segments; u8 *segments[26]; } SegmentArrayInternal;

Почему всего 26 сегментов? Из 64 бит указателя обычно реально используются 48, так что 49 сегментов уже перекрывают адресное пространство (~256 ТиБ). Я предпочитаю индекс u32 (до ~4 млрд элементов) — это даёт 32 сегмента. Ещё убираем 6 маленьких (1..32), начинаем с 64, остаётся 26 сегментов — хватает для 4 294 967 232 элементов (чуть меньше UINT32_MAX). Фиксированный массив рядом со структурой снижает риск промаха кэша.

Размеры сегментов — степени двойки: проще математика и быстрые сдвиги для индексов.

#define SMALL_SEGMENTS_TO_SKIP 6

#define log2i(X) ((u32) (8*sizeof(unsigned long long)
- __builtin_clzll((X)) - 1))

u32 capacity_for_segment_count(int segment_count) { return ((1 << SMALL_SEGMENTS_TO_SKIP) << segment_count) - (1 << SMALL_SEGMENTS_TO_SKIP); }

void *_sa_get(SegmentArrayInternal sa, u32 index, size_t item_size) { int segment = log2i((index >> SMALL_SEGMENTS_TO_SKIP) + 1); u32 slot = index - capacity_for_segment_count(segment); return sa->segments[segment] + item_sizeslot; }

log2i использует __builtin_clzll (подсчёт ведущих нулей) для быстрого вычисления номера сегмента.

Clang оптимизирует _sa_get до ~10 инструкций x86-64 (-O3), так что узким местом будет память, а не вычисления индекса. При последовательной итерации можно обходить сегменты напрямую; в segment_array.h есть макрос.

Выделение нового элемента:

u32 slots_in_segment(int segment_index) { return (1 << SMALL_SEGMENTS_TO_SKIP) << segment_index; }

void *_sa_alloc(SegmentArrayInternal *sa, size_t item_size) { if (sa->count >= capacity_for_segment_count(sa->used_segments)) { size_t segment_size = item_size * slots_in_segment(sa->used_segments); sa->segments[sa->used_segments++] = malloc(segment_size); } sa->count++; return _sa_get(sa, sa->count-1, item_size); }

Замечание: можно сделать ёмкость строго степенью двойки, если первые два сегмента одинакового размера. Код станет менее изящным, но это спасает от ~50% потерь памяти при использовании как массива бакетов в хеш-таблице со степенью двойки.

Дженерики

Я применяю технику из прошлой статьи для типобезопасного хранения любого типа. Макрос связывает тип с общей структурой:

#define SegmentArray(type)
union {
SegmentArrayInternal internal;
type *payload;
}

Дальше макросы используют payload, чтобы передавать сведения о типе…

• Обсуждается структура «сегментированный массив» (экспоненциальные сегменты), её плюсы и минусы, и сравнение с существующими решениями: std::deque, ropes, Zig std.SegmentedList, rust-array-stump, plf::colony.
• Критика терминологии: это не «массив» в классическом смысле из‑за неконтигуозной памяти; многие API ожидают сплошной/страйдовый буфер и не подойдут.
• Производительность: при локальных L1-итерациях вычислительная часть индексации может быть ощутима; для больших объёмов память становится бутылочным горлышком. Предлагаются оптимизации итерации по сегментам и замечания про clz/bsr/lzcnt и опции компилятора.
• Виртуальная память как альтернатива: резервирование большого диапазона и по мере роста коммит страниц/guard pages; отмечены плюсы на Linux (MAP_POPULATE, mremap), но плохо для embedded/WASM.
• Сравнение с deque: фиксированные блоки vs экспоненциальные, поддержка prepend, рандом-доступ есть; реализация MSVC критикуется за малый размер блока, GNU/libc++ лучше.
• Недостатки сегментов: ухудшение предвыборки/кэш-локальности при линейной итерации, отсутствие стабильной непрерывности для API, сложность с хеш-таблицами при росте (rehash), потенциальный перерасход памяти при экспоненциальных размерах.
• Предложения: настраиваемый минимальный размер сегмента, функции «склейки» мелких сегментов, разбор условий, когда экспоненциальные сегменты оправданы, и замечания о чрезмерной макротрюковости в C/C23.

• Исправления

  • Уточнено сообщение об ошибке с некорректной терминологией. (Louis Pilfold)
  • JS: устранён сбой при использовании echo в модуле с функцией process. (Peter Saxton)
  • Форматер: не переносит комментарий перед assert за него; корректно форматирует сообщения после echo/panic/todo/assert/let assert с комментарием перед ними; компилятор не генерирует неверный код для assert с пайпами на JS. (Giacomo Cavalieri)

• Форматирование битовых массивов

  • Трейлинг-Запятая управляет разбиением: с запятой — много строк; без — в одну строку.
  • Если несколько сегментов на строке и убрана завершающая запятая, форматер сохраняет сегменты по одному на строку. (Giacomo Cavalieri)

• Компилятор и генерация кода

  • echo поддерживает пользовательское сообщение: echo 11 as "lucky number" печатает контекст и значение в stderr. (Giacomo Cavalieri)
  • В сгенерированном JS doc-комментарии превращаются в JSDoc. (Giacomo Cavalieri)
  • Уменьшен размер кода case на JS. (Surya Rose)
  • Удаление неиспользуемого кода на этапе генерации (usage-based DCE). (Louis Pilfold)
  • Улучшена поддержка echo для списков символов, ошибок и циклических ссылок JS. (Louis Pilfold)
  • Улучшен внешний вид ошибок и предупреждений: контекстные метки выделяются иначе, чем источник проблемы. (Giacomo Cavalieri)
  • Подсказка при импорте с точкой вместо слеша, с примерами корректного синтаксиса. (Zij-IT)
  • Предупреждение при затенении импортированного имени верхнеуровневой константой/функцией. (Aayush Tripathi)
  • Улучшено сообщение об неизвестной переменной, если, вероятно, имелась в виду проигнорированная (_x → x), с подсказкой. (Giacomo Cavalieri)
  • Оптимизирован матчинг-паттернов на JS.

• Обсуждение посвящено релизу Gleam: многие хвалят дизайн языка, читаемость, статическую типизацию и паттерн-матчинг; приводят пример кода и делятся позитивным опытом использования в проектах.
• Есть ссылки на пост о версии 1.12.0 и доклад на YouTube; некоторые ждут дальнейшего созревания экосистемы и возможности шаринга кода между фронтендом и бэкендом.
• Критика: отсутствие интерфейсов/тайпклассов и оператора композиции; кому-то синтаксис и «Error -> Error» кажутся неэлегантными; snake_case непривычен после TypeScript.
• В ответ отмечают осознанную простоту языка и официальную позицию Gleam по отказу от тайпклассов.
• Существенная часть треда уходит в спор о «идеологичном» футере сайта (инклюзивность, антинацистская позиция, права транс-людей): часть считает это лишним, другие — важным для безопасности и качества сообщества.
• Подчеркивается, что Gleam — это не только язык, но и сообщество с явным кодексом поведения; отсутствие позиции тоже является позицией.
• Некоторые участники призывают вернуться к техническим темам релиза, чтобы не повторять одни и те же дискуссии.

• Идея децентрализованных mesh-мессенджеров повторяется годами, но Bluetooth/Wi-Fi-варианты страдают из-за ненадёжности радиоканала, различий платформ и нехватки критической массы пользователей.
• Участники делятся опытом: FireChat на EDC не работал, Bitchat выглядит хобби-проектом, а промышленные BLE-решения быстро теряют стабильность при ретрансляции.
• Позитивные примеры — аппаратные устройства (GoTenna, Meshtastic, LoRa) и FRS-рации; телефоны пока не стали «телекоммуникаторами» без сотовой сети.
• Некоторые предлагают переходить к стандартизированным протоколам или store-and-forward с библиотеками вроде minisketch, а не бесконечно изобретать новые приложения.
• Apple FindMy упоминается как крупномасштабный пример, но это не mesh, а лишь ретрансляция маячков в облако Apple.

Дэн Бертон, владелец Urban Trapping Wildlife Control в Салинасе, вскрыл дикого кабана и обнаружил «неоново‑синее, как черника» мясо. Он сообщил в округ Монтерей и Департамент рыбы и дичи Калифорнии (CDFW). Власти предупреждают охотников и трапперов: возможное загрязнение мясной ткани связано с поеданием животными антикоагулянтного родентицида дифацинола, широко применяемого в сельском хозяйстве против крыс, мышей и сусликов.

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

• Обсуждение касается диких свиней с неоново‑синей окраской мяса, что, как отмечают многие, связано с поеданием родентицидов, содержащих синий трифенилметановый краситель для идентификации яда.
• Пользователи подчеркивают риск вторичного отравления: яды поражают не только крыс, но и хищников, домашних животных и людей через пищевые цепочки; приводятся личные трагические примеры.
• Отмечена высокая разрушительность и инвазивность диких свиней для сельского хозяйства, их сверхбыстрая репродукция и потому активные меры по контролю численности (лов, отстрел и др.).
• Критикуют кликбейтные заголовки; предлагают более информативные формулировки и уточняют, что в Калифорнии уже ограничивают/запрещают некоторые яды из‑за воздействия на дикую природу.
• Дискуссия затрагивает альтернативы ядам (например, программы “community cats”) и важность предупреждать соседей при использовании отрав.
• Уточняют, что синее мясо обнаружили при отлове и эвтаназии свиней по заказу агрофирмы; обычно мясо могли бы пожертвовать, но в таких случаях это опасно.
• Некоторые участники делятся ссылками, замечаниями о слабом качестве репортажа и шутками, но общий вывод: причина синевы известна — краситель в родентицидных приманках и связанные с этим экологические риски.

• Логотип Multics

• Домой

  • История »
    • Возможности
    • Мифы
    • Project MAC
    • Даты
    • Глоссарий
    • Проект истории
    • Последний сайт
  • Люди »
    • Истории
    • Фотографии
    • Юмор
    • Памятные вещи
  • Библиотека »
    • Статьи и доклады
    • Технические статьи
    • Документы разработки
    • Исходники
    • Симулятор
  • Сайты »
    • Хронология площадок
    • AFDSC (Пентагон, Вашингтон)
    • ASEA (Вестерос, Швеция)
    • Avon (Бристоль, Англия)
    • Bell Canada (2 площадки)
    • CISL (Кембридж, Массачусетс)
    • CNO (Миннеаполис, Миннесота)
    • DND-H (Галифакс, Канада)
    • DOCKMASTER (АНБ, Мэриленд)
    • FORD (Детройт, Мичиган)
    • GM (Детройт, Мичиган)
    • Майнц (Германия)
    • MIT (Кембридж, Массачусетс)
    • NWGS (ВМС США, 4 площадки)
    • OU (Рочестер, Мичиган)
    • PRHA (Сан-Хуан, Пуэрто-Рико)
    • RADC (Рим, Нью-Йорк)
    • RAE (Фарнборо, Англия)
    • STC (Лондон, Англия)
    • System-M (Финикс, Аризона)
    • Systeme X (Лувесьен, Франция)
    • UC/ACTC (Калгари, Канада)
    • USGS (3 площадки)
    • USL (Лафайет, Луизиана)
    • VPI (Блэксберг, Вирджиния)
  • О сайте »
    • Изменения
    • Новости
    • Ссылки
    • Галерея
    • Карта сайта

• Поиск

• Меню: История: Возможности | Мифы | Project MAC | Даты

• Участники обсуждают влияние Multics на современную вычислительную технику: от безопасности и архитектуры до наследия в текущих проектах (например, STOP, происходящий от SCOMP/STOP).
• Делятся воспоминаниями об использовании Multics в британских университетах в 80-х: система считалась быстрой, апгрейды памяти были ощутимыми, доступ через терминалы и JANET, позитивный опыт работы.
• Мнения расходятся: одни критикуют «всеобъемлющесть» дизайна и сложность (в контраст к UNIX), другие подчёркивают сильные стороны Multics — кольца защиты, строгие политики доступа (MAC/ACL), сегментную память и отсутствие переполнений буфера.
• Отмечают ограниченную портируемость Multics к немногим мэйнфреймам, несмотря на теоретическую переносимость.
• Ссылаются на полезные ресурсы: мифы о Multics, оценка безопасности B2, страницы по безопасности данных (AIM/MAC), «Три вопроса» для анализа багов, меморабилии, хронологии и список недавних изменений.
• Обсуждают спад активности оригинальных установок (последние закрытия около 2000 г.), эмулятор DPS8M и печальные новости об уходе участников проекта.
• Несколько комментаторов переосмыслили роль UNIX после знакомства с историей Multics и более ранними идеями (Xerox PARC), видя в Multics самостоятельную и богатую идеями систему, а не только «предтечу UNIX».