Russian fedora, russian fedora
Триває історія заміни штатного і порядком застарілого сервісу D-Bus. Після того, як не злетів проект kdbus. а перспективи bus1 по включенню в ядро і не проглядаються. було прийнято рішення переписати наявний демон.
Чому знадобилося переписувати начисто, замість патчів до старої версії, якої, до речі, більше 15 років, і як то адже воно працює. Тому що, при всій повазі до розробників першої реалізації, вона була спроектована не дуже добре. Цьому є пояснення - було складно побачити загальну схему взаємодії додатків в той час. Тому архітектура вийшла гродомздкой, реалізація вийшла неквапливої, а неминуча складність привела до дедалі більшого горе помилок. деяким з яких вже по 7 років. Багрепорти варіюються, як вказує David, від помилок звернення до пам'яті, до мовчазної втрати повідомлень і спричинених недоліками архітектури Дедлоков. Вирішити деякі з цих проблем можна, але результат не буде відповідати технічним завданням.
Тому було вирішено переписати брокер повідомлень заново, внісши ряд важливих архітектурних змін:
- Замість концепції загальної шини даних, була реалізована концепція окремих вузлів, які незалежно один від одного спілкуються.
- Демон не використовує мережу або інші IPC. Раніше це викликало Дедлок, наприклад, коли користувачі заведені в LDAP або NIS.
- Всі ресурси враховуються не по окремих вузлах, а по користувачах, що ініціювали з'єднання.
- Про кожну помилку тепер буде повідомлятися. Якщо повідомити користувача неможливо, то демон буде завершувати роботу аварійно.
В результаті вийшов досить простий локальний брокер повідомлень (не працює по мережі, інший шині, або через libastral), який використовує тільки самі останній Linux-технології, працює повністю в просторі користувача, і який досить добре сумісний з попередньою референсной реалізацією. Колеги-аналітики вже анонімно обговорюють побачене на Linux.org.ru і OpenNET.ru.
Поки незрозуміло, яке майбутнє у bus1. якщо реалізація шини в userspace буде успішно працювати.
Традиційно вітаємо учнів з початком навчального року! Нагадаємо їм, що в рамках нашого проекту є варіанти дистрибутива, спеціально призначені для використання в наукових і навчальних цілях.
Вийшов Qemu 2.10. З хороших новин - повернули NetBSD в список підтримуваних (нагадаємо, її видалили в минулому випуску).
/. Але як же її використовують в Facebook. Ну по-перше порівняйте сценарії - накриється в FB файлова система, так цілий комп перевстановити з нуля, засінхронізіруют дані, і готово! А ви що робити будете? Ну і по-друге, якщо впаде щось чуже назавжди, то ви сильно станете шкодувати? Ото ж бо ж. А своє шкода.
Ситуацію з нестабільністю Btrfs ускладнювало те, що кожен раз розробники обіцяли, що воно ось-ось буде готово. Чи не готове до сих пір, і бекпортіровать швидко рухому ціль на стабільні ядра теж задоволення мало. Найцікавіше, це те, навіщо возитися з Btrfs, коли всі її фичи (підкреслимо, взагалі все) доступні в інших утиліти або компонентах ядра. Вже є управління томами і розділами, є надійна журнальована файлова система (XFS), є дедуплікація, thin provisioning, шифрування, створення снапшотов - потрібно тільки правильно, по-юніксвейному все організувати.
Створивши список необхідного функціоналу, наші колеги запропонували Stratis. написаний на Rust і Python фреймворк, який використовує device-mapper і XFS. Якщо все піде добре, то перша версія буде доступна вже в Fedora 28. Якщо ж все піде зовсім добре, то до версії 3 планується повністю реалізувати функціонал ZFS.
Відповімо на напрошується питання - що щодо ZFS? На жаль немає. Ця FS, мабуть, ніколи не буде запропонована для включення в Linux.
Ще одне питання - що буде з Btrfs в Fedora? Вона там буде доступна. Бекпортіровать в Fedora нічого не потрібно, і тому там ситуація набагато простіше. Користуйтеся на здоров'я, але не забувайте бекапіть, тому що вона напевно впаде.
Взагалі, нагадаю, файлові системи незабаром сильно зміняться. тому змінюється сам носій, на який записуються дані. І такі ФС починають з'являтися! Наприклад, недавно була анонсована така ФС - NOVA (новина вже обговорюють на OpenNET.ru).
Інтуїтивно зрозумілий інтерфейс GNOME завжди привертав користувачів
Відбувся запуск черговий системи з RHEL!
На цей раз, це в буквальному сенсі запуск - розроблена компанією Ілона Маска ракета Falcon 9 з кораблем Dragon полетіла до МКС. На борту, серед іншого вантажу, буде високопродуктивний комп'ютер Apollo 40. розроблений Hewlett Packard і працює під управлінням немодифікованої версії RHEL.
Комп'ютер сам по собі буде частиною експерименту з перевірки застосовності штатної, неспеціалізованої техніки в космосі. Якщо все піде добре, то замість коррупціонногенних закупівель комплектуючих для вояччини і космосу, можна буде використовувати штатні компоненти з радіоринку, а надійність забезпечувати програмно, за допомогою хмарних систем. Зрозуміло, що це серйозно здешевить начинку космічної техніки.
Bastien Nocera в своєму блозі оголосив про нововведеніяx в Evince, чергова версія якого буде доступна в складі GNOME 3.26:
- Перехід на libarchive для відкриття форматів CBT, CBZ, CB7.
- Використання бібліотеки libarr для відкриття файлів CBR (буде доступно і в Fedora 26)
- Файли Adobe Illustrator (розширення ai)
На жаль, щоб запустити на пропрієтарних драйверах NVIDIA Wayland-композитори потрібно патчить. що досить трудомістким. Зрозуміло, що який-небудь Weston поправити відносно легко, але скажімо відразу - хто їм всерйоз користується? А ось допрацьовувати Kwin і Mutter, це зовсім інша історія.
Розуміючи все це, інженер NVIDIA, Miguel A. Vico. створив copr-репозиторій для користувачів Fedora з пропрієтарними драйверами NVIDIA. У цьому репозиторії він виклав Mutter, зібраний c EGLStream. Тепер користувачі GNOME можуть спробувати Wayland в такий химерної конфігурації.
- Ми збираємо і підтримуємо пакети в рамках Fedora. Це наші п'ять копійок в розвиток відкритих технологій.
- Ми переводимо дистрибутив на українську мову, збираємо документацію до нього, організуємо заходи. Це наш внесок в те, щоб Fedora стала ближче для російськомовних користувачів.
- Ми допомагаємо включитися в світові відкриті проекти тим, хто хоче рости і бути на передньому краю розробки. Це непросто, але воно коштує витрачених зусиль.
Сайт підтримується українською спільнотою Fedora, Red Hat не несе відповідальності за його вміст.
Подяки | Правові положення Fedora | Торгові марки Fedora
Хостинг для проекту надано компанією FastVPS