New Thread[×]
Name
Email
Subject
Message
Files Max 5 files10MB total
Tegaki
Password
Captcha*
[New Thread]


image_proxy.jpeg
[Hide] (20.7KB, 474x266)
Grapheneos-Privacy-Terug-for-Google-Pixel-7-PRO-3A-4A-4XL-6-Telfono-Android-Phones-5g-OEM-Customize-Tlphone.webp
[Hide] (4.5KB, 550x550)
Обсуждаем безопасность, приватность, обходы блокировок, всё что около этих тем
2 replies and 1 file omitted. View the full thread
(не реклама)
Удобно отслеживать консервацию Рунета в реальном времени через этот канал: https://t.me/piratepartyru

Надо будет написать его парсер и вывод в удобоворимый RSS, когда делитну телегу.
https://tg.i-c-a.su/ - Всё уже сделано до нас
btw, существует ли сейчас хоть один рабочий инстанс nvidious который не будет с go-away/anubis или (что еще хуже) Cloudflare? Я не хочу включать жаваскрипт
Replies: >>101
3696386615_447818c6cf_h.jpg
[Hide] (712.1KB, 1600x1071)
>>100
Давно таких не видел. Кто-то на пляже тоже про свободные фронтенды спрашивал. А так, я бы свой поднял.
af71de9f96e058369683f31feccf2b575b63b9ee5d862be81f64117964523055.jpg
[Hide] (142.9KB, 750x731)
itch упал. Не работает даже под спец.средствами.

Erroe:524

68747470733a2f2f64336b6f3533337475316f7a66712e636c6f756466726f6e742e6e65742f636c69636b73746172742f65726c616e672e706e67.png
[Hide] (16.5KB, 256x232)
Стоит ли рассматривать более подробно данный ЯП?
10 replies and 3 files omitted. View the full thread
Сама sql-схема прилагается.
CREATE TABLE users (
    id INT AUTO_INCREMENT PRIMARY KEY,
    username VARCHAR(255) UNIQUE NOT NULL,
    password VARCHAR(255) NOT NULL
);

