LINUX.ORG.RU

Избранные сообщения tim239

Humble Book Bundle: Linux Geek by No Starch Press

Новости — Документация
Группа Документация

На HIB в рамках сотрудничества с издательством No Starch Press предлагается купить набор DRM-free электронных книг, который по идее будет интересен пользователям/фанатам GNU Linux.

  • В обмен за 1$ и больше:
    • Automate the Boring Stuff with Python: Practical Programming for Total Beginners
    • The Artist's Guide to GIMP: Creative Techniques for Photographers, Artists, and Designers. Second Edition
    • The Art of Debugging with GDB, DDD, and Eclipse
    • Perl One-Liners: 130 Programs That Get Things Done
    • The Book of GNS3: Build Virtual Network Labs Using Cisco, Juniper, and More
    • No Starch Sampler
  • За 8$ можно добавить к своей библиотеке:
    • The Book of Inkscape: The Definitive Guide to the Free Graphics Editor
    • The Book of GIMP: A Complete Guide to Nearly Everything
    • The Book of PF: A No-Nonsense Guide to the OpenBSD Firewall. Third Edition
    • The GNU Make Book
    • Blender Master Class: A Hands-On Guide to Modeling, Sculpting, Materials, and Rendering
    • Doing Math with Python: Use Programming to Explore Algebra, Statistics, Calculus, and More!
  • 15$ позволит читать книги:
    • How Linux Works: What Every Superuser Should Know. Second Edition
    • Wicked Cool Shell Scripts: 101 Scripts for Linux, OS X, and UNIX Systems. Second Edition
    • Absolute OpenBSD: Unix for the Practical Paranoid. Second Edition
    • Arduino Project Handbook Vol. 1: 25 Practical Projects to Get You Started
    • Think Like a Programmer: An Introduction to Creative Problem Solving
  • За более чем 30$ можно заполучить
    • The Linux Programming Interface: A Linux and UNIX System Programming Handbook

В качестве опции Support Charity по умолчанию предлагается фонд Electronic Frontier Foundation (EFF), но при небольшом усилии среди опционального списка фондов можно выбрать Free Software Foundation (FSF).

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

 ,

Evgueni ()

GPU monitor

Форум — Desktop

эти типо htop'a

для nvidia - https://github.com/wookayin/gpustat , https://github.com/mountassir/gmonitor

для amd - https://github.com/clbr/radeontop

мне нужен графический, есть такой в природе? ненаходит.

 , , , ,

eR ()

Браузер, Flash и аппаратное ускорение видео

Форум — General

В общем имеется старенький ноутбук Sasmsung rv515,

Процессор: AMD E-350 (1600 MHz) Оперативная память: 4 GB RAM Видеокарта: ATI Radeon HD 6470M

Установил на него Lubuntu 16.04 LTS, все вроде работает, но выявилась следующая проблема, во время просмотра HD видео на ютубе (720p, 1080p), картинка лагает, подвисает и тд., чем выше разрешение выставляешь, тем больше тормоза. Зайдя в диспетчер задач можно наюлюдать как процессор грузится в этот момент на все 100 процентов. В общем получается, что обработка видео идет процессором, а не видеокартой.

Есть ли способ что бы видео в браузере обрабатывалось видеокартой а не процессором? Chrome? Firefox? Opera?

 , , ,

us3r ()

О неопределённом поведении и багах оптимизатора clang на примере разбора цикла статей Криса Латтнера, разработчика clang.

Форум — Development

про ud2 - лень читать комменты - но кто-то должен был оставить вот этот цикл из трех постов:

http://blog.llvm.org/2011/05/what-every-c-programmer-should-know.html
http://blog.llvm.org/2011/05/what-every-c-programmer-should-know_14.html
http://blog.llvm.org/2011/05/what-every-c-programmer-should-know_21.html

stevejobs, спасибо за ссылки. С интересом почитал. Ответ получился довольно длинным, даже движок форума не хочет принимать его в таком виде в качестве простого камента, поэтому я решил, что он тянет на отдельную тему. Тем более, что здесь разбирается не какой-то мелкий баг/фича clang'а, а общий подход к созданию оптимизатора, основанный на изложении и анализе статей одного из разработчиков этого компилятора Криса Латтнера (Chris Lattner). Ну и ещё мне пришлось полностью переписать один из его примеров, чтоб он начал работать и иллюстрировать излагаемые им идеи. Если хочешь, можешь послать ему код, чтоб вставил в свою статью вместо своего, не рабочего. Я не возражаю.

А для тех, кто не в теме, это продолжение темы Вызов никогда не вызываемой функции.

Основная мысль автора цикла статей, как я понял, выражена ближе к концу 3-ей статьи в короткой фразе:

c) is a lot of work to implement.

Т. е. автор, по сути, соглашается, что они реализовали какую-то дичь с этими оптимизациями, объясняя некоторые причины: что де оптимизатор не знает, что на входе получает компилятор и даже не знает, что получает он сам на предыдущем проходе, ну и некоторые другие причины. А в конце говорит: но переделывать эту неудачную архитектуру нам лень, поэтому пользуйтесь тем, что есть. Что ж, fixed. В любом случае, статьи полезны, т. к. проливают свет на реальное (и довольно печальное) положение дел, связанных с оптимизациями в компиляторе clang.

Теперь разберу примеры из статей.

1. В первом примере автор пытается показать, почему к указателю на int нельзя обращаться как к указателю на float:

float *P;
 void zero_array() {
   int i;
   for (i = 0; i < 10000; ++i)
     P[i] = 0.0f;
 }

int main() {
  P = (float*)&P;  // cast causes TBAA violation in zero_array.
  zero_array();
}

Этот код — полная дичь. Он будет вылетать и с оптимизациями, и без них, потому что в переменную P (которая по умолчанию инициализируется 0), записывается её собственный адрес, а дальше, начиная с этого адреса, записываются ещё 40000 байт, которые непременно выдут за границы выделенной памяти.

Я немного переделал этот пример, чтоб он заработал, добавив сразу после P массив достаточного размера, в который и будут записываться числа (тоже undefined, но по факту работает с обоими компиляторами — clang и gcc), и заменив запись 0 на запись адреса &P+1, для чего ввёл объединение ufp, т. к. иначе на первой же итерации P будет указывать на 0, после чего на 2-й итерации произойдёт сегфолт. Ну и ещё добавил printf'ы для вывода информации и return, как того требует gcc и стандарт. Тут же отмечу, что мне пришлось слегка повозиться с unsigned *p, объявленным внутри функции print_array(). Сначала я сделал его глобальным, объявив до указателя float *P, и получил похожий на приведённый, но не совсем верный вывод: вместо ожидаемого 0x601268, 0x0, 0x0, 0x601268 программа без оптимизаций выдавала 0x601268, 0x0, 0x601268, 0x0. После установки watchpoint'а в дебагере выяснилось, что массив повторно модифицируется функцией print_array(). Просмотр адресов глобальных переменных &P и &p показал, что и clang, и gcc вставляют p после P и перед массивом arr, хотя в тексте программы она была объявлена первой. Видимо, компиляторы зачем-то сортируют переменные по типам и располагают указатели на float раньше указателей на unsigned. После переноса unsigned *p внутрь функции, всё стало работать, как и ожидалось. Вот мой рабочий (хоть и намеренно некорректный) вариант:

#include <stdio.h>

float *P;

float arr[10000];

union ufp
{
  float** p; float f;
} fp={&P+1};

