Apple III: як дизайн погубив початково хорошу ідеюНаприкінці 1978 року розпочалася розробка Apple III під керівництвом Венделла Сандерафа. Ця модель була кардинальною переробкою Apple II, який був під керівництвом Возняка, але розрахований на бізнес. Хоча про технічні складові мало дбали.Під час розробки Джобс наполіг, що ПК повинен бути абсолютно тихим - без вентиляторів, отворів і "потворних" решіток, а зробити тепловідвід по алюмінієвому корпусу. Інженери відкрито попереджали, що все буде дуже нагріватися, але Джобс стояв на своєму.Дуже сильно нагрівалося до такої міри, що мікросхеми самовільно вилазили зі своїх слотів, через що ПК зависав і втрачав дані, перетворюючись на марний шматок металу.Є чутки, що інженери знайшли досить дивний спосіб повернути працездатність - підняти ПК на пару сантиметрів і кинути на стіл, через що мікросхеми ставали на місце. Найсмішніше, що спосіб виявився настільки робочим, що користувачі дуже часто вдавалися до такого способу.Навіть сам Возняк визнав, що Apple III - повний провал, який приносив всього 3% доходу. Він вважав, що значніше було б почати працювати над вдосконаленням Apple II або над розробкою IBM-подібного ПК.
Представлено проєкт OQD зі створення відкритого квантового комп'ютераКвантовий комп'ютер знаходиться на стадії збірки і тестування, а схеми і файли, необхідні для складання аналогічної системи, будуть відкриті відповідно до Open Hardware під ліцензією, близькою до Apache 2.0. Для роботи над проєктом було створено шість груп, що займаються програмним стеком, методами корекції помилок і зниження впливу шумів у квантових системах, розробкою моделей для симуляції, написанням навчальних матеріалів, розробкою ШІ-технологій для оптимізації та генерації квантових алгоритмів, створенням інтерфейсу для віддаленого керування.У квантовому комп'ютері ізоляція іонів іттербію (171Yb+) і барію (138Ba+) відбувається під впливом електромагнітних полів, які переводяться в квантовий стан шляхом охолодження до 0 градусів. Стан іонів змінюється за допомогою лазерних імпульсів, а стан кубіта визначається за інтенсивністю світіння іона під впливом лазерного променя.Всі напрацювання проєкту поширюються на Github: *клік*
Reticulum - криптографичний мережовий стек, призначений для побудови як локальних, так і широких мереж, які можуть працювати в умовах високої затримки та низької пропускної здатності. Він не залежить від IP, та протоколів вищих рівнів. Reticulum забезпечує наскрізне шифрування, анонімність ініціатора, автоматичну багатострибкову маршрутизацію, ефективну адресацію та непідробні підтвердження доставки пакетів. Це дає змогу будувати автономні, самоконфігуровані мережі без централізованого контролю або цензури, використовуючи доступне апаратне забезпечення - від радіомодемів LoRa чи Packet Radio до Wi-Fi і TCP/UDP-тунелів.На відміну від традиційних мережевих протоколів, Reticulum не покладається на фіксовані адреси або ієрархічну інфраструктуру. Адресація базується на криптографічних ідентичностях, а маршрути формуються динамічно, залежно від реальної доступності вузлів. Це робить мережу стійкою до збоїв, втрати окремих сегментів і атак на інфраструктуру.Важливою ідеєю Reticulum є підтримка мереж із поганими умовами - повільних, нестабільних, із великими затримками або періодичними розривами зв’язку. Саме тому стек добре підходить для використання в кризових ситуаціях, децентралізованих спільнотах, автономних поселеннях або там, де доступ до інтернету обмежений чи контролюється. Поверх Reticulum вже існують сервіси - месенджери, файлообмін, та інші.Значним недоліком проекту є те, що основна реалізація написана на Python, що є вкрай небажаним для мережевого стеку
Кнопка-мультитул SysRq: що таке і чим може бути корисноюСпочатку ця кнопка була впроваджена IBM для виклику низькорівневих операцій ОС без ризику конфлікту з існуючими програмами. Якщо поговорити конкретно про UNIX-подібні системи (як Linux), то клавіша SysRq - це єдиний спосіб безпосередньо звʼязатися з ядром, минаючи графічні оболонки, ініт системи (systemd, openrc, тощо) та юзерські процеси. Чим це може бути корисним? Якщо система повністю зависла, то Alt + SysRq + REISUB зможе безпечно перезавантажити систему, або якщо є зависнуті процеси і kill взагалі не допомагає, то Alt + SysRq + I вбʼє всі процеси, окрім ініт системи. (на деяких клавіатурах SysRq знаходиться на кнопці PrtScr). Щоб зрозуміти, чи увімкнена ця кнопка та які команди дозволені, введіть команду cat /proc/sys/kernel/sysrq. Може вивести різні числа, що означають, які функції дозволені (детальніше з описом кожного числа можете ознайомитися тут), але щоб увімкнути весь функціонал кнопки, у /etc/sysctl.d/99-sysrq.conf вставте kernel.sysrq = 1, та після збереження введіть sudo sysctl --system.До речі, SysRq можна визивати через термінал командою: echo <БУКВА> | sudo tee /proc/sysrq-triggerДетальніше ознайомитися з усім переліком існуючих команд можете тут: https://docs.kernel.org/admin-guide/sysrq.html#what-are-the-command-keys
The front 9 fell off [2/2]Це елегантно поєднується з іншою ідеєю Plan 9: протоколом 9P. Усі файлові операції у системі використовують протокол 9P, який визначає такі операції, як читання та запис. Цей протокол мережево прозорий: ви можете монтувати віддалені сервери у свою файлову ієрархію та працювати з їхніми файлами через 9P. На Unix можна зробити щось подібне, але в Plan 9 ця концепція знаходить набагато ширше застосування, бо тут усе дійсно є файлами.Наприклад у вас дома є клієнт, за яким працюєте ви, та окремий сервер. Якщо у вашого клієнта нема аудіовиходу, ви можете замонтувати аудіовихід вашего серверу у вашу файлову систему. Плеєр навіть не знатиме, що він грає музику через мережу.Також треба згадати неймспейси. У plan9 кожний прцоес бачить файлову ієрархію по-своєму. Тому монтування не потребує спеціальних привелегії, як в unix. Користувацькі програми також можуть реалізувати файлові системи, сумісні з тими, які зазвичай реалізуються драйверами ядра, наприклад /net/ether0, і надавати їх процесам у своїх просторах. Наприклад, /dev/draw є аналогом framebuffer-пристрою: ви відкриваєте його, щоб писати пікселі на екран. Віконний менеджер Rio реалізує інтерфейс /dev/draw у користувацькому просторі, а потім монтує його у файлову ієрархію своїх дочірніх процесів. Таким чином, будь-які графічні програми можуть працювати як у звичайному framebuffer, так і у вікні, не знаючи про різницю.Ці ідеї також дозволяють побудувати механізм схожий на контейнери - задовго до появи BSD jails і значно ефективніше реалізований. Згадайте, що в Plan 9 усе - буквально файли. Доступ до обладнання надається через звичайні файли, а пер-процесні namespace не потребують привілегії для зміни монтувань. Створити контейнер дуже просто: відмонтуйте все обладнання, до якого програма не повинна мати доступ. Готово. І не потрібно бути root. Хочете пробросити TCP-порт? Напишіть обмежений варіант /net/tcp, який дає доступ лише до потрібних портів. Усе це можна зробити просто shell-скриптом.Оригінальний Plan 9 від Bell Labs більше не підтримується, але спільнота зберегла його спадщину через кілька форків, серед яких найбільш активним і життєздатним є 9front. У цьому форку розробники серйозно попрацювали над підтримкою сучасного обладнання, а також значно покращили драйвери, інструменти та документацію.Попри всі свої переваги, Plan 9 навряд чи підходить як основна операційна система. Спільнота дуже невелика, сучасного софту практично немає, навіть веббраузера з підтримкою JS не існує. Проте саме ці особливості роблять її однією з найкращих платформ для дослідників: мінімалізм, прозорість архітектури та чистота ідей дозволяють глибоко вивчати принципи взаємодії компонентів ОС і експериментувати з дизайном системного програмного забезпечення на рівні, недосяжному для традиційних Unix-подібних систем.
Пам'ятаєте, як в Ubuntu замінили GNU Coreutils на uutils? uutils призвів до порушення роботи скрипта для перевірки наявності оновлень.Серед іншого, виявився непрацездатним механізм автоматичної установки оновлень з усуненням вразливостей, що застосовується в Ubuntu Desktop і Ubuntu Server, а також в конфігураціях для хмарних систем і контейнерів.Проблема виникла через утиліту date, в якій не була реалізована опція -r, що виводить час зміни заданого файлу. Вказання даної опції в date приймалося парсером, але логіка обробки опції була відсутня, тому замість часу останньої зміни файлу завжди повертався поточний час. Команда date -r використовувалася в скрипті apt.systemd.daily, що запускався щодня, для визначення часу модифікації файлу /var/lib/apt/periodic/upgrade-stamp, який використовувався для обчислення часу останньої інсталяції оновлень. Оскільки виклик date -r не призводив до виведення помилки і повертав поточний час, скрипт завжди вважав, що в системі встановлені найсвіжіші оновлення.Хочу зазначити, що клон date проходить тільки 2 з 8 тестів - це 75% відмов, а деякі інші клони показують ще гірші результати.
Вийшов OpenBSD 7.8 - нові можливості на ARM64, посилена безпека і точність ядра до наносекунд OpenBSD - це UNIX-подібна система, заснована Тео де Раадтом після конфлікту з розробниками з NetBSD. Після того, як йому закрили доступ до репозиторію NetBSD, він зібрався з однодумцями і зробив з вихідного коду NetBSD абсолютно нову ОС, головною метою якої є бути переносимою, стандартизованою і безпечною.У новому релізі було змінено досить багато, тому я зупинюся на найважливішому:- У порту для архітектури ARM64 додано підтримку плат Raspberry Pi 5, реалізовано драйвер acpicpu, забезпечено роботу apm (Advanced Power Management) і sysctl hw.cpuspeed на пристроях з Qualcomm Snapdragon X Elite. - Реалізовано підтримку прапора FD_CLOFORK (close-on-fork) для закриття файлового дескриптора для дочірніх процесів після виклику функції fork(). У порівнянні з іншими реалізаціями, було забезпечено скидання даного прапора після виклику функції exec() з міркувань безпеки та зручності. - Ядро переведено на використання наносекунд замість тиків таймера при виконанні функції sleep(), що дозволяє уникнути втрати точності через перетворення з наносекунд в тики і назад при ініціюванні операцій з бібліотечних функцій в просторі користувача.- Забезпечено попереднє виділення робочої області для сплячого режиму під час завантаження, а також додано можливість використання режиму очікування при підключенні пристроїв через GPIO.- Реалізовано підтримку роботи у віртуальних машинах kvm/qemu при використанні для захисту гостьової системи розширення AMD SEV-ES (Encrypted State).- Підвищена сумісність з файловими системами на базі механізму FUSE (Filesystem in Userspace), в реалізації яких використовується бібліотека libfuse. - Реалізація фреймворка DRM синхронізована з ядром Linux 6.12.50- У драйвер web-камер uvideo додано підтримку кодека H.264.
Після двох місяців розробки Лінус Торвальдс представив реліз Linux 6.17 У нову версію прийнято 14334 виправлень від 2118 розробників, а розмір патча - 46 МБ (зміни торкнулися 12841 файлів, додано 646654 рядків коду, видалено 398782 рядків). У нову версію ядра увійшло дуже багато змін, тому я розповім про найважливіші з них: - У Btrfs додано експериментальну підтримку великих фоліантів сторінок пам'яті, що дозволяють знизити накладні витрати і підвищити продуктивність ФС.- На системах з архітектурою ARM64 реалізована підтримка Live-патчів, що дозволяють застосовувати виправлення у Linux на льоту, без перезавантаження і зупинки системи. - Додана можливість увімкнення захисту від вразливостей у ЦП через вибір векторів атаки, що блокуються, замість вказання в налаштуваннях конкретних вразливостей.- Додано підтримку збірки компілятором Clang з увімкненням режиму відстеження глибини стека, при якому виконується ініціалізація всіх змінних, що зберігаються в стеку.- Додано захист від підміни атакуючим файлової системи /proc через монтування в режимі "bind".- У механізм SCHED_EXT, що дозволяє використовувати BPF для створення планувальників ЦП, додана можливість керування навантаження через cgroup.
П'ятниця, а значить час проєктів від підписників!Для тих, хто не в курсі - щоп'ятниці я ділюся проєктами від підписників. Детальніше тут: https://t.me/linux_ukraine/1487Ніхто не прийшов до мене в ЛС з проєктом, тому зі своїм проектом прийду до вас у стрічку я.🌞—Підписникам привіт!Хочу розповісти про свій маленький, але досить цікавий і прикольний проєкт, який я постійно використовую, суть якого полягає в блокуванні екрану root-паролем для X11-сесій (а може навіть Wayland, треба перевірити). Надихнувся i3lock і slock та вирішив розробити свою версію блокувальника з однієї причини:- i3lock був написаний на xcb, який я терпіти не можу, а у slock (як і у всіх suckless проєктів) дуже брудна кодова база, підтримувати яку дуже незручно.Кодова база TXLock побудована на бібліотеці XLib - для реалізації GUI і взаємодії в оточенні, разом з Shadow і Crypt - для перевірки введеного root-пароля.На даний момент підрахунок IDLE залежить від сторонніх програм (наприклад, xautolock -time 5 -locker txlock), але в найближчому майбутньому я вирішу цю "проблему" додаванням в кодову базу функції підрахунку IDLE. Вага програми близько 17.5 кілобайт, в порівнянні з 19 кілобайт у slock і 51 кілобайт у i3lock.https://github.com/rendick/txlock/
Представлено Multikernel - механізм для одночасного виконання декількох ядер LinuxMultikernel дозволяє на одному фізичному комп'ютері виконувати кілька екземплярів ядра Linux, які мають прямий доступ до апаратних ресурсів і можуть використовуватися для запуску декількох ізольованих системних середовищ.Для запуску та керування ядрами запропоновано вдосконалений виклик kexec, який на відміну від класичного kexec не обмежується заміною працюючого ядра і дозволяє запускати додаткові екземпляри ядра, що виконуються паралельно. Для моніторингу та налагодження запущених екземплярів ядра реалізовано інтерфейс /proc/multikernel, а для обміну повідомленнями між ядрами та координації роботи запропоновано фреймворк Multikernel IPI.З основних переваг Multikernel можу відмітити:- Покращену ізоляцію від збоїв під час роботи.- Підвищену безпеку за рахунок поділу на рівні ядра.- Більш ефективне використання ресурсів у порівнянні з традиційними віртуальними машинами на базі гіпервізорів, таких як KVM і Xen.- Потенційна можливість оновлення ядра без зупинки роботи при використанні механізму Kernel Hand Over.- Підтримка інтеграції зі стандартними хмарними інфраструктурами і можливість прозорого переходу з традиційних систем віртуалізації і контейнерної ізоляції.- Повна сумісність з існуючими програмами і системними інтерфейсами Linux. Multikernel лише частково змінює ядро, зберігаючи повну сумісність на рівні API.
TGLIST.COM.UA
