ufm

DEC PDP-11 в хорошем состоянии

🔗 DEC PDP-11 в хорошем состоянии

Дэйв Пламмер выставил на продажу один из своих PDP-11/73. Установлен юникс BSD 2.11, интернет, все дела. Гляньте, вдруг кому сгодится.

(фейсбук)

I'm selling one of my PDP-11/73s with "all my good parts" to cover the costs of the 11/24 I'm building. Basically, it's an infallible system as long as I stay one PDP ahead of things 🙂

Plug it in, turn it on - boot 211BSD UNIX already custom configured, serve WWW pages, FTP, Telnet, and more. This is your chance to own a maxed-out and completely turnkey, ready-to-run PDP-11 UNIX Workstation. You could also install and run RT-11 or RSX-11, but this machine has been carefully set up and configured with 211BSD UNIX, including all networking features.

This machine represents a collection of my very best PDP-11 components, including:

• DEC M8190 CPU
• DEC M8637 Fast PMI Memory (x2) for a total of 4M installed, the max permitted
• DEC M3104 Eight Port Serial Multiplex - Connect up to 9 total terminals (plus Ethernet sessions)
• DEC M7555 MFM and Floppy Controller
• Emulex UC07 SCSI Controller - Supports tapes, drives, jaz, and more, up to 6 devices - Boot multiple systems
• DEC M7516 Ethernet Adapter - The faster/better DELQA NIC
• DEC RX50 Dual Floppy Drive - Tested and mounted as /mnt/flopppy0 and /mnt/floppy1 for each file interchange
• Seagate ST43400N - 3GB SCSI Drive - Contains /root, /swap, /usr, and /data partitions

It's all housed in a rare and very nice DEC BA23 chassis and tower pedestal case with front cover plate.

comments

Наиболее эффективный язык для общения с ИИ

🔗 Наиболее эффективный язык для общения с ИИ



Нет, не английский, как ни странно. И не испанский. А польский!

Ну да, "я и сама офигела".

Исследование, проведенное Университетом Мэриленда (UMD) и Microsoft, показало, что из 26 различных языков польский оказался самым эффективным для управления моделями искусственного интеллекта (ИИ), а английский занял только шестое место.

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

Группа исследователей проверила, насколько хорошо несколько основных языковых моделей ИИ, включая OpenAI, Google Gemini, Qwen, Llama и DeepSeek, реагировали на одинаковые вводные данные на 26 различных языках.

Результаты показали, что польский язык продемонстрировал среднюю точность выполнения задач на уровне 88%.

«Как показывает анализ, он является самым точным с точки зрения подачи команд искусственному интеллекту. До сих пор польский язык широко считался одним из самых сложных для изучения. Как оказалось, люди испытывают с ним трудности, но не ИИ», — написало Польское патентное ведомство в посте на Facebook.

Интересно, что системы искусственного интеллекта продемонстрировали хорошее понимание польского языка, несмотря на то, что объем данных на польском языке, доступных для обучения, намного меньше, чем на английском или китайском.

Для сравнения, китайский язык показал заметно худшие результаты, заняв четвертое место с конца из 26 протестированных языков.

В топ-10 наиболее эффективных языков для разговорного ИИ вошли:
- Польский 88%
- Французский 87%
- Итальянский 86%
- Испанский 85%
- Русский 84%
- Английский 83,9%
- Украинский 83,5%
- Португальский 82%
- Немецкий 81%
- Нидерландский 80%

(Отсюда.)

#China #Norway #cybersecurity

> Norway’s largest public transport operator, Ruter, has said that Chinese-made electric buses in its fleet may be vulnerable to remote access and control by the manufacturer, raising new concerns about cybersecurity in public transport.

> After conducting secret tests, Ruter found that the buses’ software, diagnostics and power systems could be controlled from abroad. Ruter’s CEO Bernt Reitan Jenssen said the findings highlight cybersecurity risks of internet-connected public transport.  

https://tvpworld.com/89824959/ruter-chinese...

lmaoooooooooooo

Kryptos

🔗 Kryptos

Один чувак нашифровал, другие мучаются расшифровывают.



Первую часть расшифровали: BETWEEN SUBTLE SHADING AND THE ABSENCE OF LIGHT LIES THE NUANCE OF IQLUSION

Вторую часть расшифровали: IT WAS TOTALLY INVISIBLE HOWS THAT POSSIBLE ? THEY USED THE EARTHS MAGNETIC FIELD X THE INFORMATION WAS GATHERED AND TRANSMITTED UNDERGRUUND TO AN UNKNOWN LOCATION X DOES LANGLEY KNOW ABOUT THIS ? THEY SHOULD ITS BURIED OUT THERE SOMEWHERE X WHO KNOWS THE EXACT LOCATION ? ONLY WW THIS WAS HIS LAST MESSAGE X THIRTY EIGHT DEGREES FIFTY SEVEN MINUTES SIX POINT FIVE SECONDS NORTH SEVENTY SEVEN DEGREES EIGHT MINUTES FORTY FOUR SECONDS WEST X LAYER TWO