void zero_array() {
   int i;
   for (i = 0; i < 10000; ++i)
     P[i] = fp.f;
 }

void print_array() {
   int i;
   unsigned *p;
   printf("&P==%p, P==%p\n", &P, P);
   for(i = -2; i < 10000; ++i)
    {
      p=(unsigned*)P;
      printf("&P[%i]==%p, P[%i]==%f (%p: 0x%X)\n", i, &P[i], i, P[i], p+i, *(p+i));
    }
}

int main() {
  P = (float*)&P;  // cast causes TBAA violation in zero_array.
  zero_array();
  //P=(float*)(&P+1); // restoring P for optimizer
  print_array();
  return 0;
}

При компиляции clang'ом без оптимизации:

clang -o zero_array zero_array.c

этот вариант выдаёт следующее:

&P==0x601260, P==0x601268
&P[-2]==0x601260, P[-2]==0.000000 (0x601260: 0x601268)
&P[-1]==0x601264, P[-1]==0.000000 (0x601264: 0x0)
&P[0]==0x601268, P[0]==0.000000 (0x601268: 0x0)
&P[1]==0x60126c, P[1]==0.000000 (0x60126c: 0x601268)
&P[2]==0x601270, P[2]==0.000000 (0x601270: 0x601268)
&P[3]==0x601274, P[3]==0.000000 (0x601274: 0x601268)
&P[4]==0x601278, P[4]==0.000000 (0x601278: 0x601268)
[skip]
&P[9994]==0x60ae90, P[9994]==0.000000 (0x60ae90: 0x601268)
&P[9995]==0x60ae94, P[9995]==0.000000 (0x60ae94: 0x601268)
&P[9996]==0x60ae98, P[9996]==0.000000 (0x60ae98: 0x601268)
&P[9997]==0x60ae9c, P[9997]==0.000000 (0x60ae9c: 0x601268)
&P[9998]==0x60aea0, P[9998]==0.000000 (0x60aea0: 0x601268)
&P[9999]==0x60aea4, P[9999]==0.000000 (0x60aea4: 0x601268)

и корректно завершается.

Если же включить оптимизацию:

clang -o zero_array -O2 zero_array.c

то получаем следующее:

$ ./zero_array
&P==0x601260, P==0x60126800601268
Ошибка сегментирования

Кстати, такой же результат будет, если откомпилировать эту программу компилятором gcc с включённой оптимизацией (там только адреса будут немного другими). Избавиться от этой ошибки можно 2 способами:

  1. Закомментировав вызов print_array() в функции main().

    Очевидно, что в этом случае никакого вывода мы не получим.

  2. Раскомментировав в main() строчку
    P=(float*)(&P+1); // restoring P for optimizer

    Тогда мы получим такой вывод:

    &P==0x601260, P==0x601268
    &P[-2]==0x601260, P[-2]==0.000000 (0x601260: 0x601268)
    &P[-1]==0x601264, P[-1]==0.000000 (0x601264: 0x0)
    &P[0]==0x601268, P[0]==0.000000 (0x601268: 0x601268)
    &P[1]==0x60126c, P[1]==0.000000 (0x60126c: 0x601268)
    &P[2]==0x601270, P[2]==0.000000 (0x601270: 0x601268)
    &P[3]==0x601274, P[3]==0.000000 (0x601274: 0x601268)
    &P[4]==0x601278, P[4]==0.000000 (0x601278: 0x601268)
    [skip]
    &P[9994]==0x60ae90, P[9994]==0.000000 (0x60ae90: 0x601268)
    &P[9995]==0x60ae94, P[9995]==0.000000 (0x60ae94: 0x601268)
    &P[9996]==0x60ae98, P[9996]==0.000000 (0x60ae98: 0x601268)
    &P[9997]==0x60ae9c, P[9997]==0.000000 (0x60ae9c: 0x601268)
    &P[9998]==0x60aea0, P[9998]==0.000000 (0x60aea0: 0x0)
    &P[9999]==0x60aea4, P[9999]==0.000000 (0x60aea4: 0x0)
    

Проблема тут очевидна: в цикле в P[i] записывается адрес &P+1. Но указатель P указывает на самого себя благодаря присвоению P = (float*)&P. Соответственно, элемент P[0] находится по тому же адресу, что и P. Когда при 1-й итерации цикла мы записываем туда адрес следующего элемента, указатель P меняется. В 64-битной ОС размер указателя равен 8 байтам, а размер float — 4, т. е. P у нас теперь указывает на начало arr. Дальше мы записываем 1-ый элемент от нового начала массива, т. е. по сути 3-й элемент, пропуская таким образом 2 элемента.

Когда же мы включаем оптимизатор (и в clang, и в gcc), он записывает все двойные слова подряд, начиная с 0-ого (в P[-1] у нас 0 потому, что мы перезаписали его после вызова zero_array(), чтобы программа не вылетела при вызове print_array()). Поэтому в первых 2 элементах у нас записано число 0x601268 (если представлять его как беззнаковое целое длиной в 4 байта), но 1-ые 2 элемента одновременно являются адресом, на который указывает P, т. е. адресом 0x0060126800601268 (0x601268 повторенное 2 раза). Если ничего не выводить, то всё тоже проходит успешно. Но как только мы вызываем print_array() (не модифицировав этот дикий адрес), программа сразу пытается отобразить содержимое не валидного адреса 0x601268, а того самого 0x0060126800601268, которого в нашем адресном пространстве просто нет. И получает сегфолт.

Почему printf отображает значения с плавающей точкой, которые в целочисленном виде выглядят как 0x601268, нулями, а не NAN, как по идее должно бы было быть, я не знаю. Видимо, это баг стандартной библиотеки (надо будет послать багрепорт, если никто мне не объяснит, что они правы).

Кстати, оба компилятора по неведомым мне причинам при оптимизации (а я пробовал разные уровни оптимизации) почему-то вместо записи поля fp.f memset'ом продолжают генерить цикл, только более короткий, чем без оптимизации (ассемблерные листинги я тут приводить не буду, кому интересно, могут сами откомпилировать с опцией -S). Хотя при записи константы 0 компилятор clang с вкючённой оптимизацией вместо цикла вызывает memset (gcc и в этом случае генерит цикл).

На всякий случай укажу версии использованных компиляторов:

$ clang --version
Debian clang version 3.5.0-10 (tags/RELEASE_350/final) (based on LLVM 3.5.0)
Target: x86_64-pc-linux-gnu
Thread model: posix

$ gcc --version
gcc (Debian 4.9.2-10) 4.9.2
Copyright (C) 2014 Free Software Foundation, Inc.
Это свободно распространяемое программное обеспечение. Условия копирования
приведены в исходных текстах. Без гарантии каких-либо качеств, включая 
коммерческую ценность и применимость для каких-либо целей.

К сожалению, мне пришлось писать рабочую программу за автора статьи, который не удосужился даже проверить тот код, который опубликовал (хотя там и без проверки видно, что код по-любому не рабочий, хоть оптимизируй, хоть нет). Впрочем, автор всё честно объяснил:

c) is a lot of work to implement.

Такие они, разработчики clang'а.

Но идею я понял: при заполнении массива 0 или другими значениями в цикле, опасно одновременно менять указатель на этот массив. Но при чём тут изначальное утверждение о том, что

It is undefined behavior to cast an int* to a float* and dereference it (accessing the «int» as if it were a «float»).

Как это утверждение иллюстрируется данным примером?

