fictionup — конвертер из формата Markdown в формат FB2, который работает из командной строки. Он поддерживает ограниченный набор тэгов, описывающих метаинформацию, необходимую для создания корректных FB2-документов.

Изменения в новой версии:

• добавлена поддержка мета-тэга «Series:» («Серия:»), который позволяет указывать, к какой серии относится книга;
• добавлена возможность использовать разметку Markdown в аннотации, а не только в тексте самого документа;
• добавлена возможность упаковки результирующего документа в формат fb2.zip (ключ командной строки -z).

Лицензия — GPL 3+.

Примеры исходного (Markdown) и конвертированного (FB2) документов.

>>> Сайт программы

Ни с хера сегодня утром поотваливались все дополнения в Firefox. При том, что Firefox не обновлялся (версия 66.0.3). Выглядит вот так: https://pp.userapi.com/c845218/v845218563/1fb3a1/lTh1ewM3IGE.jpg Ссылки ведут на несуществующую страницу на сайте поддержки Mozilla. Что это за херь???

Способ решения проблемы №1: https://forum.mozilla-russia.org/viewtopic.php?pid=769320#p769320

Способ решения проблемы №2 (работает до перезапуска браузера): https://www.reddit.com/r/firefox/comments/bkfy5k/as_of_1200_am_utc_nearly_all...

Ну вот к примеру есть Corange под BSD, я делаю форк и переименовываю проект к примеру в LALALA делаю кучу правок так что к примеру 80% кода переписано. Ну то есть, не просто форк, а отдельный проект.

Естественно я всегда буду прилагать лицензионный файл в том или ином виде с указанием авторских прав оригинального кода и условий лицензии BSD. Но тут как бы вопросы.

Каков как бы сказать этикет на это всё?

• Стоит ли вписывать себя в текст лицензии? Или её вообще никак нельзя трогать? (этически)
• Если не стоит то как указывать что все изменения мои (ну вдруг мой код говно и автору оригинала не надо что бы думали что он ЭТО написал) отдельный файл лицензии где разница лишь в строке Copyright (c) и указание на то что изменения основаны на таком то коде?
• Всегда ли явно указывать что это форк и ссылаться на оригинальное имя проекта?
• Как поступать если распространение проприетарное? И часть кода под BSD, а изменения под иной EULA лицензией?

Ну собственно к примеру есть библиотека LALALA лежит в гите вместе с ней прилагается лицензионный файл с указанием что мол вот авторские права на Corange. А от Corange там не то что названия кода осталось мало, но он есть. Надо ли где то описывать явно что LALALA основана на Corange.

Короче как всё это делать, есть проект, он переименован, он на половину переписан, он будет выложен. Если ничего не трогать то получится что я никаких изменений и не вносил. Если вписывать себя в Copyright то как то неоднозначно.

Мне вроде как вообще пофиг, но если честно когда говорю мол вот я пилю двиг LALALA, и надоело каждый раз делать приписку присказку что это форк и что оригинал именуется Corange чтобы не ставить всё так как будто это чисто мой проект. Вот тоже самое с лицензией. Как всё это принято делать?

Вот проприетарщикам просто, достаточно сказать вот мол мой проект, а вот одна из лицензий что в проекте используется вот такая то либа. Ну, а что эта либа может составлять 99,9999% всего проекта не ваше дело там моя строчка под EULA и всё тут.

1. Есть несколько книг на выбор. Нужно определить какую книгу стоит прочитать первой, а какие позже. Главные критерии для упорядочивания: «фундаментальность» касательно ООП, практичность и доступность (грамотность) в изложении материала.

Вот список:

1. Философия Java // Б.Эккель
2. ЯП C++ // Б.Страуструп
3. ООП с ANSI-C // А.Шрайнер
4. Типы в ЯП // Б.Пирс

2. Посоветуйте лучший, по вашему мнению, учебный материал по паттернам проектирования (статьи, книги, видео, что угодно).

Вышла первая стабильная версия встраиваемого фреймворка (движка) перехвата функций для ядра Linux — KHOOK v1.0