Третью часть расшифровали: SLOWLY DESPARATLY SLOWLY THE REMAINS OF PASSAGE DEBRIS THAT ENCUMBERED THE LOWER PART OF THE DOORWAY WAS REMOVED WITH TREMBLING HANDS I MADE A TINY BREACH IN THE UPPER LEFT HAND CORNER AND THEN WIDENING THE HOLE A LITTLE I INSERTED THE CANDLE AND PEERED IN THE HOT AIR ESCAPING FROM THE CHAMBER CAUSED THE FLAME TO FLICKER BUT PRESENTLY DETAILS OF THE ROOM WITHIN EMERGED FROM THE MIST X CAN YOU SEE ANYTHING Q ?

Над четвёртой частью ломают голову, а пятая даже ещё не показалась.

comments

Что было с Амазоном

🔗 Что было с Амазоном

Summary of the Amazon DynamoDB Service Disruption in Northern Virginia (US-EAST-1) Region

19–20 октября 2025 года в регионе Северная Вирджиния (US-EAST-1) произошел значительный сбой в работе сервисов AWS, вызванный, главным образом, скрытым состоянием гонки в автоматизированной системе управления DNS Amazon DynamoDB. Это привело к сбоям в разрешении DNS для региональной конечной точки DynamoDB, что привело к масштабным последствиям для нескольких сервисов AWS. Событие развивалось в три основных этапа: учащение ошибок API DynamoDB (с 23:48 по тихоокеанскому времени 19 октября до 2:40 по тихоокеанскому времени 20 октября), ошибки подключения к NLB (с 5:30 до 14:09 по тихоокеанскому времени 20 октября) и сбои запуска экземпляров EC2 из-за проблем с подключением (с 2:25 до 13:50 по тихоокеанскому времени 20 октября).

Проблема была связана с архитектурой DNS DynamoDB, которая использует DNS Planner для генерации планов конечных точек и избыточные DNS Enactors (в трёх зонах доступности) для их применения через Amazon Route 53. Редкое состояние гонки возникло, когда один Enactor столкнулся с задержками, позволив другому применить новый план и удалить старый в процессе. Это привело к пустой записи DNS для публичной конечной точки, что привело к блокировке подключений. Восстановление потребовало ручного вмешательства для восстановления DNS к 2:25 утра по тихоокеанскому летнему времени, а полное подключение было восстановлено к 2:40 утра по истечении срока действия кэшей. Глобальные таблицы испытывали задержки репликации, но оставались доступными в других регионах.

В EC2 наблюдались ошибки API, задержки и сбои запуска из-за зависимостей от DynamoDB. Менеджер рабочих процессов дроплетов (DWFM) не смог поддерживать аренду на физических серверах («дроплетах»), что привело к ошибкам, связанным с нехваткой ёмкости. После восстановления DynamoDB DWFM столкнулся с перегрузкой из-за накопившихся данных, что потребовало ограничения пропускной способности и перезапуска. Network Manager столкнулся с задержками распространения сетевых данных для новых экземпляров, которые были устранены к 10:36 PDT. Полное восстановление EC2, включая снятие ограничений пропускной способности, произошло в 13:50 PDT. Существующие экземпляры не пострадали.

В NLB возникали ошибки подключения из-за сбоев проверки работоспособности, усугублявшиеся задержкой распространения сетевых данных для новых экземпляров EC2. Это приводило к чередованию работоспособных и неработоспособных состояний, вызывая ненужные отказоустойчивости AZ и снижение производительности. Инженеры отключили автоматические отказоустойчивости в 9:36 PDT, восстановив работу к 14:09 PDT после стабилизации EC2.

Влияние на другие сервисы:
- Lambda: Ошибки и задержки API до 14:15 PDT, с задержками из-за сбоев опроса SQS и недостаточного масштабирования из-за проблем с NLB/EC2.
- ECS/EKS/Fargate: Сбои запуска и масштабирования контейнеров до 14:20 PDT.
- Amazon Connect: Повышенное количество ошибок вызовов/чатов до 13:20 PDT, с обратным заполнением данных до 28 октября.
- STS: Ошибки API до 09:59 PDT.
- AWS Management Console: Сбои аутентификации до 01:25 PDT.
- Redshift: Ошибки запросов и кластеров до 02:21 PDT, некоторые кластеры недоступны до 21 октября из-за заблокированных замен EC2; проблемы с запросами IAM временно затронули все регионы.
- Другие сервисы, такие как Airflow, Outposts и Support Center, столкнулись с аналогичными сбоями.

AWS извинилась за последствия и предложила решения: отключение/пересмотр автоматизации DNS DynamoDB для устранения состояния гонки; добавление контроля скорости NLB; улучшение тестирования и регулирования EC2; а также текущие проверки для повышения устойчивости и времени восстановления во всех сервисах.

comments

#nokings #humour #politique #gimp