MapSCII — это инструмент для отображения карт мира прямо в терминале с использованием символов ASCII и Брайля. Для подключения на Mac и Linux достаточно выполнить команду telnet mapscii.me, предварительно установив telnet (например, через brew install telnet), а на Windows — использовать PuTTY.

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

• Обсуждение технических аспектов работы карты в различных терминалах и через Telnet, включая проблемы с отображением и поддержкой мыши.
• Упоминание о возрасте проекта (более 8 лет) и его доступности для vintage-компьютеров через Telnet.
• Сравнение проекта с другими известными работами, такими как Google Maps для NES и ежедневной игрой FoodGuessr.
• Восторженные отзывы о визуальной реализации и использовании OpenStreetMap для детализации до уровня улиц.
• Несколько комментаторов изначально спутали проект с чем-то связанным со StarCraft II из-за аббревиатуры SCII.

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

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

• Обсуждается условность расположения севера наверху карт, с аргументами о практичности (большинство суши и населения в северном полушарии, использование компаса) и отсутствии морального аспекта в этом выборе.
• Поднимается вопрос о психологических ассоциациях (верх = хорошо, низ = плохо), но многие участники считают эту связь надуманной или навязываемой самими статьями.
• Упоминаются альтернативные проекции и ориентации карт (югом вверх, востоком вверх, Dymaxion), которые столь же корректны и предлагают новый взгляд на мир.
• Отмечается, что ориентация карт часто обусловлена историческими и культурными причинами (место создания карт, удобство для конкретного региона), а не объективной правильностью.
• Некоторые участники видят в обсуждении надуманную проблему, поскольку современные цифровые карты и навигаторы произвольно меняют ориентацию.

Изучай по-своему: Переосмысление учебников с помощью генеративного ИИ

Исследования Google

Кто мы

Создаем технологии сегодняшнего и завтрашнего дня. Стремимся к созданию среды для разнообразных исследований с разными временными масштабами и уровнями риска.

Области исследований

• Фундаментальное ML и алгоритмы: теория алгоритмов, управление данными, машинное восприятие, NLP
• Вычислительные системы и квантовый ИИ: распределенные системы, квантовые вычисления, робототехника, безопасность
• Наука, ИИ и общество: климат и устойчивость, инновации в образовании, здравоохранение, взаимодействие человека и компьютера

• Пользователи обсуждают потенциал ИИ-инструментов для персонализированного обучения, отмечая как преимущества (бесконечное терпение, возможность углубляться в темы), так и серьёзные недостатки (фактические ошибки, выдумывание информации, высокая стоимость инфраструктуры).
• Критики выражают сомнения в эффективности и целесообразности замены учителей ИИ, указывая на риск снижения качества образования, антиинтеллектуализм и отсутствие подотчётности за вредоносные или ложные выводы модели.
• Многие комментаторы проводят параллели с концепцией «Иллюстрированного букваря для юной леди» из романа «Алмазный век» Нила Стивенсона, видя в проекте шаг к подобному будущему.
• Поднимается вопрос о методологии исследования Google: отсутствие контроля в виде печатного учебника и сравнения с не-ИИ интерактивными форматами, что ставит под сомнение заявленные преимущества.
• Обсуждается фундаментальная проблема школьного образования — необходимость заинтересовать и заставить учиться всех детей, а не только мотивированных, и сомнения, что ИИ способен решить эту задачу.

OpenTelemetry Collector: что это, когда нужен и когда нет

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

Нужен ли вам OpenTelemetry Collector? Для небольших проектов — возможно нет. Для production-среды с множеством сервисов, где важны стоимость, производительность и безопасность — почти наверняка да.

Краткое определение

OpenTelemetry Collector — это нейтральный к вендорам, расширяемый конвейер телеметрии, который принимает, обрабатывает и экспортирует данные (трейсы, метрики, логи) из ваших приложений в одно или несколько хранилищ.

Он позволяет:

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

Архитектура

Без Collector (прямой экспорт)

Каждый сервис отправляет телеметрию напрямую в бэкенд:

Плюсы:

• Проще (меньше компонентов)
• Меньше операционных затрат
• Подходит для маленьких приложений / POC

Минусы:

• Каждый сервис сам handles retries, auth, backpressure
• Сложно менять экспортеры
• Нет централизованного семплирования / очистки / маршрутизации
• Риск misconfigurations
• Выше стоимость исходящего трафика при отправке в несколько систем

С центральным Collector

Все приложения отправляют данные в центральный Collector, который затем экспортирует:

Плюсы:

• Централизованная конфигурация: семплирование, очистка, обогащение
• Один канал исходящего трафика с пакетированием и retry
• Развязывает жизненный цикл приложения от изменений вендоров
• Меньше нагрузки на приложения
• Безопасность: приложения не выходят в интернет напрямую