Особенностью данного ПО является то, что перехват осуществляется путём модификации (патчинга) пролога функции, сохраняя возможность вызова оригинальной функции, и не зависит от наличия в целевом ядре такого механизма как kprobes.

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

( читать дальше... )

>>> Подробности

По следам вот этого: http://www.opennet.ru/opennews/art.shtml?num=49969

Я вот жтот трешак в разработке systemd наблюдал с самого начала его существования, когда еще в первый раз говнище с journald повылазило в первый раз. Когда они недвусмыссленно дали понять, что systemd для RedHat, доводить под других они не будут, под embedded делать они не будут, о ресурсах думать они не будут, так как RedHat не даст на это денег. Вот почему внезапно вылезает все именно на таком, хотя во все предыдущие разы все утёрлись и пошли дальше? Ведь такое отношение было всегда. Почему именно сейчас? Главный спонсор забыл заплатить?

Если взять мощную рабочую станцию и накатить на неё Linux From Scratch без пакетника.

Насколько потом трудозатратно будет поддерживать такую систему? Софт предполагается ставить в духе ./configure --prefix $HOME/package --with-libdir=$HOME/library; make; make install

Обновлять систему по нужде, а не ради обновлений.

Хочу сделать шаблон (в LaTeX и/или в другой системе, не суть) для оформления документов высокой степени объема и сложности: таблицы и рисунки с подписями (в том числе подписи могут быть очень большими, на страницу и даже больше), библиография, cross-reference, плашки, рамки, цитаты.

Могут ли мне в этом вопросе помочь ГОСТы, либо такие шаблоны придумываются каждый раз заново, то есть индивидуально?

Вопрос адресован людям из научного мира, в том числе (из тех кого я знаю здесь), Evgueni, eugeno, ptarh.

Я сам никогда с ГОСТами (либо ISO-стандартами) не работал; просто знаю что есть такие вещи. Поэтому для меня, как для полнейшего дурачка в этих делах, вопрос звучит вообще примерно так: «Елы-палы, а может есть такой волшебный универсальный стандарт, ну то есть шаблон оформления документации, куда засунешь любой текст, сколь угодно сложный, на тыщу страниц, со сложной структурой итд, и этот текст автоматически становится удобным для прочтения».

Это как бы первая часть вопроса. Теперь вторая.

Вот вы сами, когда пишете большие сложные документы, их как оформляете? Вот используя какой-то такой «волшебный ГОСТ» или у вас свой велосипед? И почему вы выбрали именно тот путь, а не этот?

Zmicier предложил привести пример заимствования кода одним открытым проектом из другого открытого проекта, причём в одном из них код GPLнут. Вот сейчас наткнулся на эпический пример надевания GPL на crc32, crc32c (VirtualBox) <-> crc32c.c (NetBSD), crc64, реализация которых, мне кажется, достойна ни то что BSD, а является уже общественным достоянием (public domain). Там у виртуалбокса и дальше идёт подобный код в common: https://www.virtualbox.org/svn/vbox/trunk/src/VBox/Runtime/common/ Вот нужно было называть не public domain, а common code in public domain. Тогда было бы ещё очевидней.

Хотя бы в crc32.c Оракл признаётся, что код основан на:

 * This code is based on:
 *
 *  CRC32 code derived from work by Gary S. Brown.
 *
 *  COPYRIGHT (C) 1986 Gary S. Brown.  You may use this program, or
 *  code or tables extracted from it, as desired without restriction.

Ещё пример: вы ищете в вашем коде расширение файла, но ваш код не GPL? Тогда Оракл придёт к вам:

/* $Id$ */
/** @file
 * IPRT - RTPathExt
 */

/*
 * Copyright (C) 2006-2016 Oracle Corporation
 *
 * This file is part of VirtualBox Open Source Edition (OSE), as
 * available from http://www.virtualbox.org. This file is free software;
 * you can redistribute it and/or modify it under the terms of the GNU
 * General Public License (GPL) as published by the Free Software
 * Foundation, in version 2 as it comes in the "COPYING" file of the
 * VirtualBox OSE distribution. VirtualBox OSE is distributed in the
 * hope that it will be useful, but WITHOUT ANY WARRANTY of any kind.
 *
 * The contents of this file may alternatively be used under the terms
 * of the Common Development and Distribution License Version 1.0
 * (CDDL) only, as it comes in the "COPYING.CDDL" file of the
 * VirtualBox OSE distribution, in which case the provisions of the
 * CDDL are applicable instead of those of the GPL.
 *
 * You may elect to license modified versions of this file under the
 * terms and conditions of either the GPL or the CDDL or both.
 */