Я уже не говорю о том, что оптимизировать циклы в memset нет никакой необходимости, потому что программист и сам может это сделать, сократив не только получившийся бинарник, но и исходник. А если программисту до этого нет дела, то почему компилятору должно быть дело? Тем более, если программист сделал цикл намеренно, то компилятору совсем незачем это исправлять. Думаю, именно поэтому gcc и не сворачивает циклы в memset. Я уже не говорю о том, что если уж вы сворачиваете их в memset, то будьте последовательны. Почему при заполнении массива константой 0 вместо цикла clang вызывает memset, а при заполнении того же массива одной не меняющейся переменной длиной в 4 байта оставляет цикл? Грош цена такой оптимизации.

Вот заменить вызов memset на ассемблерную команду rep stos действительно было бы полезно, но почему-то ни clang, ни gcc этого не делают.

2. Во втором примере автор цикла показывает, как смертельный указатель может запутать оптимизатор clang так, что тот сгенерит очередную фигню вместо исполняемого кода. Вот пример смертельного кода из 2-й статьи:

void contains_null_check(int *P) {
  int dead = *P;
  if (P == 0)
    return;
  *P = 4;
}

Очевидно, что если передать функции contains_null_check() NULL, то код будет непереносимым (undefined behavior). В защищённом режиме при попытке разыменования такого указателя произойдёт сегфолт. (UPD: практически аналогичная ошибка в ядре Linux 2.6.30 и 2.6.18 для Red Hat привела к серьёзной уязвимости, причём при разыменовании указателя система не падала.) Однако в реальном режиме такой код вполне законный. Более того, если мы рассматриваем язык си как системный язык, то в некоторых случаях без подобного кода в реальном режиме не обойтись. Что у нас лежит по адресу 0 в реальном режиме? — Указатель на обработчик 0-ого прерывания (деление на 0). А что если я хочу зарегистрировать свой обработчик? Для этого и существует неопределённое поведение: в одних системах оно работает так, а в других иначе. Но разработчики clang'а считают, что «неопределённое поведение» — это индульгенция на генерацию разного бреда вместо нормального кода.

Но вернёмся к статье. Автор описывает 2 варианта поведения оптимизатора.

  1. В первом варианте сначала проверяется избыточный код, а затем избыточные проверки. Выглядит это примерно так:
    void contains_null_check_after_DCE(int *P) {
      //int dead = *P;     // deleted by the optimizer.
      if (P == 0)
        return;
      *P = 4;
    }
    

    На этом этапе совершенно справедливо выпилили переменную dead, т. к. она нигде не используется.

    Далее идёт проверка избыточности проверок и делается правильный вывод о том, что проверка P на равенство 0 нужна. Она остаётся. Всё работает, как и задумывалось (и даже не падает в защищённом режиме на радость быдлокодерам).

  2. Во втором варианте оптимизатор сначала проверяет проверки программиста на избыточность, а затем выпиливает ненужные переменные:
    void contains_null_check_after_RNCE(int *P) {
      int dead = *P;
      if (false)  // P was dereferenced by this point, so it can't be null 
        return;
      *P = 4;
    }
    

    Здесь оптимизатор почему-то решил, что раз *P разыменовывается без проверки, то он априори 0 быть не может и проверять его необходимости нет. А то, что программист мог ошибиться, разработчикам оптимизатора даже в голову не приходит. Как и то, что помимо защищённого режима есть ещё и реальный. А бывают ещё компиляторы для разных контроллеров и встроенных специализированных систем, где разыменовывать 0 указатели бывает нужно и иногда даже необходимо. Или clang такие системы не поддерживает? И никогда не сможет поддержать с подобным подходом, ориентированным на работу только защищённых многозадачных ОС.

    Но вернёмся к статье. На следующем этапе выпиливается переменная dead и проверка на 0 и остаётся:

    void contains_null_check_after_RNCE_and_DCE(int *P) {
      *P = 4;
    }
    

    Если раньше программа корректно работала в реальном режиме, а в защищённом падала, то теперь в реальном режиме вектор 0-ого прерывания перезаписывается адресом 4. В результате при любой ошибке деления компьютер намертво зависает (хотя реальный режим clang, как я понимаю, не поддерживает и никогда не сможет поддержать с таким шикарным легаси).

3. Третий пример я разбирать не буду, т. к. согласен с автором, что оптимизация «x > x+1 всегда false» может быть полезна при использовании макросов. А для проверки переполнения существуют константы MAX_*.

4. Четвёртый пример — почти из поста Вызов никогда не вызываемой функции. Его уже разобрали по полочкам, сломали все копья, какие только можно было сломать, в т. ч. и я, поэтому здесь повторяться не буду. Единственно, скажу, что мне было непонятно, зачем заменять вызов функции по 0-ому адресу с неизбежным сегфолтом на недопустимую инструкцию ud2. Автор поясняет во 2-й статье:

2. Clang has an experimental -fcatch-undefined-behavior mode that inserts runtime checks to find violations like shift amounts out of range, some simple array out of range errors, etc. This is limited because it slows down the application's runtime and it can't help you with random pointer dereferences (like Valgrind can), but it can find other important bugs. Clang also fully supports the -ftrapv flag (not to be confused with -fwrapv) which causes signed integer overflow bugs to trap at runtime (GCC also has this flag, but it is completely unreliable/buggy in my experience). Here is a quick demo of -fcatch-undefined-behavior:

В вольном пересказе: мы всегда так делаем, чтобы показать, что код содержит участки с неопределённым поведением. И плевать, что недопустимая инструкция не указывает на некорректный код. Просто ничего лучшего мы не придумали.

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

И напоследок 2 эпические цитаты. Первая из начала 1-ой статьи. Она очень понравилась dzidzitop:

It turns out that C is not a «high level assembler» like many experienced C programmers (particularly folks with a low-level focus) like to think

Вот оно что оказывается. Си — это та же ява, чуть более быстрая и более опасная. А для написания системных вещей переходите на настоящий ассемблер! Кен Томпсон гомерически хохочет и Деннис Ритчи переворачивается в гробу.

А вторая из 3-ей, заключительной статьи:

Ultimately, undefined behavior is valuable to the optimizer because it is saying «this operation is invalid - you can assume it never happens».

В вольном пересказе это обозначает: «Вау! Неопределённое поведение! Ворочу куда хочу!»

UPD: Вот хочу добавить сюда ещё несколько ответов на вопросы, на которые приходится отвечать по всему треду одно и то же:

1. То, что ub обозначает «делай, что хочешь!», мягко говоря, неправда. Вот, что написано в стандарте C99:

3.4.3

1 undefined behavior

behavior, upon use of a nonportable or erroneous program construct or of erroneous data, for which this International Standard imposes no requirements

2 NOTE Possible undefined behavior ranges from ignoring the situation completely with unpredictable results, to behaving during translation or program execution in a documented manner characteristic of the environment (with or without the issuance of a diagnostic message), to terminating a translation or execution (with the issuance of a diagnostic message).

3 EXAMPLE An example of undefined behavior is the behavior on integer overflow.

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

1. Игнорировать ситуацию. Смотрим в Ожегове, что обозначает слово «игнорировать»:

Умышленно не заметить, не принять во внимание.

Т. е. «игнорировать» — это сделать вид, что всё нормально и пройти мимо, а не модифицировать или удалять такой код, и уж тем более делать на его основе какие-то бредовые предположения.

2. Компилировать и выполнять такой код в соответствии с документацией, с выводом предупреждающих сообщений или без них. Т. е. напишите явно в документации, что если мы встречаем 0 указатель, то делаем то-то и то-то, и делайте. Но не в тихую.