• Рекомендуется использовать коллектор OpenTelemetry для упрощения архитектуры, локальной отладки и управления аутентификацией
• Предлагается декаплеить коллектор от потребителей трассировок через брокеры сообщений (Kafka/NATS) для надежности и масштабируемости
• Коллектор рассматривается как защитный шлюз (read-only) между приложениями и базой данных для безопасности
• Отмечается сложность освоения OpenTelemetry, но подчеркивается его ценность как стандарта для интероперабельности
• Указывается полезность OTEL даже для монолитов благодаря возможностям корреляции и вложенных спэнов
• Обсуждаются альтернативы (Vector vs OTEL) и необходимость улучшения документации и примеров
• Упоминается использование коллектора для валидации и тестирования с помощью AI-агентов

Google Chrome обновляется с помощью новейших технологий искусственного интеллекта, чтобы сделать его безопаснее, умнее и полезнее. Эти функции включают умную организацию вкладок, настройку тем и помощь в написании текстов. Они доступны на Mac и ПК в США, начиная с этой недели.

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

Эти инструменты используют локальные модели машинного обучения Google для обеспечения конфиденциальности. Chrome продолжит внедрять ИИ, чтобы улучшить работу в интернете.

• Пользователи выражают обеспокоенность по поводу конфиденциальности и безопасности из-за интеграции ИИ в браузер, которая подразумевает сбор и анализ всего содержимого вкладок.
• Многие сравнивают новые функции Chrome с функцией Recall от Microsoft, видя в них схожие угрозы приватности и потенциальные инструменты слежки.
• Высказывается сильное желание иметь возможность полностью отключить все ИИ-функции, сделать их строго опциональными (opt-in), а не включенными по умолчанию.
• Некоторые пользователи видят потенциальную пользу новых функций (например, поиск по истории на естественном языке, помощь в задачах), но лишь при условии локальной обработки данных.
• Обсуждается, что объявление Google игнорирует ключевые вопросы безопасности (например, prompt injection) и конфиденциальности, в отличие от похожих анонсов других компаний.
• Есть мнение, что это шаг по использованию доминирующего положения Chrome на рынке для продвижения собственной экосистемы ИИ и сбора большего количества данных.
• Некоторые пользователи рассматривают переход на альтернативные браузеры (Firefox, Chromium, Ladybird) как способ избежать нежелательных ИИ-функций.

Исаак Ньютон в студенческие годы открыл связь между площадями под кривыми и бесконечными суммами, переосмыслив классические задачи. Он начал с простых случаев, например, вычисления площади под ( y = (1 - x^2)^{1/2} ) (полукруг), и заметил закономерности в коэффициентах разложения. Путем догадок и проверок Ньютон обобщил биномиальную теорему на дробные степени, что позволило представлять функции в виде степенных рядов.

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

• Обсуждение значимости письма Ньютона как доказательства его приоритета над Лейбницем в разработке исчисления.
• Споры о доступности математики: одни считают, что современные развлечения отвлекают от глубоких идей, другие приводят примеры, что люди всё ещё способны на открытия.
• Технические проблемы с отображением математических формул на сайте: часть пользователей сталкивается с ошибками, другие не видят проблем.
• Упоминание работы Абхьянкара о важности школьной математики для серьёзных результатов.
• Обмен советами по решению проблем с отображением формул (блокировка JS, смена браузера).

Упрощённые версии GRU и LSTM (minGRU и minLSTM) позволяют заменить последовательные вычисления на параллельные, устраняя зависимость скрытого состояния от предыдущего шага. Это достигается за счёт переопределения гейтов так, чтобы они зависели только от текущего входа, что превращает рекуррентное обновление в линейную форму, разрешимую алгоритмом параллельного сканирования (scan). Такой подход сокращает сложность с O(T) до O(log T), что критично для ускорения на GPU.

Реализация на CUDA демонстрирует значительное ускорение: для последовательностей длиной 65 536 шагов время выполнения сокращается с ~13 секунд на CPU до ~5,3 секунд на GPU для GRU и с ~13 до ~6,7 секунд для LSTM. На коротких последовательностях (T < 2048) преимущество менее выражено из-за накладных расходов на распараллеливание, но с ростом длины масштабирование становится явным. Это подтверждает, что даже минимальные изменения в архитектуре RNN могут радикально улучшить их производительность на параллельных вычислениях.

• Обсуждаются архитектурные ограничения классических RNN/LSTM, в частности их последовательная природа, препятствующая эффективному распараллеливанию на GPU.
• Представлены упрощённые модели (minGRU, minLSTM) и альтернативные архитектуры (например, RWKV), которые пытаются устранить эти ограничения и конкурировать с трансформерами.
• Поднимается вопрос о возможности параллельного обучения RNN на разных независимых текстах (книгах) и обсуждаются сложности синхронизации градиентов.
• Уточняется, что мозг человека вряд ли является RNN, и выдвигаются альтернативные гипотезы о его работе, например, как модели поиска устойчивого состояния (equilibrium model).
• Обсуждается исторический контекст: почему трансформеры, несмотря на потенциальную эффективность RNN, стали доминировать благодаря лучшей параллелизации обучения.