/*********************************************************************************************************************************
*   Header Files                                                                                                                 *
*********************************************************************************************************************************/
#include "internal/iprt.h"
#include <iprt/path.h>


RTDECL(char *) RTPathSuffix(const char *pszPath)
{
    const char *psz = pszPath;
    const char *pszExt = NULL;

    for (;; psz++)
    {
        switch (*psz)
        {
            /* handle separators. */
#if defined(RT_OS_WINDOWS) || defined(RT_OS_OS2)
            case ':':
                pszExt = NULL;
                break;

            case '\\':
#endif
            case '/':
                pszExt = NULL;
                break;
            case '.':
                pszExt = psz;
                break;

            /* the end */
            case '\0':
                if (pszExt && pszExt != pszPath && pszExt[1])
                    return (char *)(void *)pszExt;
                return NULL;
        }
    }

    /* not reached */
}

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

Перемещено tailgunner из development

Второй раз за месяц расслабил булки и не заметил утечку оперативной памяти. Система наглухо зависла, сожрав все 16 гб (свапа нет). В консоль не пустили. В последнем эпизоде виноват был Picard, который на обработке коллекции Вивальди сходит с ума и может жрать всю память в одно рыло. У меня только один вопрос, почему OOM Killer не сработал и не прибил эту заразу, если размер виртуальной памяти является основным триггером для него? И что нужно сделать, чтобы убивать подобную жирноту автоматом?

День второй. Поставил zram на половину памяти, vm.oom_kill_allocating_task=1, swappiness=100. Пикард на коллекции Бетховена ставит систему раком. Память жмется хорошо, но киллер не приходит.

День третий. Добавил дисковый свап 2 гб на ssd. Повторил эксперимент. Отзывчивость системы была нормальной даже когда кончился zram и начал заполняться ssd swap, но когда и он кончился, системе закономерно пришел песец. То есть опять песец пришел, а киллер не пришел.

http://www.opennet.ru/tips/2999_iptables_block_tor.shtml

Всем ГУРУ линукса, Доброго дня Вам! :)

Я всю жизнь жил в WINDOWS, последние лет 7 в 7 )))

На прошлой неделе поставил Debian, актуальная версия с сайта.

уже узнал что такое терминал, как установить qemu-kvm, virt-manager и прочее что писали в разных статьях...

В общем я удачно смог запустить виртуальную машину через virt-manager и пробросить через «Add Device» оба устройства. Система на ВМ на момент проброса уже была установлена, гостевая винда увидела новое устройство, аудио стало сразу, на gpu скачал драйвера, все встало но после перезагрузки ВМ - синий экран...

Соответственно в проце есть своя vga, которую я использую на хосте, а pci карту пробрасываю в ВМ. Соответственно grub и bios настроены, аппаратная виртуализация в целом работает. У меня: Intel core i7 4x3.6GGz GT, Asus Strix GTX 970

Подумал, что проблема в самой настройке ВМ. На форумах узнал что NVidia на уровне драйверов блокирует запуск на kvm, если видит данный параметр.

После чего нашел отличную статью с бенчмарком: http://www.fassen.net/video/v1cFWrKtWis/ Там все вроде понятно написано, но я не понимаю как эти параметры воткнуть в конфигурацию ВМ?

Я уже изучил virt-inst, но застрял на том, что нет каталога vfio-pci, да и вообще vfio терминал не понимает, а там надо объединить графику и звук, видимо, это описано много где, например здесь: https://wiki.debian.org/VGAPassthrough

Далее куда надо прописать параметры, которые указаны для запуска?

DEVICE1="03:00.0" ( The GTX970 address in my system )
DEVICE2="03:00.1"