CREATE TABLE messages (
    id INT AUTO_INCREMENT PRIMARY KEY,
    sender_id INT NOT NULL,
    receiver_id INT NOT NULL,
    message TEXT NOT NULL,
    sent_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    FOREIGN KEY (sender_id) REFERENCES users(id),
    FOREIGN KEY (receiver_id) REFERENCES users(id)
Message too long. View the full text
937eff3bd92b0190ca02f9b2e2da0d32806c35e849ebbda073d83ea602c2e6b4.png
[Hide] (741.8KB, 800x599)
Да уж... Давно это было. 
В итоге я написал учебный проект простейшего месседжера в связке с pyQt и забил учить дальше. Как следствие - сдеградировал. Быть может, когда-нибудь, освежу в памяти и продолжу. Сейчас работа накладывает свои ограничения на изучение других ЯП.
Replies: >>92
>>91
>Сейчас работа накладывает свои ограничения на изучение других ЯП.

На чем кодишь?
Replies: >>93
>>92
Текущий проект на работе на питоне. Возможно скоро  какие-то отдельные модули начнем писать на Go
Replies: >>94
>>93

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

новостей тред
24 replies and 4 files omitted. View the full thread
Разработчики дистрибутива Arch Linux объявили о переходе к прямому сотрудничеству с компанией Valve, развивающей операционную систему SteamOS, основанную на Arch Linux. Компания Valve поможет в сопровождении сборочной инфраструктуры и поддержании анклава для заверения компонентов дистрибутива цифровыми подписями. Valve предоставит дополнительные ресурсы, которые позволят развивать отмеченные области, не ограничиваясь свободным временем добровольцев.

Ожидается, что сотрудничество с Valve ускорит решение некоторых актуальных проблем дистрибутива, ускорит разработку и позволит быстрее реализовать задуманные планы. Работа над реализуемыми при участии Valve проектами будет вестись в рамках штатных рабочих процессов, принятых в сообществе Arch Linux, и модели принятия решений на основе достижения консенсуса. Для всех инициируемых при участии Valve значительных изменений будут создаваться RFC, проводиться публичное обсуждение в списке рассылки и осуществляться планирование работ через публикацию заявок (issue) в GitLab, что позволит добиться прозрачности и даст возможность сообществу контролировать ход выполняемой работы. 

---

https://www.opennet.ru/opennews/art.shtml?num=61950
Message too long. View the full text
Вот, как это работало: при отправке письма на портал Zendesk техподдержки компании (например, [email protected]) Zendesk создаёт новый тикет техподдержки. Чтобы отслеживать цепочку писем, Zendesk автоматически генерирует адрес reply-to, который выглядит так: support+id{id}@company.com, где {id} — это уникальный номер тикета. Благодаря этому адресу все будущие ответы будут отправляться напрямую на тот же тикет.

Также у Zendesk есть функция совместной работы над тикетами. Если добавить кого-нибудь в CC в одном из ответов на письмо, то Zendesk автоматически добавляет его к тикету, позволяя ему видеть полную историю тикета на портале техподдержки.

Эксплойт было реализовать легко: если нападающий знает адрес почты техподдержки и ID тикета (который достаточно просто подобрать, потому что ID тикетов увеличиваются инкрементально), он может применить спуфинг почты, чтобы выдать себя за исходного отправителя. Если отправить поддельное письмо на support+id{id}@company.com с почтового адреса пользователя и добавив в CC своё собственное письмо, то Zendesk подумает, что письмо подлинное. Затем он добавит почтовый адрес нападающего к тикету, давая ему полный доступ ко всей истории тикета.

Это значит, что нападающий, по сути, мог присоединиться к любой беседе техподдержки и читать конфиденциальную информацию; и всё это благодаря тому, что Zendesk не обеспечил должной защиты от спуфинга электронной почты.
. . .
В то время я обнаружил пост TICKETTRICK, написанный в 2017 году. В нём исследователь безопасности Инти Де Сёклер подробно описал, как он воспользовался Zendesk для внедрения в приватные рабочие пространства Slack сотен компаний. Так как многие компании использовали Slack SSO на том же домене, что и Zendesk, исследователь догадался, что можно выполнить почтовые верификации через почтовый адрес [email protected] и получить доступ к приватным каналам Slack. В те годы Zendesk ещё не была такой большой и существовали другие баги, позволявшие любому, кто знает ваш адрес почты, просматривать тикеты.
. . .
1. Создаём аккаунт Apple с почтой [email protected] и запрашиваем код верификации. Apple отправляет код верификации с [email protected] на [email protected] и Zendesk автоматически создаёт тикет.

2. В то же самое время создаём тикет на портале техподдержки company.com с моего собственного адреса почты, что позволяет мне отслеживать диапазон значений ID.

3. Используем баг со спуфингом почты, чтобы попытаться добавить себя во все тикеты в рамках определённого выше диапазона.
Message too long. View the full text
Стажер устроил саботаж на рабочем месте и принес проблем на 10 млн. долларов.

•  Программист Кейю Тянь (https://github.com/keyu-tian) устроился стажёром в компанию ByteDance (https://ru.wikipedia.org/wiki/ByteDance) (владеет TikTok) и изнутри два месяца саботировал выполнение проекта по разработке нейросетей, добавляя ошибки в код. Как сообщает BBC, Кейю успел нанести значительный ущерб — внедрял вирусы и изменял ключевые элементы инфраструктуры. Вся команда из 30 разработчиков отчаянно пыталась выяснить, откуда появляются ошибки, пока не стало ясно, что проблема внутри самой компании.

•  Один из самых коварных методов, который использовал стажер, — загрузка специальных Pickle-файлов (https://pythonworld.ru/moduli/modul-pickle.html) со скрытым вредоносным кодом. Этот код активировался случайным образом, что усложняло его обнаружение. Система начала ломаться, проекты зависали, а команда была в растерянности: казалось, что баги возникали из ниоткуда.

•  Кроме того, стажер изменил версию библиотеки PyTorch, (https://ru.wikipedia.org/wiki/PyTorch) на которой строились все проекты команды. Он вносил крохотные изменения каждый день, которые по итогу рушили все разработки. Программы перестали работать стабильно, а эксперименты давали неверные результаты. Разработчики не сразу догадались проверить исходный код, ведь ошибки выглядели настолько рандомными, что их сложно было связать с изменениями в библиотеке.

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

•  Хитрость «шпиона» была в том, что он посещал все командные совещания и следил за тем, как коллеги планируют решать проблемы. В результате, он мог заранее продумывать новые способы саботажа. Команда долгое время не подозревала, что один из своих и был причиной всех неприятностей.

•  Тем не менее, лог-файлы помогли вывести злоумышленника на чистую воду. Как только его действия были выявлены, компания уволила стажера и проинформировала его учебное заведение и отраслевые организации о случившемся. Теперь ByteDance оценивает убытки, которые составляют 10 миллионов долларов. Проект по внедрению ИИ сильно затормозился, а сроки сгорели. 

•  После того, как Тянь исключили из ByteDance, он не подвергся наказанию или порицанию со стороны своих наставников в высшем учебном заведении. Такие вот дела...
Message too long. View the full text
Своим первым постом на площадке я хочу привлечь внимание к катастрофе, сложившейся на данный момент в RU-зоне проекта NTPPool.org. Я думаю, что проект в представлении не нуждается, тем не менее, для тех, кто никогда о нём не слышал - во многом благодаря ему все ваши компьютеры, смартфоны, серверы и прочие гаджеты имеют точное время.

Из описания проекта:

    pool.ntp.org — это огромный кластер серверов точного времени, предоставляющий надежный и простой в использовании NTP‑сервис для миллионов клиентов. В настоящее время услугами пула пользуются десятки миллионов систем по всему миру. Он используется по умолчанию в большинстве дистрибутивов Linux и во многих сетевых устройствах (см. информацию для производителей).

Я являюсь участником проекта довольно давно - лет 5 точно, может быть больше. У меня дома толстый канал 500 Мбит/с, я поднял на домашнем Mikrotik RB4011 NTP-сервер, научил роутер ходить на несколько российских NTP-серверов высшего уровня точности Stratum 1 и добавился в пул на правах Stratum 2. Вкратце о том, что это значит - Stratum это уровень точности времени, чем больше цифра, тем меньше точность (условно). Серверы S1 получают данные о времени напрямую от источников точного времени (атомные часы, GPS, что-нибудь подобное). S2 запрашивает время у S1 и отдаёт его клиентам (серверов S1 на всех не хватает). S3 запрашивает время у S2 и отдаёт своим клиентам, и так далее. По факту для обычной жизни вполне достаточно S3.

На роутере годами висела поднятая служба NTP, которая приносила пользу миру и не мешала жить. Всё изменилось в середине октября, когда в домовой чат стали писать соседи, что шлагбаум, завязанный на мой интернет, стоит открытый (это его стандартное поведение при пропадании связи со шлюзом). Проверив всё у себя и не найдя проблем, я списал на случайность, пока не залез на роутер и не обнаружил 500 Мбит/с и около 500 000 pps входящего трафика, который словно растворялся в роутере (на WAN-интерфейсе дикий IN, но нет никаких сопутствующих OUT). Попинал лобовое стекло, протёр колесо, вышел и вошёл Обновив на роутере прошивку, перезагрузив его и увидев, что проблема не ушла, я полез искать причину и обнаружил, что проблема в службе NTP. Это именно она жрёт на 100% все 4 ядра CPU и всю полосу на приём. Заблокировал фаерволом запросы - и всё сразу же отвисло и заработало. Вскоре мне пришло сообщение от мониторинга NTPPool, что сервер пропал из доступа и исключён из пула (пул непрерывно мониторит серверы на предмет корректности отдаваемого времени и доступности вообще, и присваивает ему рейтинг - от -100 до 20. В пул добавляются серверы с рейтингом больше 10).

В личном кабинете участника проекта есть настроечка Netspeed, она показывает условное количество трафика по отношению к общему объёму твоей зоны, который ты готов принять на себя. У меня Netspeed стоял фактические 500 Mbps, но когда серверов осталось 5 - даже настройка 512 kbps кладёт полностью канал толщиной 500 Mbps.

Я несколько раз пытался открывать краник, в том числе на 512 kbit — мониторинг признавал сервер, добавлял его в пул и домашняя сеть ложилась под нагрузкой. NTP с точки зрения нагрузки мерзкий протокол — много‑много маленьких‑маленьких UDP‑шных пакетиков, попытка шейпить которые фаерволом ни к чему хорошему не приводит и нагрузку не снижает. Единственное, что можно сделать — откинуть.

В процессе изучения проблемы я обнаружил, что что-то случилось в начале-середине октября и из зоны RU за 2 недели вылетело 120 серверов из 140 имеющихся.
Message too long. View the full text
15 октября мы раскатили прошивку на 10% устройств. Поэтапная раскатка обновления — это стандартная практика. Она предназначена в том числе для того, чтобы выявлять проблемы новых версий на ранней стадии. И прежде чем увеличивать процент раскатки, мы отсматриваем метрики всех ключевых пользовательских сценариев. Но число генерируемых нами NTP‑запросов исторически никогда не входило в метрики, требующие валидации, потому что NTP‑клиент годами существовал практически без изменений и не приводил к проблемам.

К 24 октября новая прошивка докатилась до 100% колонок. Опять же, критичные для пользователей сценарии покрыты автоматическим мониторингом. Если что‑то важное ломается, мы получаем уведомление. Но, как вы уже догадались, для NTP‑клиента таких уведомлений настроено не было.
. . .
Жалоб было мало, действующий регламент поддержки не был рассчитан на подобные ситуации, поэтому обращения рассматривали не в самом высоком приоритете. К 20 ноября мы нашли ошибку, внесли исправление в код и начали готовить новый релиз.

В выходные 23–24 ноября ситуация с NTP‑серверами обостряется: доступными остаются лишь четыре сервера. К этому моменту мы уже начали раскатывать релиз с исправлением на 10% устройств.
. . .
В воскресенье мы выпустили хотфикс в виде новой рантайм‑конфигурации для NTP‑клиента, который увеличивал период перезапроса с 5 до 600 секунд, уменьшая нагрузку на серверы в 120 раз. Хотфикс не исправлял проблему полностью, но был единственным быстрым способом снять чрезмерную нагрузку с NTP-серверов.
. . .
мы запланировали выделить ресурсы в общий пул NTP‑серверов. Это займёт некоторое время, потому что наши дата‑центры удалены от основных точек обмена трафиком, а для NTP‑серверов RTT (Round Trip Time) это — ключевой фактор качества. Мы установим и запустим мощности на основных точках обмена трафиком.

Для наших устройств мы заведём именную зону в соответствии с гайдлайнами проекта NTPPool.org для бо́льшей прозрачности. Генерируемый ими трафик будет локализован на наших NTP‑серверах, если мы продолжим полагаться на публичную инфраструктуру проекта.

Ещё мы добавим метрики, связанные с NTP, на этап валидации A/Б‑экспериментов, а также реалтайм‑уведомления о неполадках в этом компоненте. В том числе расширим сценарии мониторинга исходящего и входящего служебного трафика устройства в целом. Также поработаем над каналами коммуникаций и поддержкой, чтобы подобные проблемы быстрее до нас эскалировались.
Message too long. View the full text

ClipboardImage.png
[Hide] (466.9KB, 600x480)
тред про мониторинг разного и разными способами
ClipboardImage.png
[Hide] (704.7KB, 1560x871)
Prometheus Alert Hints

https://habr.com/ru/companies/bercut/articles/761080/
https://archive.is/GK7ga#selection-462.0-462.1
ClipboardImage.png
[Hide] (56.1KB, 657x333)
ClipboardImage.png
[Hide] (295.4KB, 1280x626)
Как-то я пропустил, но тут в сентябре наконец-то выпустили Falco Talon условно стабильной версии.

Falco, если кратко, мониторит системные вызовы, анализирует что происходит и выдаёт предупреждение, если что-то нарушает его правила (делает это не только для Kubernetes, но и хоста).

Раньше, после того как Falco стриггерился на что-то, надо было придумать как на алерт реагировать. Так же Falco не позволял выстроить цепочку событий, которая бы объясняла, как к событию в алерте пришли.

Например, об этом рассказывал @gecube тут
https://youtu.be/uKX8TaLJK6E?t=293

Как это можно применять можно почитать в посте от Sysdig
Optimizing Wireshark in Kubernetes
https://sysdig.com/blog/optimizing-wireshark-in-kubernetes/

Там они рассказали, как дампили трафик с помощью Wireshark, отправляли в Falco, а потом с помощью Falco Talon реагировали на то что происходит.

Message too long. View the full text

ansible — система управления конфигурациями, написанная на языке программирования Python, с использованием декларативного языка разметки для описания конфигураций.

документация:
* https://docs.ansible.com/ansible/latest/index.html
* https://redhat-cop.github.io/automation-good-practices
* https://docs.ansible.com/ansible/2.8/user_guide/playbooks_best_practices.html

полезное:
* https://github.com/sandervanvugt/rhce8-book
* https://github.com/geerlingguy/ansible-for-devops

курсы/видосы:
* Ansible: From Basics to Guru by Sander van Vugt
* Red Hat RHCE 8 (EX294)

Message too long. View the full text
Есть такая контора southbridge. И они недавно запустили бесплатные курсы по ansible. Пошел смотреть и сначала было интересно, потом смешно, а потом уже не смешно.

Например, они говорят:

так делать плохо:
- name: Rpmcheck exclusions file templated
  template:
    src: "{{ base_sb_srv_dir }}/etc/{{ base_fix_rpm_file }}.j2"
    dest: "/{{ base_sb_srv_dir }}/etc/{{ base_fix_rpm_file }}"
    owner: root
    group: root
    mode: "0644"

так хорошо:
- name: Rpmcheck exclusions file templated
Message too long. View the full text
Открыл для себя циклические зависимости в ансибле! Можно смело уходить на выходные.

В общем, если сделать так:

node:
  unit:
    name: node-01
    service: "{{ node.unit.name }}.service"
    path: /etc/systemd/system/
    full: "{{ node.unit.path }}/{{ node.unit.service }}"
  drop-in:
    name: 10-drop-in.conf
    path: "{{ node.unit.path }}/{{ node.unit.name }}.d"
    full: "{{ node.drop-in.path }}/{{ node.drop-in.name }}"

Message too long. View the full text
Вообще все чаще думаю о переходе с ansible на nix/guix. Пора в футуре шагнуть обеими ногами.
как оказалось такой вариант править  непросто

node:
  unit:
    name: node-01
    service: "{{ node.unit.name }}.service"
    path: /etc/systemd/system/
    full: "{{ node.unit.path }}/{{ node.unit.service }}"
  drop-in:
    name: 10-drop-in.conf
    path: "{{ node.unit.path }}/{{ node.unit.name }}.d"
    full: "{{ node.drop-in.path }}/{{ node.drop-in.name }}"

похоже реально в ямле  нужно по минимуму использовать переменные
ClipboardImage.png
[Hide] (503.9KB, 563x648)
Здравствуйте, мои дорогие дети. Ваши сердца полны стремления к знаниям, и вы не желаете терять ни минуты своего времени. Однако, в этом стремлении к скорости, вы регулярно допускаете ошибки, которые в итоге лишь увеличивают затрачиваемое время. Сегодня я хочу поделиться с вами тем, как действовать правильно, чтобы избежать мучительных , как зубная боль, моментов в будущем.

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

Всё началось в момент увеличивающихся вычислительных мощностей. Тогда в голову инженерам пришла мысль: а давайте все автоматизируем! Сказано - сделано. Были написаны скрипты на баше и перле. Но время шло, количество компьютеров увеличивалось, а вместе с ним уменьшался уровень образованности и интереса людей к их работе. В итоге начали появляться системы управления конфигурациями.

И вот вылупились salt, puppet и ansible. С тех пор жизнь системных администраторов кардинально изменилась и уже никогда не вернется к прежнему.

Толковым парням и девчонкам сразу было понятно: вот теперь наделаем кучу ошибок и надо как-то этого избежать. Решением стали тесты на питоне. Одноклеточные существа имитирующие облик и поведение людей просто не заморачивались. Как известно: нет тестов - нет проблем.


Отсутствие тестирования.

Отсутствие тестирования ansible ролей само по себе не так чтобы и плохо. Плохо станет потом. Например, когда не учли какие-то особенности или написали неидемпотентно. Или написали предельно криво и в какой-то счастливый момент нужно внести изменения.

Message too long. View the full text

обсуждаем всякое разное на технические темы
зайду с козырей

https://archive.is/fnXVz

А вот вам несколько историй с другой стороны. Я DevOps инженер с опытом более 15 лет. Когда-то давно начинал как системный администратор. Умею настраивать Linux и сети. Есть несколько сертификатов. Например Red Hat Certified Engineer (RHCE), Red Hat Certified Systems Administrator (RHCSA), AWS Certified Solutions Architect - Associate (SAA). Это для контекста. Можете погуглить RHCE Exam objectives, что бы понять объём области знаний.

Так вот, последние полгода прохожу интервью и пока ни одного оффера.

Собеседовался в один банк - завалил кодинг интервью. Не смог за полчаса распарсить лог веб сервера Apache и найти топ самых часто встречаемых IP адресов.

Ну да, не хватает практики. Зарегистрировался на leetcode и hackerrank. Начал решать задачки регулярно. Подтянул Python.

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


Message too long. View the full text

GNU GUIX (произносится гикс /ɡiːks/) — функциональный пакетный менеджер и операционная система, разработанные Ludovic Courtès. Отличительной особенностью является создание полностью воспроизводимых билдов и декларативное описание. Guix можно поставить на существующий дистрибутив GNU/Linux или в качестве отдельной системы на базе Linux или GNU Hurd. Раньше существовало разделение менеджера пакетов Guix и операционной системы GuixSD.

Определения пакетов описываются на диалекте языка Scheme – GNU/Guile. Большая часть исходников написана на нём же. Система изначально была основана на Nix. Отличиями от Nix(OS) являются язык для описания пакетов и сервисов, система инициализации (GNU Shepherd), использование ядра Linux-Libre (Linux без блобов) и отсутствие проприетарных пакетов.

Чем интересен Guix: https://habr.com/ru/post/436938/

GNU Guix (из коробки) не имеет проприетарного firmware. Потому при переходе на эту систему надо учитывать, что возможно wifi адаптер, gpu и другие компоненты системы могут не работать полностью или частично.

Список свободных wifi адаптеров:
https://gist.github.com/sirikid/2817f36d67d1480a428cbf33b220cfcc

Как завести систему с несвободным железом:
* Канал с несвободными пакетами NonGuix
* Установочный образ с несвободным ядром и firmware
Last edited by Hidden User
Message too long. View the full text
Доступен системный менеджер GNU Shepherd 0.10 (бывший dmd), сочетающий возможности системы инициализации и инструментария для управления системными сервисами. Проект развивается разработчиками дистрибутива GNU Guix System в качестве альтернативы системе инициализации SysV-init, поддерживающей зависимости. Управляющий демон и утилиты Shepherd написаны на языке Guile (одна из реализаций языка Scheme), который также используется для определения настроек и параметров запуска сервисов. Shepherd уже применяется в дистрибутиве GNU Guix System и нацелен также на использование в GNU/Hurd, но может работать в любой POSIX-совместимой ОС, для которой доступен язык Guile.

Shepherd выполняет работу по запуску и остановке сервисов, учитывая взаимосвязь между сервисами, динамически определяя и запуская сервисы, от которых зависит выбранный сервис. Shepherd также поддерживает определение конфликтов между сервисами и предотвращает их одновременное выполнение. Проект может использоваться как в роли основной системы инициализации (init c PID 1), так и в обособленном виде для управления фоновыми процессами отдельных пользователей (например, для запуска tor, privoxy, mcron и т.п.) с выполнением с правами данных пользователей.

Основные новшества:

    * Добавлены новые промежуточные состояния сервисов - "starting" и "stopping", отображаемые при выполнении команды "herd status" и определяющие нахождение сервиса в процессе запуска или остановки (ранее поддерживались только состояния "running" и "stopped").
    * Обеспечена блокировка повторного выполнения операций "start" и "stop", если сервис уже запущен или остановлен (ранее выполнение "herd start SERVICE" приводило к попытке запуска второго экземпляра сервиса).
    * Обеспечено распараллеливание запуска зависимостей и сервисов, запускаемых в режиме "start-in-the-background".
    * Реализован учёт времени сбоев и изменений состояний каждого сервиса. Накопленная статистика показывается при выполнении команды "herd status".
    * Добавлена команда "herd log" для показа сводного лога событий и списка всех изменений состояния сервиса.
    * Добавлена команда "herd graph" для генерации данных, позволяющих при помощи Graphviz ("herd graph | xdot -") отобразить наглядный граф зависимостей.
    * Реализовано цветное подсвечивание вывода команды herd.
    * Добавлены новые сервисы: "monitoring" для отслеживания потребления ресурсов процессом shepherd и "repl" для запуска отладочного интерфейса REPL (read-eval-print loop).
    * Объявлен устаревшим интерфейс GOOPS (Guile’s Object-Oriented Programming System). 
Message too long. View the full text

тред посвящается околинуксовым всяким разным штукам
Last edited by Hidden User
спидран по установке arch

https://youtu.be/8utpbbdj0LQ

После полутора лет разработки опубликован четвёртый бета-выпуск операционной системы Haiku R1. Изначально проект был создан как реакция на закрытие ОС BeOS и развивался под именем OpenBeOS, но был переименован в 2004 году из-за претензий, связанных с использованием в названии торговой марки BeOS. Для оценки работы нового выпуска подготовлено несколько загрузочных Live-образов (x86, x86-64). Исходные тексты большей части ОС Haiku распространяются под свободной лицензией MIT, исключение составляют некоторые библиотеки, медиа-кодеки и компоненты, заимствованные из других проектов.

ОС Haiku ориентирована на персональные компьютеры, использует собственное ядро, построенное на основе модульной архитектуры, оптимизированное для высокой отзывчивости на действия пользователя и эффективного выполнения многопоточных приложений. Для разработчиков представлен объектно-ориентированный API. Система напрямую базируется на технологиях BeOS 5 и нацелена на бинарную совместимость с приложениями для данной ОС. Минимальное требование к оборудованию: CPU Pentium II и 384 МБ ОЗУ (рекомендовано Intel Core i3 и 2 ГБ ОЗУ).

В качестве файловой системы используется OpenBFS, поддерживающая расширенные атрибуты файлов, журналирование, 64-разрядные указатели, поддержку хранения мета-тэгов (для каждого файла можно сохранить атрибуты в форме ключ=значение, что делает ФС похожей на БД) и специальных индексов для ускорения выборки по ним. Для организации структуры директорий используются "B+ tree" деревья. Из кода BeOS в состав Haiku включён файловый менеджер Tracker и панель Deskbar, исходные тексты которых были открыты после ухода BeOS со сцены.

Основные новшества:

    Улучшена работа на экранах с высокой плотностью пикселей (HiDPI). Реализовано корректное масштабирование интерфейса, не ограничивающееся изменением размера шрифтов. При первой загрузке Haiku теперь пытается автоматически определить наличие HiDPI-экрана и выбрать необходимые размеры для масштабирования. Выбранные параметры могут быть изменены в настройках, но для их применения пока требуется перезагрузка. Параметры масштабирования поддерживаются в большинстве родных приложений и в некоторых портированнных, но не во всех.
    Предоставлена возможность использования внешнего вида с плоским декоратором окон и плоским оформлением кнопок, вместо оформления с активным использованием градиентов. Плоское оформление поставляется в пакте Haiku Extras и включается в разделе настроек внешнего вида.
    Добавлена прослойка для обеспечения совместимости с библиотекой Xlib, позволяющая запускать X11-приложения в Haiku без запуска X-сервера. Прослойка реализована через эмуляцию функций Xlib при помощи трансляции вызовов в высокоуровневый графический API Haiku.
    Подготовлена прослойка для обеспечения совместимости с Wayland, позволяющая запускать тулкиты и приложения, использующие данный протокол, в том числе приложения на базе библиотеки GTK. Прослойка предоставляет библиотеку libwayland-client.so, основанную на коде libwayland и совместимую на уровне API и ABI, что позволяет запускать приложения Wayland без изменений. В отличие от типовых композитных серверов Wayland, прослойка не запускается в форме отдельного серверного процесса, а загружается как плагин к клиентским процессам. Вместо сокетов в сервере используется нативный цикл обработки сообщений на основе BLooper.
    Благодаря прослойкам для совместимости с X11 и Wayland удалось подготовить рабочий порт библиотеки GTK3. Из приложений, которые можно запустить при помощи порта отмечены GIMP, Inkscape, Epiphany (GNOME Web), Claws-mail, AbiWord и HandBrake.
    Добавлен рабочий порт с Wine, который можно использовать для запуска Windows-приложений в Haiku. Из ограничений отмечается возможность запуска только в 64-разрядных сборках Haiku и способность выполнения только 64-разрядных приложений Windows.
    Добавлен порт текстового редактора GNU Emacs, работающий в графическом режиме. Пакеты размещены в репозитории HaikuDepot.
Message too long. View the full text

появилось в версии 15.7.0

https://www.youtube.com/watch?v=IrK83nKi8HA

Show Post Actions

Actions:

Captcha:

- feedback - admin - news - rules - faq -
jschan 1.7.3