3. Прерывать компиляцию и/или выполнение с обязательным выводом диагностических сообщений.

И всё. Ни о каком «что хочешь» в стандарте речи не идёт. Вот тут мне в каментах подсказали, что «with unpredictable results» обозначает «что хочешь». Но на самом деле это обозначает лишь то, что результаты могут быть непредсказуемыми, а совсем не то, что компилятор может делать всё, что угодно (хотя разработчикам таких компиляторов подобная трактовка очень удобна).

Ну и тот же человек считает, что «это notes», а значит неважно, что там написано. Но т. н. неопределённое поведение при переполнении целого — вообще example из того же пункта:

EXAMPLE An example of undefined behavior is the behavior on integer overflow.

И больше я нигде никаких упоминаний об ub при арифметическом переполнении не нашёл. Про переполнение при сдвигах — нашёл. А в других случаях — нет. Но все почему-то на этот example ссылаются.

2. Многие говорят, что быдлокодеры должны страдать. Но серьёзные уязвимости, связанные с ub, а точнее с непредсказуемой реакцией компилятора на ub, в разное время обнаруживались в ядре Linux, во FreeBSD и в GDK-Pixbuf, затрагивающая Chromium, Firefox и VLC. Подробнее см. в этом комментарии, чтоб не раздувать и без того длинный верхний пост. Здесь только скажу, что уязвимость в ядре Linux связана с ошибкой, идентичной со 2-м примером из разбираемых статей.

3. Автор статей и многие в этом треде утверждают, что автоматически отыскать такие ошибки очень сложно и дорого, а то и вовсе невозможно. Но это тоже не так. В Интернете я нашёл такой пример си++ программы с ub:

#include <iostream>
int main()
{
    for (int i = 0; i < 300; i++)
        std::cout << i << " " << i * 12345678 << std::endl;
}

Программа из-за переполнения временного результата на 174-й итерации при использовании ключа оптимизации -O2 в g++ попадает в бесконечный цикл.

Запустив компиляцию, я получил следующие предупреждения (причём безо всяких опций -W что-то_там):

$ g++ -o infinity_loop -O2 infinity_loop.cpp
infinity_loop.cpp: В функции «int main()»:
infinity_loop.cpp:5:38: предупреждение: iteration 174u invokes undefined behavior [-Waggressive-loop-optimizations]
         std::cout << i << " " << i * 12345678 << std::endl;
                                      ^
infinity_loop.cpp:4:5: замечание: containing loop
     for (int i = 0; i < 300; i++)
     ^

А ведь здесь случай куда менее очевидный, чем простое разыменование NULL-указателя.

4. Наконец, на Хабре я вычитал, что стандартный макрос

#define offsetof(st, m) ((size_t)(&((st *)0)->m))

тоже содержит UB. Правда, к ошибкам и уязвимостям это пока не приводит. Но именно, что пока, UB ведь, а значит любой компилятор имеет полное право, встретив вызов этого макроса, отформатировать диск, как утверждают создатели компиляторов и многие лорчане.

UPD 2: Вот тут Sorcerer в комментарии кинул ссылку на письмо Линуса Торвальдса в рассылке от 12 января 2009 года, где он пишет о том, что думает о некоторых оптимизациях. Приведу несколько фрагментов этого письма в своём переводе:

Type-based aliasing — это тупость. Это такая невероятная тупость, что даже не смешно. Оно испорчено. И gcc взял испорченную концепцию и настолько её раздул, следуя букве-закона, что получилась бессмысленная вещь.

[skip]

Это НЕНОРМАЛЬНО. Это так невероятно безумно, что люди, которые делают это, просто должны избавиться от своего убожества, прежде чем они смогут восстановить. Но реальные gcc программисты действительно думали, что это имеет смысл, потому что стандарт это позволяет и даёт компилятору максимальную свободу, — потому что он может делать теперь вещи БЕЗУСЛОВНО АБСУРДНЫЕ.

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

[skip] И если кто-то жалуется, что компилятор невменяемый, компиляторщики скажут «ня, ня, разработчики стандарта сказали, что так можно», с абсолютным отсутствием анализа, имеет ли оно СМЫСЛ.

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

[skip]

Угадайте, что произойдёт, если вы имеете такой безумный склад ума и пытаетесь сделать безопасный код без alias'а, — вы займёте лишнее пространство на стеке.

По факту, Linux использует -fno-strict-aliasing из-за чертовски веской причины: потому что в gcc понятие «strict aliasing» является огромной зловонной кучей д-рьма. Linux использует этот флаг не потому, что Linux исполняется быстро и свободно, он использует этот флаг, потому что _не_ использует тот безумный флаг.

Type-based aliasing неприемлемо тупо для начала, и gcc вознёс этот идиотизм до совершенно новых высот, фактически не обращая внимания даже на статически видимый aliasing.

Линус

Оригинал (на английском):

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

И ещё спасибо anonymous'у за камент с ещё одним сообщением на ту же тему того же автора от 26 февраля 2003 года.

Ну и от себя добавлю, что не только Линусу не нравится aliasing. Microsoft тоже не спешит реализовывать его в своём Visual C++. Т. е. не нравится это тем, кто помимо разработки компиляторов создаёт и другой софт с использованием этого компилятора, например ОС. А те, кто создают только компиляторы для сферических программистов в вакууме, рьяно эту фичу реализуют, хоть их и никто не заставляет.

Ну и напоследок оставлю несколько полезных ссылок на память:

Стандарт C11 (последний) (pdf), Стандарт C99 (pdf),

http: //read.pudn.com/downloads133/doc/565041/ANSI_ISO%2B9899-1990%2B%5B1%5D.pdf (Стандарт C89) (pdf),

http: //web.archive.org/web/20030222051144/http: //home.earthlink.net/~bobbitts/c89.txt (Стандарт C89) (txt),

https: //web.archive.org/web/20170325025026/http: // www .open-std.org/jtc1/sc22/wg21/docs/papers/2017/n4660.pdf (Стандарт C++17) (последний) (pdf),

Стандарт C++14 (pdf), Стандарт C++11 (pdf),

бумажный перевод стандарта C++17, выполненный Зуевым и Чуприновым, Москва, 2016, на основе Working Draft, Standard for Programming Language C++ от 22 мая 2015 года (номер документа n4527) за 4945 руб. (надеюсь, что эту ссылку не сочтут за рекламу, т. к. к авторам я никакого отношения не имею), а здесь можно скачать начало перевода (предисловие и содержание), ну и ещё торрент-ссылку видел на эту книгу, но здесь её публиковать не буду,

статья на Хабре (из песочницы) от 2014 г. Неопределенное поведение в C++, ещё одна статья там же от 2016 года Находим ошибки в коде компилятора GCC с помощью анализатора PVS-Studio, Разыменовывание нулевого указателя приводит к неопределённому поведению и Про C++ алиасинг, ловкие оптимизации и подлые баги. Это так, ссылки на заметку.

Некоторые ссылки парсер ЛОР'а не принял, поэтому мне пришлось разделить их пробелами, превратив в текст, который можно скопировать в адресную строку браузера, удалив пробелы. Там, где http встречается дважды в 1 строке — не ошибка, а именно такие ссылки.

 , , , ,

aureliano15 ()

Классика на свободных движках.

Форум — Games