./vfio-bind 0000:$DEVICE1 0000:$DEVICE2

QEMU_PA_SAMPLES=6144 QEMU_AUDIO_DRV=pa \
qemu-system-x86_64 -enable-kvm -m 8192 -cpu host,kvm=off \
-smp 4,sockets=1,cores=4,threads=1 \
-machine q35,accel=kvm \
-soundhw hda \
-device ioh3420,bus=pcie.0,addr=1c.0,multifunction=on,port=1,chassis=1,id=root.1 \
-device vfio-pci,host=$DEVICE1,bus=root.1,addr=00.0,multifunction=on,x-vga=on \
-device vfio-pci,host=$DEVICE2,bus=root.1,addr=00.1 \
-vga none \
-bios /usr/share/seabios/bios.bin \
-device virtio-net-pci,netdev=user.0,mac=52:54:00:03:02:01 \
-netdev user,id=user.0 \
-drive file=win7-x64_system.qcow2,if=none,id=drive-virtio-disk0,format=qcow2 \
-device virtio-blk-pci,scsi=off,addr=0x7,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 \
-drive file=win7-games.qcow2,if=none,id=drive-virtio-disk1,format=qcow2 \
-device virtio-blk-pci,scsi=off,addr=0x8,drive=drive-virtio-disk1,id=virtio-disk1 \
-rtc base=localtime,driftfix=slew \
-device qxl \
-device usb-kbd \
-usbdevice host:1e7d:2d51 (USB Mouse)

В общем я понимаю, что у меня есть грамотные куски информации, но в силу моей зелености в Linux'ах, мне не хватает опыта, чтобы свести эту информацию воедино. Я посмотрел конфиги xml виртмашины, которую создал virt-manager, но не могу найти инструкции, как его править, все статьи создают машины только через команды.

Люди добрые, подскажите, по шагам, как мне сделать ВМ с пробросом моей карты?

Может где есть полная статья под debian, от того какие компоненты и как надо установить, до того, как запустить ВМ с аналогичными командами (Куда их прописать?), тогда я подставлю эти команды с поправкой на адреса моей карты и вуаля?...

В общем я пытался найти всю информацию сам, но понял, что без помощи я здесь не разберусь :)

Эта статья является переводом статьи из блога главного разработчика композитного менеджера KWin (используется в KDE) Мартина Гресслина. Оригинал вы можете прочесть по ссылке. Далее идёт повествование от автора. Прошу сильно не пинать за качество перевода.

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

Ситуация с X11

В X11 главная проблема для игр, это композитор. Играм необходим прямой доступ к графическому процессору (видеокарте), без каких либо посредников. Для сравнения, возьмём игровую консоль Playstation: когда вы запускаете игру, вы можете быть уверены, что она получила полный доступ к графическому процессору (GPU). Композитинг X11 предоставить такого не может. Композитор в X11 должен полностью скомпоновать сцену. Выглядит это так:

• Игра рендерится через OpenGL/GLX;
  
• X-сервер уведомляет композитор через расширение Xdamage;
  
• Композитор рассчитывает область для перерисовки;
  
• Композитор использует расширение Xcomposite для получения пиксельной карты для игрового окна;
  
• Композитор связывает пиксельную карту с текстурой OpenGL;
  
• Композитор рендерит текстуру, используя OpenGL/GLX поверх игрового окна;
  
• X-сервер предоставляет готовое изображение из композитора через KMS.

При таком раскладе, мы имеем 5 вещей, которые не оптимальны для полноэкранных игр: проходы туда-сюда через композитор X-сервера, что добавляет серьёзные задержки. В такой ситуации, композитор всегда будет замедлять игру, так как будет выполнять вертикальную синхронизацию и так далее.

Обходные пути в X11

Существует готовое решение чтобы исправить это, известное как «unredirection full-screen window (отключить перенаправление для полноэкранных окон)». Идея заключается в том, что композитор не будет работать для полноэкранного приложения, и будет использована обычная, «не композитная» функциональность X-сервера.

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