Файлы конфигурации — это пользовательские интерфейсы. Мы часто сталкиваемся с ситуацией, когда растущее ПО требует настройки, но полноценный графический интерфейс кажется избыточным. Прагматичное решение — текстовый файл конфигурации, который легко версионировать и который оставляет возможность для будущего развития.

Выбор языка для конфигурации — непростая задача. JSON кажется слишком техническим, TOML — слишком минималистичным. И тут возникает соблазн использовать YAML: он приятен глазу и популярен. Однако за кажущейся простотой скрываются pitfalls, как показывает печально известный «документ из ада». Со временем даже небольшой YAML-файл может превратиться в кошмар поддержки.

Корень проблемы не в выборе языка (YAML vs. альтернативы), а в том, что мы недооцениваем конфигурационные файлы как пользовательские интерфейсы. Они должны обеспечивать отличный UX: предотвращать ошибки, вести пользователя к успеху и работать как «велосипед для ума».

Пример реализации такого подхода — проект KSON, который позиционируется как более эффективная альтернатива YAML/JSON/TOML. KSON является верифицированным надмножеством JSON, поддерживает JSON Schema и предлагает инструменты для улучшения работы с конфигурациями.

• Критика KSON за отсутствие чувствительности к пробелам, что может приводить к неочевидным ошибкам парсинга, как в примере с вложенным списком портов.
• Обеспокоенность рисками безопасности из-за единственной реализации на Kotlin и сложностей сборки для других языков, таких как Python и Rust.
• Предложение использовать полноценные языки программирования (например, Python) для конфигурации вместо специализированных форматов, чтобы дать пользователям больше инструментов.
• Аргумент в пользу того, что конфигурационные форматы должны быть выразительными, но ограниченными (как Cue, Starlark или Dhall), а не просто данными, как JSON или YAML.
• Подчёркивание различия между форматами для людей (конфигурация) и для компьютеров (данные), и критика попыток совместить их в одном формате.
• Замечание, что сложная конфигурация часто указывает на проблемы в дизайне ПО, и что лучше предоставить пользовательский интерфейс вместо сложных файлов.
• Упоминание альтернатив, таких как TOML, HJSON, HOCON, KDL и Jsonnet, с различными подходами к простоте, выразительности и проверке типов.

• Поддержка сохранения земель для восстановления биоразнообразия и будущих поколений
• Критика ограничения доступа к общественным землям частными владельцами как несправедливой практики
• Обсуждение различий в подходах к праву доступа и землепользованию между США, Великобританией и Скандинавией
• Озабоченность экономическими последствиями для местных сообществ при создании заповедников
• Дебаты о балансе между правами частной собственности и общественным доступом к природным территориям
• Вопросы о налоговых льготах для некоммерческих организаций, занимающихся консервацией земель
• Обсуждение юридических аспектов, включая ответственность владельцев и прецеденты по праву прохода

cactus-compute/cactus

Запуск ИИ локально на телефонах и AI-устройствах.

Навигационное меню

Платформа:

• GitHub Copilot
• GitHub Spark
• GitHub Models
• GitHub Advanced Security
• Actions
• Codespaces
• Issues
• Code Review
• Discussions
• Code Search

Решения:

• Для предприятий
• Малые и средние команды
• Стартапы
• Некоммерческие организации

Ресурсы:

• Темы (ИИ, DevOps, безопасность)
• Обучающие материалы
• Мероприятия
• Истории клиентов

Open Source:

• GitHub Sponsors
• The ReadME Project
• Репозитории

Enterprise:

• Платформа для предприятий
• Дополнительные модули
• Поддержка

Цены

• Пользователи обсуждают смену лицензии Cactus с Apache 2.0 на некоммерческую, выражая озабоченность по поводу доверия и её влияния на коммерческие приложения.
• Поднимаются вопросы о технических возможностях фреймворка: производительность на разных устройствах (Pixel 9 Pro, rk3588), использование NPU/GPU, размер приложений и влияние на батарею.
• Разработчики спрашивают о бизнес-модели проекта, коммерческом лицензировании и его стоимости, а также уточняют кажущиеся противоречия в формулировках о поддержке платформ.
• Обсуждаются функциональные возможности: работа с инструментами (веб-поиск), оффлайн-режим, добавление моделей и поддержка агентских workflow.
• Создатель проекта отвечает на вопросы, упоминая улучшения производительности, бесплатность для личного использования и возможность интеграции различных инструментов.