Здравствуйте, любители свежей олдятинки!
Провёл ревизию и выяснил, что есть вполне живые и работоспособные движки к классическим игрушкам. Вот некоторые примеры:

  • openKB - движок для King's Bounty - идейного прародителя Heroes Of Might & Magic, Warlords, Disciples, Age Of Wonders.
  • FHeroes2 - Heroes of Might & Magic 2 - прошёл 2 больших карты против AI, всё вполне работоспособно, быстро, красиво, поддерживается вся серия HOMM2, смена разрешений, в настройках можно добавлять плюшки из HOMM3.
  • VCMI - Heroes of Might & Magic 3 - играл против AI, тестировал новые версии движка, испавлял баги, добавлял города. Поддерживаются WOG и ERA, но можно играть и на чистых HOMM3 (поддерживается вся серия). Также много плюшек, новых артефактов, городов, юнитов, героев, смена разрешений и другие вкусности.
  • Dune Legacy - Dune 2 - прошёл несколько миссий за разные дома, играл скирмиши, всё прекрасно работает. Движок вполне современный, взято много идей из последующих игр серии, например выделение множества объектов, очереди строительства, векторы движения, естественно, есть смена разрешений и куча приятных настроек. Также поддерживаются моды.
  • War1gus - движок для Warcraft I, основан на Stratagus.
  • Wargus+Aleona's Tales - свободный движок для Warcraft II + свободные ресурсы (можно играть и с оригинальными) - тоже вполне играбельно и удобно, основа движка - Stratagus, возможность выделять множество объектов, векторы движения, разные разрешения...
  • Stargus - движок для Starcraft I, основан на Stratagus.
  • 7KAA - движок для своеобразной стратегии Seven Kingdoms.
  • OpenRedAlert - движок для Red Alert 1, написанный на C++, в отличие OpenRA (Mono).
  • OpenRA - модифицированный движок для Red Alert, Command & Conquer и Dune 2000 (Achtung! Mono!).
  • OpenXcom - UFO: Enemy Unknown - прохожу капманию, всё работает, с каждой новой версией всё лучше. Также с версии 1.0 поддерживается мод с Ктулху.
  • FreeSynd - Syndicate - тоже вполне играбельно, наконец-то починили радар.
  • Syndicate Wars Port - движок для Syndicate Wars, продолжения Syndicate.
  • GemRB - движок для Baldur's Gate, Icewind Dale и Planescape: Torment. Вполне рабочий, я почти прошёл Baldur's Gate.
  • Micropolis - Свободный движок для SimCity.
  • ECWolf - модернизированный движок для Wolfenstein 3D, Spear of Destiny и Super 3D Noah's Ark, основанный на кодах Wolf4SDL и ZDoom.
  • Cytadela - движок для Cytadela, стрелялки от первого лица для Amiga.
  • Rise of the Triad - движок для уникальной для своего времени игры Rise of the Triad, основанной на сильно модифицированном движке для Wolfenstein 3D.
  • ZDoom+FreeDoom - Модифицированный и современный движок для Doom, Doom 2, Heretic, HeXen, Strife + свободные ресурсы. Множество улучшений: свободный обзор, прицел, приседания и прыжки, объекты больше не имеют бесконечную высоту, высокое разрешение. Также есть замечательный мод BrutalDoom, привносящий моря кровищщи, горы кишок и ультранасилие.
  • GZDoom - OpenGL-форк ZDoom.
  • Doomsday - модифицированный OpenGL-движок для Doom I&2, Heretic, Hexen, HacX, Chex с поддержкой трёхмерных моделей вместо спрайтов.
  • uHexen2 - SDL/OpenGL движок для Hexen II: Hammer of Thyrion.
  • DarkPlaces + Quake Revitalization Project - модифицированный OpenGL-движок для Quake I + обновлённые текстуры.
  • Yamagi Quake II - модифицированный движок для Quake II, также поддерживает дополнения Mission Pack 1 'The Reckoning' и Mission Pack 2 'Ground Zero'.
  • ioquake3 - модифицированный движок для Quake III.
  • Eduke32+HRP - Модифицированный SDL/OpenGL движок для Duke Nukem 3D (свободный обзор, прицел, прыжки, приседания, высокое разрешение) + набор свободных трёхмерных текстур. Прошёл всего Дюка с трёхмерными текстурами и продвинутой отрисовкой Polymer.
  • eRampage - движок для стрелялок Redneck Rampage, Suckin' Grits on Route 66, Redneck Rampage Rides Again и Redneck Deer Huntin'. Основан на EDuke32.
  • BloodCM + HRP for BloodCM - Blood на движке EDuke32 + текстуры в высоком разрешении. Готовы 2 эпизода игры, третий в разработке.
  • Aleph One - модифицированный движок для Marathon, Marathon 2: Durandal и Marathon Infinity. Также сообществом разработаны новые игры Marathon: EVIL, Tempus Irae, Marathon RED, Marathon: Eternal, Marathon: Rubicon X, Marathon: Phoenix. Ещё есть отдельная игра Excalibur: Morgana's Revenge. Эти игры особенно придутся по душе латентным, активным и пассивным любителям Macintosh, ибо изначально Marathon разрабатывался исключительно под эту платформу.
  • Xash3D - свободный движок для Half-Life (аналог GoldSource).
  • D2X-XL - OpenGL движок для трёхмерной леталки-стрелялки Descent. Также разработан редактор уровней DLE.
  • DXX-Rebirth - SDL/OpenGL движок для трёхмерных леталок-стрелялок Descent 1&2.
  • ForsakenX - движок для трёхмерной леталки-стрелялки Forsaken, клона Descent.
  • OpenTTD - свободный движок для Transport Tycoon Deluxe + свободная графика и звуки.
  • JA2-Stracciatella - Jagged Alliance 2. Несмотря на периодические приостановки, проект до сих пор жив и недавно снова вошёл в активную фазу.
  • ScummVM - набор свободных движков в основном для игр в жанре quest (приключение), например от Lucas Arts, Sierra, Westwood, Coktel Vision, The Neverhood Inc., The Dreamers Guild, Revolution Software, Psygnosis, Infocom, Delphine Software International, Adventure Soft, также и для некоторых ролевых игр: Eye of the Beholder I&II, Lands of Lore: The Throne of Chaos. На данном этапе ведутся работы по поддержке таких замечательных игр, как Myst, Riven: The Sequel to Myst, Gabriel Knight, Gabriel Knight 2: The Beast Within, King's Quest VII, Phantasmagoria I&II, Police Quest IV, Police Quest: SWAT, Quest for Glory IV, Space Quest 6: The Spinal Frontier, Leisure Suit Larry 7, Broken Sword 2.5...
  • ResidualVM - движки для трёхмерных игр Grim Fandango и Escape from Monkey Island от Lucas Arts, также добавлена поддержка для Myst 3 Exile. Для Grim Fandango разработан 'point & click интерфейс'.
  • Pentagram - движок для Ultima VIII с поддержкой разных разрешений, разных звуковых систем, миникарты, TrueType.
  • Exult - движок для Ultima VII с поддержкой разных разрешений, разных звуковых систем, статусбаров, Exult Studio для разработки своих игр.
  • Nuvie - движок для Ultima VI.
  • XU4 - движок для Ultima IV с поддержкой VGA и 16-bit графики, смешивание заклинаний как в Ultima V.
  • OpenMW - The Elder Scrolls III: Morrowind. Проект активно развивается, добавляется новый функционал, поддержка модификаций, но на данном этапе поиграть пока не удастся.
  • Lord of the Rings game engine - движок для ролевой игры Lord of the Rings.
  • Arx Libertatis - движок для трёхмерной ролевой игры Arx Fatalis.
  • FS2Open - движок для космического симулятора FreeSpace 2. Также есть fsport - адаптация кампаний FreeSpace 1 для FS2Open.
  • CorsixTH + CorsixTH-Graphics - движок для симулятора больницы Theme Hospital и набор новой свободной графики.
  • Abysmal Engine - движок для System Shock 1 и Ultima Underworld. Проект жив, потихоньку развивается.
  • OpenAge - движок для Age of Empires II. Проект на начальной стадии, ещё сырой. Разработчики пока толком не определились с технологиями, хотят для изометрической графики задействовать OpenGl и шейдеры.
  • Antares - движок для космической стратегии Ares. Трепещите, латентные, активные и пассивные любители Macintosh, игра изначально разрабатывалась исключительно под эту платформу.
  • CaesarIA - симулятор Римской Империи и Цезаря в частности Caesar III.
  • Falltergeist - свободный движок для Fallout 1&2, разрабатываемый на C++ с использованием SDL2. Проект на начальной стадии, но активно развивается.
  • freeablo - свободный движок для Diablo 1 с использованием SDL2. Проект на начальной стадии, готов начальный посёлок с нейтральными персонажами и пара случайно генерируемых подземных уровней.
  • Abuse - аркадная стрелялка-платформер, сюжет вдохновлён вариациями на тему «Хищник против Чужих». Движок использует отрисовку через SDL или OpenGL (на выбор), работает на 32-bit и 64-bit платформах. К игре прилагаются освобождённые ресурсы.
  • New RAW - интерпретатор для аркадной игры Another World.
  • Bermuda Syndrome - SDL-движок для аркадного приключения Bermuda Syndrome.
  • REminiscence - SDL-движок для аркадного приключения Flashback.
  • f2bgl - SDL/OpenGL-движок для трёхмерного приключения Fade To Black.
  • Igor - SDL-движок для испанского квеста Igor: Objetivo Uikokahonia.
  • Carlos - SDL-движок для платформера Carlos.
  • xBaK - движок для уникальной для своего времени ролевой игры Betrayal at Krondor. Относительно играбельно, но некоторых важных функций может не оказаться. Проект, к сожалению, заброшен. Форкайте, господа, пилите для ScummVM.
  • bstone - движок для стрелялки от первого лица Blake Stone: Planet Strike.
  • CatacombSDL - SDL2-движок для фентези-стрелялки Catacomb II.
  • NXEngine - SDL-движок для платформера Doukutsu Monogatari (также известного как Cave Story).
  • Commander Genius - движок для серии платформеров Commander Keen.
  • The Ur-Quan Masters + Ur-Quan Masters HD - движок для космического аркадного ролевого стратегического квеста Star Control II + текстуры в высоком разрешении.
  • OpenJK - движок для Jedi Knight II: Jedi Outcast и Jedi Knight III: Jedi Academy с минимальными измененями, максимально близкий к оригинальному.
  • JediOutcastLinux - ещё один движок для Jedi Knight II: Jedi Outcast.
  • JediAcademyLinux - ещё один движок для Jedi Knight III: Jedi Academy.
  • SDL Sopwith - SDL/GTK+ движок для классического аркадного авиасимулятора Sopwith.
  • Ultimate Stunts - OpenGL движок для классического гоночного симулятора Stunts.
  • Freeserf - SDL-движок для классического симулятора поселенцев The Settlers 1 «Serf City».
  • Return to the Roots - OpenGL-движок для для классического симулятора поселенцев The Settlers II Gold Edition.
  • OpenRaider - OpenGL-движок для серии приключенческих игр Tomb Raider (1-5). 5-я игра серии пока не полностью работоспособна.
  • OpenTomb - ещё один OpenGL-движок для серии приключенческих игр Tomb Raider (1-5).
  • Privateer - Gemini Gold - OpenGL-движок для Wing Commander, основан на кодовой базе Vega Strike.
  • ET: Legacy - модифицированный движок для многопользовательской игры Wolfenstein: Enemy Territory.
  • Zod Engine - движок для уникальной стратегии Z.