В KWin/Plasma, у нас есть лучшее решение: блокировка композитора. Мы можем это сделать, так как не требуем композитинга, в отличии от окружений с обязательным композитингом, где можно использовать только unredirection. У нас даже есть высокоуровневый API для игр, для того чтобы они могли сообщать, что необходимо заблокировать композитинг.

Это также объясняет, почему в KWin/Plasma не включена по умолчанию опция отключения полноэкранного композитинга. Это может вызвать проблемы в работе неигровых приложений (например тиринг в видеоплеере. прим.перев.), но рекомендуется для игр. Также это объясняет почему мне пофиг на тесты PTS (Phoronix Test Suite), так как по моему мнению они проводятся с неправильными настройками. Если бы нас это волновало, то можно было бы просто убедиться, что используемые в PTS игры, отключают композитинг.

Ситуация с Wayland.

В Wayland всё гораздо лучше, так как теперь нет X11-прослоек. Теперь процесс выглядит так:

• Игра рендерится через OpenGL/EGL;
  
• Композитор получает уведомление через wl_surface;
  
• Композитор напрямую представляет wl_buffer через KMS, так как знает что тут больше не на что смотреть.

Так что ситуация значительно улучшилась. Хочу отметить, что KWin пока не поддерживает эти этапы и всё ещё рендерит через OpenGL, но мы движемся в этом направлении.

Однако, я думаю, ещё есть проблемы. Наш композитор (KWin) по-прежнему получает события от других окон, может «проснуться» и так далее. Запуск игры в режиме рабочего стола означает, что будут другие процессы в системе, с которыми игра должна разделить ресурсы. Мы хотим пойти по примеру Playstation: игре всё, остальным - ничего. Я не хочу чтобы KWin отбирал ресурсы CPU/GPU у игры.

Управление видеорежимами в ядре (Kernel Mode-Setting, KMS) в играх.

Итак, что мы можем сделать? Я думал об этом и предлагаю кардинально решить проблему с играми в Linux: убрать оконную систему! Игры должны общаться с KMS напрямую, игры должны взаимодействовать с libinput (библиотека ввода, прим. перев.) напрямую. Давайте удалим все лишние прослойки, нам это не нужно, это только мешает игровой производительности.

Когда игра запустится в полноэкранном режиме, можно создать отдельную сессию на другом виртуальном терминале (tty) и предоставить управление этой сессией через logind. Это позволит игре открыть файлы для рендеринга и обработки ввода также, как это делает композитор Wayland. Рендеринг может быть осуществлён через EGL поверх DRM/GBM, также как в композиторе Wayland. Игра получит полный контроль над KMS. Нужно другое разрешение экрана? Без проблем, бери и выставляй. В режиме рабочего стола, это всегда проблематично (гораздо хуже в X11, но лучше в Wayland). Для игр в оконном режиме ничего не изменится, они так и будут запускаться в режиме рабочего стола. (Прим.перев. По сути автор предлагает давно известную концепцию «запуска в отдельных иксах», но лишённую кучи недостатков).

Конечно, это должно убрать все взаимодействия с окружением рабочего стола. Это то, что нужно рассматривать в первую очередь, например, как заставить, скажем, Mumble (программа для аудиоконференций, прим. перев.) работать с такой конфигурацией? Может игре нужно запускать собственный Wayland-сервер?

Это также сломает Alt+Tab (сворачивание игры, прим.перев.). Ну, не совсем, правда. Для X11, который захватывает клавиатуру в некоторых играх, Alt+Tab всё равно не работает, так что тут особо ничего не потеряешь. Но конечно, всегда можно будет переключиться через Ctrl+Alt+F1 в рабочую сессию. Игры также должны иметь общий путь для достижения этой цели, на мой взгляд.

Есть конечно ещё несколько вещей, которые ещё предстоит решить, например, как запустить отдельную сессию, как вернуться в рабочую сессию без необходимости разблокировать экран и т.д. Всё должно быть также хорошо, как на игровой консоли. Так что тут ещё есть над чем поработать, но я думаю, это лучше, чем пытаться заставлять хорошо работать игры в режиме рабочего стола, потому как это всё равно не будет работать лучше, чем на игровой консоли.