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


новостей тред
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

68747470733a2f2f64336b6f3533337475316f7a66712e636c6f756466726f6e742e6e65742f636c69636b73746172742f65726c616e672e706e67.png
[Hide] (16.5KB, 256x232)
Стоит ли рассматривать более подробно данный ЯП?
6 replies and 2 files omitted. View the full thread
Генераторы: двоичные и списка. Имеют структуру
NewList = [Выражение || Генератор1, Генератор2,..., ГенераторN. Условие1, Условие2,..., УсловиеM]

language: erlang
% общий вид двоичного генератора в литературе, которую я читаю, не приводится. Поэтому напишу здесь усреднённый вид генератора, чтобы понимать потом.
[X || <<X>> <= <<1, 2, 3, 4, 5>>, X rem 2 == 0].
ClipboardImage.png
[Hide] (41.4KB, 583x418)
Продолжаем.
Это код простого udp-сокета. Решил немного уйти дальше просто посмотреть. Очень доставил встроенная бесконечная функция loop.
Replies: >>56
>>55
Расширенный код сокета. Объединён с tcp-сокетом в один файл. Оба сокета запускаются параллельно.

-module(socket_server).
-export([start/0]).

start() ->
    TcpPort = 1337,
    UdpPort = 1488,
    TcpOptions = [{active, false}, {reuseaddr, true}],
    UdpOptions = [{active, false}, {reuseaddr, true}],
    {ok, TcpSocket} = gen_tcp:listen(TcpPort, TcpOptions),
    {ok, UdpSocket} = gen_udp:open(UdpPort, UdpOptions),
    io:format("TCP server started and listening on port ~w~n", [TcpPort]),
    io:format("UDP server started and listening on port ~w~n", [UdpPort]),
Message too long. View the full text
Replies: >>57
>>56
В будущем применимый для этого сокет-сервера модуль с использованием mysql

-module(db).
-export([connect/0, insert_user/2, insert_log/3]).

connect() ->
    mysql:start_link([{host, "localhost"}, {user, "root"}, {password, "password"}, {database, "chatgpt_db"}]).

insert_user(Username, Password) ->
    mysql:query(mysql:prepare(<<"INSERT INTO users (username, password) VALUES (?, ?)">>, [Username, Password])).

insert_log(FromUser, ToUser, Message) ->
    mysql:query(mysql:prepare(<<"INSERT INTO message_logs (from_user, to_user, message) VALUES (?, ?, ?)">>, [FromUser, ToUser, Message])).

Message too long. View the full text
Сама 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

тред посвящается околинуксовым всяким разным штукам
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

We are pleased to announce the release of GNU Guix version 1.4.0!

The release comes with ISO-9660 installation images, a virtual machine image, and with tarballs to install the package manager on top of your GNU/Linux distro, either from source or from binaries—check out the download page. Guix users can update by running guix pull.

It’s been 18 months since the previous release. That’s a lot of time, reflecting both the fact that, as a rolling release, users continuously get new features and update by running guix pull; but let’s face it, it also shows an area where we could and should collectively improve our processes. During that time, Guix received about 29,000 commits by 453 people, which includes important new features as we’ll see; the project also changed maintainers, structured cooperation as teams, and celebrated its ten-year anniversary!

A happy frog sitting at a Guix-powered computer with an almighty benevolent Guix humanoid in its back.

    Illustration by Luis Felipe, published under CC-BY-SA 4.0.

This post provides highlights for all the hard work that went into this release—and yes, these are probably the longest release notes in Guix’s history, so make yourself comfortable, relax, and enjoy.

    Bonus! Here’s a chiptune (by Trevor Lentz, under CC-BY-SA 3.0) our illustrator Luis Felipe recommends that you listen to before going further.

Improved software environment management
Message too long. View the full text

Show Post Actions

Actions:

Captcha:

- feedback - news - rules - faq -
jschan 1.6.2