Статья на LOR Wiki.

 ,

toney ()

Для тех, кто думает перейти на Gentoo

Форум — General

Привет

Достаточно часто создаются темы, где люди думают переходить на Gentoo и хотят уточнить некоторые моменты. Чтобы сэкономить время себе и другим, решил создать этот топик, в котором буду собирать ответы на частые вопросы.

TL; DR: Для тех, кто думает перейти на Gentoo (комментарий)

Преимущества
#1 Gentoo очень гибкая и всенастраиваема
Пример того что в Gentoo делается просто:
- Использовать openrc вместо systemd или наоборот; pulseaudio или без него
- Наложить кастомный патч; пример когда это нужно
- Подключить или отключить такие вещи как vaapi, vdpau, opencv и т. п.
- Иметь несколько веток софта; уточню, что это работает только для определённых пакетов; например можно одновременно установить python 2.7, 3.4, 3.5 или qt4 и qt5, но нельзя одновременно установить qt 5.7 и 5.8

#2 Очень удобный и функциональный пакетный менеджер
Примеры удобных фич:
- Прервать установку (вплоть до перегрузки компьютера), а потом ее продолжить. Можно продолжить с последнего пакета (emerge --resume), продолжить но пропустить последний пакет, например, если его установка прервалась с ошибкой (emerge --resume --skipfirst, некоторые нюансы); для больших пакетов можно продолжить саму компиляцию (ebuild <полный путь и имя файла>.ebuild merge).
- Когда при установке обновляется конфиг приложения, определяется редактировался ли предыдущий конфиг пользователем. Если да, конфиг не перезаписывается, а кладётся радом, и выводится сообщение пользователю с предложением обновить конфиг.
- Обновить всю систему, но исключить некоторые пакеты (удобно для исключения больших пакетов из ежедневного обновления)
- Почистить зависимости - удалить те пакеты, которые больше никому не нужны.
- Поскольку ebuild - текстовый файл, то можно пропарсить на предмет требований к количеству ресурсов для установки:

$ for F in $(find /usr/portage -name "*.ebuild") ; do REQ=$(grep "CHECKREQS" "$F") ; if [[ -n "$REQ" ]]; then echo -e "\n$F\n$REQ" ; fi; done
- Вынести компиляцию на другой компьютер (поддержка distcc на уровне пакетного менеджера). Важно когда Gentoo устанавливается на слабый компьютер.


#3 Хорошая документация, по крайней мере на английском. Более того, поскольку Gentoo-специфичные утилиты являются лишь надстройкой на generic механизмами, документация от других дистрибутивов (например от Arch) в большинстве случаев тоже подходит.
Опрос 2014: У какого дистрибутива лучшая документация

#4 Достаточно свежий софт, много сторонних репозиториев.
Список сторонних репозиториев
Gentoo - rolling release, а значит как только новая версия конкретного софта появилась в репозитории, её можно установить. Но здесь не имеется ввиду, что как только новая версия зарелизилась, она моментально становится доступна в основном дереве; лаг есть, но он как правило не большой, хотя зависит от пакета. В тестинг ветке новые версии появляются раньше. Кроме того мейнтейнеры Gentoo могут маскировать некоторые версии, если в них обнаруживаются серьезные баги. Однако всегда можно размаскировать нужную версию. Кроме того для некоторых пакетов есть -live версии, когда исходники скачиваются напрямую из github или аналога.
Пример когда «у меня не самый свежий софт в Gentoo»

#5 Полный порядок в системе, ничего лишнего - эстетическое удовольствие, плюс возможно можно немного улучшить перформанс

#6 В процессе установки и эксплуатации получаешь полное понимание как работает система, а значит возникающие проблемы решаются быстро. На самом деле без должного знания Линукса (или желания его узнать в процессе) Gentoo нормально не установить.

Недостатки
#1 Сложная и долгая первичная установка. Если устанавливать в первый раз, нужно готовиться потратить несколько дней. Для опытных - несколько часов + компиляция.
Время установки (компиляции) Gentoo, еще немного цифр по большим пакетам

#2 Пакетный менеджер хоть и удобный, но очень медленный

#3 Если не обновлять систему долго (полгода и более), то сложность обновления сопоставима с установкой новой системы. Есть мнение, что emerge-webrsync --revert=yyyymmdd должен помочь (лично я не проверял).

Особенности
#1 Высокий порог входа; дистрибутив не для новичков. Если человек не комфортно чувствует себя в командной строке, никогда не компилировал ядро, не разбивал диски на разделы, не привык изучать докуменацию, вчитываться в сообщения и анализировать логи, то Gentoo покажется сложной в обслуживании, а возникающие проблемы будут списываться на дистрибутив.

#2 Обновляться нужно часто.

#3 Основные фичи - в командной строке. Для тех, кто не привык работать в командной строке, это будет минусом. А для тех, кто комфортно чувствует себя в командной строке, это будет плюсом, так как работа в командной строке более эффективна, а типовые сценарии можно обернуть в скрипты и еще больше сократить время на обслуживание системы.

#4 Есть две ветки: stable и testing. В stable меньше шансов встретить проблему, но в testing более свежий софт. Ветки можно комбинировать.

Мифы
Миф #1 Gentoo даст прирост производительности за счет того, что весь софт компилируется под конкретное железо.
Краткий ответ: В 99% случаев при смене дистрибутива X на Gentoo вы не заметите какого-либо улучшения в плане скорости работы. Если вы зададитесь целью сравнить свежеустановленный дистрибутив X с свежеустановленной Gentoo, то в 90% вы не увидите значительной разницы.

Детальный ответ.
Не следует ожидать что просто скомпилировав систему из исходников вы получите сколько-нибудь заметное улучшение перформанса.
Для большинства приложений компиляции под конкретное железо даст прирост производительности в районе 1-2%.
Ложка дегтя: в некоторых случаях даже может быть замедление. Например Firefox, можно ускорить с помощью PGO. В Gentoo по умолчанию это отключено, так как PGO увеличивает время компиляции почти в два раза. В бинарных дистрибутивах соотв. софт может быть скомпилирован с PGO.
Так как добиться улучшения производительности? Узкий круг приложений может быть значительно ускорен при компиляции под конкретную платформу - на 30%-50% и больше. В основном это приложения которые активно занимаются вычислениями. Но для этого требуется соотв. настройки. Например, активация SIMD инструкций, даст прирост производительности в мультимедиа приложениях. Некоторые процессоры имеют аппаратную поддержку шифрования AES. В бинарных дистрибутивах подобные фичи будут отключены, так как не все процессоры это поддерживают, а бинарные дистрибутивы в первую очередь заботятся о совместимости.
Небольшое улучшения перформанса возможно если убрать из системы всё лишнее (мнение 1, мнение 2).
Еще интересный случай

Миф #2 Обновления занимают много времени
Краткий ответ: 5-10 минут на фоне, не мешая основной работе.

Детальный ответ.
Обновления не занимают много времени, но опять же, при правильном подходе.
Во-первых, как было сказано выше, обновляться нужно часто. Для testing ветки это каждый день, или по крайней мере не реже чем в раз 2-3 недели. Для стабильной ветки - раз в неделю достаточно (на стабильной ветке намного реже выпускаются обновления)
Во-вторых, есть пакеты которые правда очень долго компилятся: libreoffice, firefox, chromium... Их всего 10-15. Я их исключаю из ежедневного обновления, а обновляю раз в несколько месяцев.
Еще нужно сказать, что на этом вопросе часто заостряют неоправданно много внимания. Обычно обновления происходят на фоне, и не сильно влияют на работу; так какая разница как долго они выполняются?
В итоге, у меня обновления занимают примерно 5-10 мин ежедневно (у меня тестинг-ветка).
К тому же всё происходит на фоне, в любой момент можно поставить на паузу (Ctrl+Z, fg), продолжить после прерывания (умышленного или случайного).
Мой скрипт ежедневного обновления

Миф #3 Gentoo требует много времени на обслуживание
Краткий ответ: Может быть больше, может быть меньше по сравнению с другими дистрибутивами. Очень зависит от того, насколько вы будете вчитываться в то, что пишет вам пакетный менеджер, и разбираться первопричинах.

Детальный ответ.
Обслуживание Gentoo занимает меньше времени по сравнению с другими дистрибутивами, но только при грамотном обращении, конечно. Достигается это за счет следующего:
- хороший пакетный менеджер: маскировки, глобальные и индивидуальные установки для пакетов (USE флаги, опции компиляции, каталоги), хуки, приоритеты (чтобы компиляция происходила на фоне и можно было работать), много опций для установки и анализа, подсказки после установки.
- всё происходит в CLI, а значит типовые операции можно обернуть в скрипты/алиасы.
- уже существуют много утилит для облегчения обслуживания: eselect, equery, eix, eclean, euse, genlop и др.
Грамотное обращение означает, что вы правильно и регулярно обновляете систему, исполняете предписания emerge, которые он выдает после установки, держите в порядке конфигурационные файлы, а если таки возникает проблема, которую решить вы не можете, то вы обращаетесь в форумы, а не просто жалуетесь на жизнь.
Что до проблем с обновлениями - см. следующий пункт «Миф #4 Установка, обновление постоянно падают; частые блокировки»

Миф #4 Установка, обновление постоянно падают; частые блокировки
Краткий ответ: Не чаще чем в других дистрибутивах

Детальный ответ.
Если говорить про «часто» и «постоянно», то проблемы с обновлением/установкой могут быть если:
- система давно не обновлялась
- система неправильно обслуживается (см. выше про Грамотное обращение)

В редких случаях пакет просто не компилируется. На самом деле это проблема не Gentoo, а тех, кто писал этот софт. И в подавляющим большинстве случаев это не является проблемой, и вот почему. Если это обновление, то можно продолжить процесс запустив emerge с параметрами --resume --skipfirst - он обойдет проблемный пакет, пересчитает зависимости чтобы система осталась консистентной, и продолжит обновление (а можно изначально передать параметр --keep-going, тогда это будет происходить автоматически, прерываний вообще не будет). Если пакет критичен, можно установить предыдущую версию, которая компилировалась (а проблемную замаскировать чтобы пакетный менеджер ее не видел).

Что может заблокировать обновление полностью:
- просьба пакетного менеджера поменять флаги пакета. При этом emerge предлагает сделать это автоматически, но лично я предпочитаю делать вручную. Для ручного способа, решается добавлением строчки в package.use
- просьба пакетного менеджера задать лицензию. Это валидно только для не-свободных лицензий, например EULA, Skype, Adobe Flash и т. п. Если мы говорим имено про обновление, то такое бывает только когда лицензия обновляется, что бывает очень редко (как много у вас пакетов под не-свободной лицензией, и как часто они меняют лицензию?). Решается добавлением одного слова в make.conf
- просьба пакетного менеджера размаскировать пакет. По моему опыту нужно не размаскировывать, а наоборот замаскировывать пакеты, которые тянут замаскированные зависимости. Это, да, требует минут 5-10 на разобраться. Но, если только у вас нет смешения веток и live пакетов, такой вариант случается раз в пятилетку.
- сложные блокировки. Большинство блокировок пакетный менеджер разрешает сам; по моим наблюдениям, качество данного механизма значительно улучшилось пару лет назад. Из своего опыты скажу, что (учитывая частые обновления) блокировок, которые бы совсем останавливали обновление я уже не видел года 1.5. Но если они есть, то это действительно сложный кейс.

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

Миф #5 В Gentoo нет бинарных пакетов
Краткий ответ: Есть там, где это действительно нужно.

Детальный ответ
Во-первых есть Calculate Linux - полностью бинарный форк Gentoo.
Во-вторых даже в самом Gentoo в основном репозитории есть несколько бинарных пакетов: libreoffice-bin, firefox-bin, некоторые другие. Связано это с тем, что из исходников они очень долго компилируются, и иногда проще поставить бинарник.
Бинарный пакет можно сделать самому командой quickpkg --include-config y <установленный пакет> - удобно для бекапов.

FAQ

#1 Установка на слабый компьютер
Смотря что есть слабый компьютер.
Из собственного опыта: Intel Core2 Duo 6600 @ 2.40GHz, 2Gb RAM + 4Gb swap хватало для комфортной работы в Gentoo.
Зачастую ebuld'ы содержат информацию о том, сколько нужно памяти для компиляции пакета. TOP 5:
16G - chromium
8G - ledger, isabelle
7G - ceph
6G - firefox x64 (для x32 нужно 3G), pypy x64 (для x32 нужно 3G)
5G - electron
Если компьютер и вправду слабый, то лучше выбрать не Gentoo (точнее не-source-based дистрибутив). Альтернатива - можно вынести компиляцию на другой «не-слабый» компьютер с помощью distcc.


Опрос 2021: Какую операционную систему и/или дистрибутив GNU/Linux вы используете на ПК?
Опрос 2018: Какой ОС вы пользуетесь на основном ПК?
Опрос 2017: Какую ОС вы используете на основном ПК?
Опрос 2014: Какой дистрибутив вы используете на десктопе?
W3Tech стастика дистрибутивов на серверах
Отличия дистрибутивов, время работы ноутбука
Чем удобны USE флаги
Сколько памяти нужно для РАБОТЫ Gentoo (сколько нужно для компиляции было указано выше)
Сколько места на диске нужно для Gentoo
Правильное полное обновление Gentoo, Мой скрипт ежедневного обновления, Еще вариант
Gentoo для девелоперов
Практика инсталляции Gentoo: в двух словах простым языком
Небольшой скрипт - сборка livecd

 

Kroz ()

AMDGPU-PRO на Gentoo тред

Форум — Linux-hardware

Это — тред про установку и использование драйвера AMDGPU-PRO на Gentoo.

Не секрет, что в связи со школьными каникулами ребята с арчик-линукса уже давно, буквально в течение недели запилили у себя (пока не официально) использование передового драйвера-бетки AMDGPU-PRO, первая бетка ставилась так, а свежайшая — вот так.

Если у вас GCN 1.1, то в ядре должна быть включена опция CONFIG_DRM_AMDGPU_CIK=y :

Device Drivers  --->
    Graphics support  --->
        <*> Direct Rendering Manager (XFree86 4.1.0 and higher DRI support)
        <M> AMD GPU
            [*] Enable amdgpu support for CIK parts 
                 (only needed if you want to use Sea Islands GPUs with the amdgpu driver)

Итак, вернемся на генту, я пробовал здесь сделать так же как на арче следуя шагам в PKGBUILD, много чего пришлось перезаписать, удалить, поставить, в итоге ничего не вышло, OpenGL 4.5 не поднялся, впрочем OpenCL тоже, хотя ранее удавалось запилить OpenCL 1.1/1.2 с помощью рецепта Novell-ch. Но мне нужен не только OpenCL, но и OpenGL, поэтому я и решил создать этот тред.

Кто пробовал уже на генте поднять AMDGPU-PRO? Успешно? На чём остановились? Я сегодня приступаю к запилу сабжа, но быть может кто-то уже поставил и использует?

Буквально в день выхода первой бетки, некто farmboy0 создал ебилд под названием ati-drivers-16.15.2.277429, который на самом деле никакой не ati-drivers, а самый настоящий amdgpu-pro, но он не ставится, там нужно переделывать серьезно, что очевидно с того времени фармбой и не осилил.

 , , , ,

l-_-l ()

Приложения для дома, использующие OpenCL или GLSL (ну ладно, пусть будет и CUDA)

Форум — Desktop

Update: В список добавлен ряд приложений упомянутых в теме.

Первая половина 2015 года уже давно прошла и так как раз в несколько лет на ЛОР'е пытаются выяснить какой софт сейчас поддерживает OpenCL/GLSL/CUDA для Linux, то тоже спрошу, как сейчас с этим обстоят дела? Какие приложения могут порадовать пользователя домашнего ПК обработкой на GPU? Из всего что удалось пока найти:

Обработка изображений

  • Darktable - заявлена поддержка OpenCL.
  • Corel AfterShot Pro - поддержка OpenCL.
  • Agisoft PhotoScan - поддержка OpenCL.
  • Gimp - поддержка OpenCL в «зачаточном состоянии», так как переход на GEGL ещё не завершён.
  • Krita - поддержка ускорения вращения, масштабирования через функции OpenGL 3.2.

Были слухи, что поддержку OpenCL хотели сделать в Inkscape для обработки фильтров SVG, но в итоге они добавили поддержку OpenMP.
Появилась ли поддержка OpenCL в Hugin, RawTherapee, Krita я выяснить не смог.
Существуют ли просмотрщики с поддержкой редактирования умеющие использовать мощности видеокарты?

Вычисления

  • Scilab - поддержка CUDA и OpenCL некоторых функций посредством внешнего модуля Scilab SciGPGPU.
  • Matlab - поддержка CUDA.
  • Maple - поддержка CUDA.
  • Wolfram Mathematica - поддержка OpenCL и CUDA.
  • Заявлена поддержка OpenCL в LibreOffice Calc

Какое состояние поддержки у Octave, Maxima?

«Библиотеки» и приложения для обработки мультимедиа и изображений

  • FlacCL, FlaCUDA - кодер.
  • x264 OpenCL - незначительная поддержка OpenCL.
  • imagemagick - незначительная поддержка OpenCL.
  • tesseract - поддержка OpenCL.
  • SiftGPU - поддержка ускорения в Sift на GPU через GLSL.
  • Shotcut - видеоредактор с поддержкой ускорения на GPU через GLSL.

В общем случае не совсем для дома: Создание компьютерной графики

  • Blender - поддержка OpenCL и CUDA
  • LuxRender - система рендеринга трёхмерных сцен, поддержка OpanCL.
  • Bullet - движок с поддержкой OpenCL

Какие нативные приложения для обработки видео имеют поддержку OpenCL или CUDA? И какие ещё интересные и полезные приложения для домашнего использования умеют использовать OpenCL, GLSL, CUDA или их поддержку планируют добавить в обозримом будущем?

P.S.
Всякий софт «сгенери_мне_виртуальную_денюжку» или «у_меня_нет_денег_на_интернет_подбери_пароль_к_wifi_соседа» совсем не интересен.

 , , , ,

grem ()