Линус Торвальдс представил (https://lkml.org/lkml/2012/5/20/126) релиз ядра Linux 3.4 (http://kernel.org/). Из основных улучшений можно отметить интеграцию поддержки x32 ABI (64-разрядных режим с 32-разрядными указателями); включение в состав ядра модуль Yama для блокирования некоторых типов атак; механизм dm-verity для проверки целостности хранимых блоков данных по криптографическим хэшам; серию улучшений в реализации Btrfs (повышение производительности работы с метаданными, улучшение обработки ошибок и добавление средств для восстановления файлов с повреждённой ФС); расширение возможностей видеодрайверов (поддержка Nvidia Geforce 600 'Kepler', Intel Medfield, AMD RadeonHD 7xxx и AMD Trinity APU); автоматизацию проверки наличия драйверов для задействования специфичных возможностей x86 CPU; GUI на базе GTK2+ для формирования отчётов для подсистемы perf; возможность использования внешних доступных только на чтение устройство в качестве базового источника LVM-раздела.
В новую версию принято около 10 тысяч исправлений от более чем 1200 разработчиков, размер патча - 42 Мб (изменения затронули 11086 файлов, добавлено 576 тыс. строк кода, удалено 358 тыс. строк). Около 40% всех представленных в 3.4 изменений связаны с драйверами устройств, примерно 30% изменений имеют отношение к обновлению кода специфичного для аппаратных архитектур, 13% связано с сетевым стеком, 5% - файловыми системами и 6% c внутренними подсистемами ядра.Наиболее интересные новшества (http://kernelnewbies.org/Linux_3.4) ядра 3.4:
-
Память и системные сервисы- В ядро интегрированы (https://www.opennet.ru/opennews/art.shtml?num=33142) наработки проекта X32 (https://sites.google.com/site/x32abi/), в рамках которого разработан гибридный x86_64 ABI с 32-разрядной адресацией памяти. X32 представляет собой прослойку поверх стандартного x86_64 ABI ядра, позволяющую использовать на 64-разрядных системах 32-разрядную модель адресации памяти. ABI X32 позволяет приложениям использовать все преимущества архитектуры x86_64, такие как дополнительные регистры и более быстрые инструкции, PIC ABI. В то же время ABI X32 даёт возможность работать с 32-разрядными указателями памяти, что позволяет экономить память, способствует более эффективному наполнению процессорного кэша и положительно сказывается на общей скорости исполнения кода. При тестировании (http://www.linuxplumbersconf.net/2011/ocw//system/presentati...) в ситуациях, связанных с интенсивной работой с указателями, новый ABI продемонстрировал ускорение исполнения кода вплоть до 30% в сравнении с классическим x86_64 ABI. Ограничением ABI X32 является невозможность адресации из приложения более 4 Гб памяти;
- Поддержка автоматической проверки необходимости загрузки дополнительных драйверов (autoprobing) для задействования специфичных возможностей x86 CPU. Ранее для загрузки данных драйверов создателям дистрибутивов приходилось придумывать обходные пути, основанные на субъективных методах, которые не всегда работали. Например, часто возникали проблемы с загрузкой модуля CRC, использующего для ускорения работы инструкции SSE 4.2. В результате того, что нужный CRC-модуль не загружался, наблюдалось заметное понижение производительности подсистем, требующих быстрого вычисления контрольных сумм (например, Btrfs). Другой проблемой был выбор корректного для текущего CPU модуля с поддержкой CPUFREQ - дистрибутивы просто пытались последовательно перебрать все доступные модули, пока один из них не заработает. Теперь данные проблемы остались в прошлом и нужные модули могут быть автоматически загружены при помощи стандартные механизмов автозагрузки udev, на основании предоставленных ядром уведомлений (проверка выполняется на основании флагов cpuid по связке вендор/семейство/модель, как и для других драйверов);
- Расширение возможностей инструментария perf для использования встроенной в ядро отладочной подсистемы Performance Events (http://wiki.opennet.ru/Performance_Events). Представлен GUI-интерфейс на базе библиотеки GTK+ для наглядного анализа отчётов, генерируемых командой 'perf report' (запускается через "perf report --gtk"). Улучшена визуализация при выполнении 'perf annotate'. Добавлена возможность профилирования веток с задействованием аппаратных механизмов CPU. Реализована возможность фильтрации вывода по пользователям (например, "perf top --uid 1000") и отдельным нитям (например, "perf top -p 21483,21485");
-
Дисковая подсистема, ввод/вывод и файловые системы- Расширение возможностей файловой системы Btrfs:
- Добавлена новая утилита btrfs-restore (https://btrfs.wiki.kernel.org/index.php/Restore) для выполнения недеструктивного восстановления файлов с повреждённой ФС - утилита не занимается непосредственным восстановлением целостности ФС, а лишь пытается выделить и отдельно сохранить файлы из повреждённой ФС;
- В утилиту fsck добавлена начальная поддержка восстановления целостности повреждённой ФС (опция "--repair"). В настоящее время реализована только поддержка восстановления повреждений в дереве распределения экстентов;- Возможность работы с блоками метаданных, размер которых превышает 4 Кб (вплоть до 64 Кб). Наиболее хорошие результаты наблюдаются при использовании блоков в 16 или 32 Кб, которые теперь рекомендуется использовать. При использовании блоков в 16 или 32 Кб наблюдается существенное уменьшение размера дерева распределения экстентов и уменьшение фрагментации. Размер блоков может быть задан на этапе создания ФС через утилиту mkfs (например, "mkfs.btrfs -l 32K"). Отмечается, что возможность работы с блоками разного размера была изначально заложена в архитектуру Btrfs, но данная функция была отключена из-за неготовности кода (использовались только блоки размером 4 Кб, соответствующие размеру страницы памяти для систем x86);
- Улучшение производительности Btrfs в нескольких областях. Отмечается изменение метода взаимодействия метаданных со страничным кэшем и увеличение агрессивности отбрасывания страниц для метаданных, ставших ненужными. Проведена работа по снижению нагрузки на CPU в процессе работы. Сокращено число лишних чтений данных в процессе взаимодействия механизма copy-on-write и Linux VM. К увеличению производительности также приводит использование увеличенного размера блоков метаданных, за счёт снижения накладных расходов на обработку дерева распределения экстентов и общего снижения фрагментации данных.
В итоге, удалось заметно повысить производительности в конфигурациях, связанных с интенсивной работой с метаданными. Например, при выполнении теста по созданию 32 миллионов пустых файлов Btrfs теперь обеспечивает создание 170 тыс. файлов в секунду. Для сравнения, в данном тесте ext4 позволяет создавать 110 тыс. файлов в секунду, а XFS - 115.000 тыс. файлов в секунду;- Интеграция подготовленных проектом SUSE патчей (http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6...) с улучшением обработки ошибочных ситуаций. Надлежащая обработка подобных непредвиденных ситуаций ранее не была реализована во многих функциях Btrfs, которые в случае выявления проблем просто останавливали работу системы, переходя в режим "паники". В новой версии ядра проведён аудит обработки ошибок и реализована возможность в случае проблем прервать выполнение ошибочной транзакции и перейти в режим только для чтения, не прерывая функционирования системы.
- Возможность подключения внешнего хранилища, доступного в режиме только для чтения в качестве основы для создания типовых LVM-разделов. Например, для систем виртуализации можно подготовить базовый образ виртуального окружения, на основе которого сформировать LVM-разделы для клиентов, которые будут использовать неизменные данные из одной эталонной области, т.е. на все такие LVM-разделы будет использована только одна копия изначальных данных. При такой конфигурации все обращения на чтение неизменных данных...
URL: https://lkml.org/lkml/2012/5/20/126
Новость: https://www.opennet.ru/opennews/art.shtml?num=33888
> В ядро интегрированы наработки проекта X32, в рамках которого разработан гибридный x86_64 ABI с 32-разрядной адресацией памяти.Это же замечательно! Можно ли теперь говорить, что x64 архитектура не нужна?
Нет, нельзя, во многих приложениях если и не нужно 4Гб+ собственно памяти, то необходимость mmap-ить файлы всеравно остается.
Кто подскажет, как собрать приложение с этим x32 ABI? И какой там размер int - 32 или 64 бита?
Если имеется в виду int в сишечке, то он не может быть больше 32 бит. Так как long int это 32 бита, а int не более long int. 64 бита это отдельный тип int64_t, например.
Вы неправы, стандартом гарантируется только что int имеет размер не меньше 16 байт, и не больше long int, который в свою очередь не больше long long int. Остальное на выбор авторам компилятора, но, как правило, sizeof(int) == размеру машинного слова, 32 бита на х86 и 64 на х86_64.
> как правило, sizeof(int) == размеру машинного слова, 32 бита на х86 и 64 на х86_64Это вы где-то уникальных особенностей компилятор нашли.
Я много с чем работал, но на всех известных мне 64-битных архитектурах sizeof(int)==4, а вот уже sizeof(long)==8
"много с чем" ? галстук красный сними, потом делай громкие заявления.
> "много с чем" ? галстук красный сними, потом делай громкие заявления.Не имею привычки заниматься сравнительным анализом размеров, но по моей довольно своеобразной работе мне пришлось иметь дело с действительно разнообразными компиляторами, каждый со своими особенностями. Поскольку примерный перечень я ниже привел, не поленюсь сюда скопипастить, специально для людей в синих галстуках:
1. GCC
2. MSVC
3. HP aCC под UNIX и OpenVMS
4. Intel C++ Compiler
5. IBM XL C/C++
В данный момент gcc, msvc, intel, clang:x86:
short - 16 бит
int == long - 32 бита
long long - 64 битаx86_64:
short - 16 бит
int - 32 бита
long == long long - 64 бита
> long == long long - 64 бита... поэтому нормальные люди давно уже открыли для себя (u)intXX_t и тому подобные типы, избавленные от этого кретинизма :)
то да, long long - там еще клиника на дому.. но то был лишь c99
новых сверхвысот моразма аворы добились в с11
> новых сверхвысот моразма аворы добились в с11к счастью, его можно не читать (как я и сделал), а для gcc использовать -std=gnu99.
Ну может быть. Я все равно взял себе за правило четко указывать размер переменной int_32_t, int64_t, и предельно редко использовать стандартный int.
Ага и адресовать память через int_32_t, int64_t и макрос, нормально мы любим велосипеды, на хрена нам рекомендованный long.
Уже есть рекомендованный костыль - size_t.
size_t - не костыль, у него есть свои обязанности.
Для адресации памяти *обязательно* использовать intptr_t и ptrdiff_t
Тут можут быть особенность моей работы - кроссплатформенная реализация всяких бинарных протоколов, где нельзя иметь типы данных с плавающим размером.
вообще это это uintptr_t, стандарт.
int специально оставили равным 4 во многих компиляторах чтобы старый былокод не обосрался кирпичами при компиляции на 64х битных платформах.
> int специально оставили равным 4 во многих компиляторах чтобы старый былокод не
> обосрался кирпичами при компиляции на 64х битных платформах.Это безнадежно, он обсирается по куче иных поводов. Посмотрите на колчиество проприетарных 64-битных программ и скорость их выпуска. Что, по пальцам можно пересчитать? Ну вот вам и ответ о быдлокоде. Да, понятно что если сорц не показывать - возникает соблазн схалтурить. И это имеет свою цену...
> Да, понятно что если сорц не показывать — возникает соблазн схалтурить. И это имеет свою
> цену…ну почему сразу «схалтурить». компромисс между красотой и скоростью выпуска. если руководство во время создания софта не рассматривало 64-битные платформы как серьёзный рынок, то с чего программистам на это было затачиваться?
работу надо сдать в срок. работу надо сдать работающую. если «писать переносимый код» в ТЗ не было, то не надо писать переносимый код. это не FOSS, это контрактная работа. если нанять строителей, и они выстроят вместо заказаной кирпичной коробки 10x10x3 бункер из армированого железобетона (завалив при этом сроки), то вряд ли заказчик останется доволен.
> Вы неправы, стандартом гарантируется только что int имеет размер не меньше 16 байтВы неправы. Стандартом C/C++ гарантируется только то, что sizeof(char) <= sizeof(short) <= sizeof(int) <= sizeof(long) <= sizeof(long long). Даже не гарантируется, что в char 8 бит.
"Стандарта С/С++" в природе нету - это два разных языка. Я писал про Си, в котором sizeof char == 1.
> «Стандарта С/С++» в природе нету — это два разных языка. Я писал
> про Си, в котором sizeof char == 1.вот только это «1» не обязательно 8 бит. это машинный байт. будет машина с шестибитными байтами — будет в этой единице шесть битов. по-моему, именно так.
впрочем, могу и ошибаться: если ошибся, извиняюсь за дезу.
> вот только это «1» не обязательно 8 бит. это машинный байт. будет
> машина с шестибитными байтами — будет в этой единице шесть битов.Ага.
Есть системы, где клавиша DEL необязательно отправляет сигнал DEL. (С) FreeBSD'оиды
У нормальных людей DEL - это DEL. Пофиг, как у остальных. (C) Linux'оидыЗато признаем системы с 6 битами в байте.
что сказать-то хотел?
> что сказать-то хотел?За многими компами сидели, где в байте 6 битов?
что сказать-то хотел по теме, убогий?
>> Вы неправы, стандартом гарантируется только что int имеет размер не меньше 16 байт
> Вы неправы. Стандартом C/C++ гарантируется только то, что sizeof(char) <= sizeof(short)
> <= sizeof(int) <= sizeof(long) <= sizeof(long long). Даже не гарантируется, что
> в char 8 бит.Угу, вот именно..
Всё, на что ссылается Стандарт, - CHAR_BIT в <limits.h>
- количество битов для наименьшего из объектов, не являющегося битовым полем
При этом, значение должно лежать в пределах [8, бесконечность]
Что уж там набыдлокодят китайские братья Чон в своем компиляторе - дело десятое,
и они будут безусловно правы, а всякие птушники из соседней ветки с заверениями вида: "Я много с чем работал, но на всех известных мне 64-битных архитектурах sizeof(int)==4, а вот уже sizeof(long)==8" - нет :)
> При этом, значение должно лежать в пределах [8, бесконечность]разве?
> Угу, вот именно..
> Всё, на что ссылается Стандарт, - CHAR_BIT в <limits.h>
> - количество битов для наименьшего из объектов, не являющегося битовым полем
> При этом, значение должно лежать в пределах [8, бесконечность]
> Что уж там набыдлокодят китайские братья Чон в своем компиляторе - дело
> десятое,
> и они будут безусловно правы, а всякие птушники из соседней ветки с
> заверениями вида: "Я много с чем работал, но на всех известных
> мне 64-битных архитектурах sizeof(int)==4, а вот уже sizeof(long)==8" - нет :)Хоть мне и не довелось учиться в ПТУ, о великий Гуру программирования cvsup1,
со стандартами я вполне знаком. Опираться в реальной разработке на его, прямо скажем,
нежесткие требования - значит сильно терять в эффективности кода.Равно как я бы никому не рекомендовал применять компилятор от "китайских братьев Чон",
которые действительно могут натворить в нем что угодно - вплоть до явного и
преднамеренного нарушения стандарта языка.Что же касается *приличных* компиляторов, то они ведут себя на данный момент
именно так, как я написал "в соседней ветке". Список приличных компиляторов
включает в себя:
1. GCC
2. MSVC
3. HP aCC под UNIX и OpenVMS
4. Intel C++ Compiler
5. IBM XL C/C++С Clang поработать не довелось, но шибко подозреваю, что и там в 64-битном режиме
все то же самое.
вот насчёт чара вроде как гарантируется, что это машинный байт, емнип. просто у нас сейчас нет, в принципе, машин с невосьмибитными байтами.
>long int это 32 битаНа x86_64 long int - 64 бита.
Довольно наглядная таблица
http://www.viva64.com/media/images/content/a/64-bit-migratio...
Только long int в 64-битной системе будет 8 байт в отличии от 32-битной, где он будет 4 байта. int - да, и там и там 4 байта.
Пруф: http://www.gnuplanet.ru/main/topic.php?topic_id=3246&rnd=753... (в конце)
> Пруф: http://www.gnuplanet.ru/main/topic.php?topic_id=3246&rnd=753... (в конце)Это не пруф, это такое же быдлокодеро как и тут.
--
Intel® 64 and IA-32 Architectures Software Developer’s Manual Combined Volumes:1, 2A, 2B, 2C, 3A, 3B, and 3C
http://www.intel.com/content/www/us/en/processors/architectu...
4.1
FUNDAMENTAL DATA TYPES
The fundamental data types are bytes, words, doublewords, quadwords, and double
quadwords (see Figure 4-1). A byte is eight bits, a word is 2 bytes (16 bits), a
doubleword is 4 bytes (32 bits), a quadword is 8 bytes (64 bits), and a double quad-
word is 16 bytes (128 bits). A subset of the IA-32 architecture instructions operates
on these fundamental data types without any additional operand typing.The quadword data type was introduced into the IA-32 architecture in the Intel486
processor; the double quadword data type was introduced in the Pentium III
processor with the SSE extensions.
Figure 4-2 shows the byte order of each of the fundamental data types when refer-
enced as operands in memory. The low byte (bits 0 through 7) of each data type
occupies the lowest address in memory and that address is also the address of the
operand.4.2
NUMERIC DATA TYPES
Although bytes, words, and doublewords are fundamental data types, some instruc-
tions support additional interpretations of these data types to allow operations to be
performed on numeric data types (signed and unsigned integers, and floating-point
numbers). Single-precision (32-bit ) floating-point and double-precision (64-bit)
floating-point data types are supported across all generations of SSE extensions and
Intel AVX extensions. Half-precision (16-bit) floating-point data type is supported
only with F16C extensions (VCVTPH2PS, VCVTPS2PH).4.2.1 Integers
The Intel 64 and IA-32 architectures define two types of integers: unsigned and
signed. Unsigned integers are ordinary binary values ranging from 0 to the maximum
positive number that can be encoded in the selected operand size. Signed integers
are two’s complement binary values that can be used to represent both positive and
negative integer values.
Some integer instructions (such as the ADD, SUB, PADDB, and PSUBB instructions)
operate on either unsigned or signed integer operands. Other integer instructions
(such as IMUL, MUL, IDIV, DIV, FIADD, and FISUB) operate on only one integer type.
The following sections describe the encodings and ranges of the two types of
integers.4.2.1.1 Unsigned Integers
Unsigned integers are unsigned binary numbers contained in a byte, word, double-
word, and quadword. Their values range from 0 to 255 for an unsigned byte integer,
from 0 to 65,535 for an unsigned word integer, from 0 to 232 – 1 for an unsigned
doubleword integer, and from 0 to 264 – 1 for an unsigned quadword integer.
Unsigned integers are sometimes referred to as ordinals.4.2.1.2 Signed Integers
Signed integers are signed binary numbers held in a byte, word, doubleword, or
quadword. All operations on signed integers assume a two's complement representa-
tion. The sign bit is located in bit 7 in a byte integer, bit 15 in a word integer,
bit 31 in a doubleword integer, and bit 63 in a quadword integer he sign bit is set
for negative integers and cleared for positive integers and zero.
Integer values range from –128 to +127 for a byte integer, from –32,768 to +32,767
for a word integer, from –231 to +231 – 1 for a doubleword integer, and from –263 to
+263 – 1 for a quadword integer.
When storing integer values in memory, word integers are stored in 2 consecutive
bytes; doubleword integers are stored in 4 consecutive bytes; and quadword inte-
gers are stored in 8 consecutive bytes.
The integer indefinite is a special value that is sometimes returned by the x87 FPU
when operating on integer values. For more information, see Section 8.2.1, “Indefi-
nites.”4.3
POINTER DATA TYPES
Pointers are addresses of locations in memory.
In non-64-bit modes, the architecture defines two types of pointers: a near pointer
and a far pointer. A near pointer is a 32-bit (or 16-bit) offset (also called an effec-
tive address) within a segment. Near pointers are used for all memory references in
a flat memory model or for references in a segmented model where the identity of
the segment being accessed is implied.
A far pointer is a logical address, consisting of a 16-bit segment selector and a 32-bit
(or 16-bit) offset. Far pointers are used for memory references in a segmented
memory model where the identity of a segment being accessed must be specified
explicitly. Near and far pointers with 32-bit offsets are shown in Figure 4-4.4.3.1 Pointer Data Types in 64-Bit Mode
In 64-bit mode (a sub-mode of IA-32e mode), a near pointer is 64 bits. This
equates to an effective address. Far pointers in 64-bit mode can be one of three
forms:• 16-bit segment selector, 16-bit offset if the operand size is 32 bits
• 16-bit segment selector, 32-bit offset if the operand size is 32 bits
• 16-bit segment selector, 64-bit offset if the operand size is 64 bits
GCC совместим с ISO C99 http://gcc.gnu.org/onlinedocs/gcc-4.7.0/gcc/Integers-impleme...С99 говорит, что int это такая хрень, в которую можно
всунуть число между INT_MIN и INT_MAX живущие в <limits.h>http://c0x.coding-guidelines.com/6.2.5.html
#include <stdio.h>
#include <limits.h>
#include <math.h>int main() {
printf("short %lf bit\n", log2((double)SHRT_MAX) + 1);
printf("ushort %lf bit\n", log2((double)USHRT_MAX));
printf("int %lf bit\n", log2((double)INT_MAX) + 1);
printf("uint %lf bit\n", log2((double)UINT_MAX));
printf("long %lf bit\n", log2((double)LONG_MAX) + 1);
printf("ulong %lf bit\n", log2((double)ULONG_MAX));
printf("long long %lf bit\n", log2((double)LLONG_MAX) + 1 );
printf("ulong long %lf bit\n", log2((double)ULLONG_MAX));return 0;
}
> С99 говорит, что int это такая хрень, в которую можно
> всунуть число между INT_MIN и INT_MAX живущие в <limits.h>И правильно говорит: всё согласно ГОСТу^W Стандарту :)
Так что стандарт Си в этом месте сам себе не противоречит :)
> Если имеется в виду int в сишечке, то он не может быть
> больше 32 бит. Так как long int это 32 бита, а
> int не более long int. 64 бита это отдельный тип int64_t,
> например.дорогой, скажи, пожалуйста: не мог ли я случайно использовать софт, где ты участие принимал? если да, то какой. чтобы я начал немедленно замены искать.
> Это же замечательно!На десктопе!
> что x64 архитектура не нужна?Разве? Гимп вот только учится 16, 32-разрядному цвету. Так что потребность в полноценной x68_64 никуда не девается. Да и даже из новости видно, что x32 из-под x86_64 работает. В этом-то и смысл!
> Разве? Гимп вот только учится 16, 32-разрядному цвету. Так что потребность в
> полноценной x68_64 никуда не девается.При чем здесть 16-32бита на канал в Гимпе и x86_64?
Все просто. 16ти, и, тем более, 32-битные фотки памяти занимают вагон и маленькую тележку. А если у нас несколько слоев, да undo в памяти на сколько-то там действий, да картинка не одна. В общем, памяти для графического редактора много не бывает :)
не пишите пожалуйста больше тут
> Можно ли теперь говорить, что x64 архитектура не нужна?"640Кб хватит всем" - 2.0 edition? :)
>Можно ли теперь говорить, что x64 архитектура не нужна?Тебе -- можно. На опеннете ещё и не такой ф. писали.
Кто пропатчит 64-битный Фокс для работы через X32? Толк от этого определённо должен быть.
Нет, серьёзно. Более 4 Гб памяти фоксу определённо не нужно, так что вин определённый. Хром вот на 64 бита переводить не желали в том числе и из-за 64-битной адресации памяти.
Хром всегда может нафоркать кучу процессов, каждый из которых займет по 4 гига. Есть куда расти!
Чур тебя. Он и так жрёт как не в себя при паре десятков активных табов.
Помнится Chromium изначально был под amd64, а под Windows не портируют, потому-что Google лень.
> Модуль "verity" для Device Mapper, позволяющий обеспечить проверку неизменности загружаемых данных с точки зрения их возможной модификации злоумышленниками. Проверка выполняется через сверку считанных с накопителя блоков файловой системы с сохранёнными в отдельной области криптографическими хэшами (используется древовидная структура хэша, в которой каждый элемент учитывает содержимое соседей, а проверка корректности корневого элемента осуществляется с использованием методов асимметричного шифрования). Если элемент хэша не совпадает, то операция чтения завершается ошибкой.Да дело не только в злоумышленниках. Это же по сути сквозное чексуммирование для любой ФС, независимо от ее типа.
А еще оно решает неоднозначность с восстановлением mdraid1, когда данные с зеркал не совпадают, а сообщений об ошибках чтения с диска нет (например, если запортить данные с помощью dd, как любят делать фанаты ZFS). Достаточно просто создавать зеркала поверх verity-устройств.
> А мешало то, что ядро не сообщало о фичах CPU. Теперь сообщает.Точнее говоря, о модулях, необходимых для поддержки этих фич.
> systemd - это не маргиналы, это мейнстрим.мейнстрим теперь федора и опенсусе. буду знать.
Федора является мейнстримом уже лет 10. До нее был Red Hat Linux.
> Федора является мейнстримом уже лет 10. До нее был Red Hat Linux.ну правильно. всякие редхаты с центосами и дебианы с убунтами - это маргиналы, а федора и опенсусе, которые в сумме дай бог, чтоб десять процентов от общего числа установок имеют, - мейнстрим, ага.
А вы не забыли, что обсуждаете init-подсистемы и распространять их маргинальность/мэинстримность их на дистрибутивы, в которых они используются, мягко говоря несколько некорректно? Хоть один из перечисленных дистрибутивов перестал быть нужен, хоть и всё ещё выполняет свои функции?
> А вы не забыли, что обсуждаете init-подсистемы и распространять их маргинальность/мэинстримность
> их на дистрибутивы, в которых они используются, мягко говоря несколько некорректно?я распространяю наоборот. init система не существует сама по себе, и станет мейнстримом, когда ее начнут применять мейнстримные дистро.
в любом случае, как это изменит факт, что у init с upstart в ближайщие лет пять оснований называться мейнстримом по-прежнему будет несколько побольше, чем у systemd?
> Хоть один из перечисленных дистрибутивов перестал быть нужен, хоть и всё
> ещё выполняет свои функции?не имеет значения.
> в любом случае, как это изменит факт, что у init с upstart в ближайщие лет пять оснований называться мейнстримом по-прежнему будет несколько побольше, чем у systemd?Это какие же у upstart основания?
Мы же прекрасно понимаем, что несмотря на все громкие заявления, в убунте он долго не протянет (ну не осилят они собственные форки udev и ConsoleKit, они же не разработчики, а дизайнеры и маркетологи). Год, максимум два - и апстарту каюк.Кроме того, когда перед разработчиками ядра Linux встанет вопрос выбора между systemd и upstartом - ответ вполне очевиден. Патриоты upstartа разработкой ядра почти не занимаются, знаете ли :)
> Это какие же у upstart основания?
> Мы же прекрасно понимаем, что несмотря на все громкие заявления, в убунте
> он долго не протянет (ну не осилят они собственные форки udev
> и ConsoleKit, они же не разработчики, а дизайнеры и маркетологи). Год,
> максимум два - и апстарту каюк.вы, может, и понимаете, а я - нет. я вот не уверен, что редхат будет посреди одного мажора выпиливать инит систему и менять ее на новую, как и центос с оракл линуксом не станут отрываться от коллектива. насчет убунты мне вот тоже не очевидно - там апстарт уже сколько времени пилится и наконец-то начал принимать вменяемый вид - по крайней мере, в последнем релизе он _работает_, не треюуя к себе особого внимания, в отличие от systemd, который в свежейустановленной(!) опенсусе 12.1 только и делал что ежесекундно гадил в лог ошибками. и что, будут гробить в борьбе лучшего с хорошим еще один-два релиза? Не уверен. тем более, что деньги у Марка еще не кончились, и человек он упря^Wцелеустремленный, как показывает пример Юнити, написанной маркетологами и дизайнерами, про которых тоже говорили "ниасилят".
что касается консолекита - то я вообще не понимаю, накой оно вообще было нужно, кроме перделки под названием "переключение пользователя", которой никто не пользуется, и т.н. мультисита, который и под виндами-то нафиг никому не нужен был все эти годы.
> Кроме того, когда перед разработчиками ядра Linux встанет вопрос выбора между systemd
> и upstartом - ответ вполне очевиден. Патриоты upstartа разработкой ядра почти
> не занимаются, знаете ли :)эм, это замечание мне не понятно - что, Поттеринг наш предложил интегрировать в системд еще и ядро???
> что касается консолекита - то я вообще не понимаю, накой оно вообще
> было нужно, кроме перделки под названием "переключение пользователя", которой никто не
> пользуется, и т.н. мультисита, который и под виндами-то нафиг никому не
> нужен был все эти годы.если под мультиситом понимается одновременная работа нескольких пользователей, то тут имеет место быть нелюбовь МС к таким вещам: лицензия одна, а рабочих мест несколько.
> я вот не уверен, что редхат будет посреди одного мажора выпиливать инит систему и менять ее на новую, как и центос с оракл линуксом не станут отрываться от коллектива.Посреди мажора - не будут. Но и разрабатывать его не будут, только поддерживать.
Ну а кто будет initом в RHEL7 (CentOS 7, OL7) - очевидно уже сейчас.> насчет убунты мне вот тоже не очевидно - там апстарт уже сколько времени пилится и наконец-то начал принимать вменяемый вид - по крайней мере, в последнем релизе он _работает_, не треюуя к себе особого внимания
Сейчас его пилит только гугл, в плане заточки под хромоось (и разработчиков из каноникал сманил). Вряд ли убунту, практически не имеющую собственных разработчиков, устраивает такой курс развития.
> как показывает пример Юнити, написанной маркетологами и дизайнерами, про которых тоже говорили "ниасилят"
Разумеется. Это же просто темка для GNOME3, нарисованная дизайнерами и пропиаренная маркетологами. Разработчики для таких проектов не требуются.
> Посреди мажора - не будут. Но и разрабатывать его не будут, только
> поддерживать.
> Ну а кто будет initом в RHEL7 (CentOS 7, OL7) - очевидно
> уже сейчас.не тупите. в RHEL6 upstart уже сейчас, и что? все быстренько обновились и кругом upstart?
> Сейчас его пилит только гугл, в плане заточки под хромоось (и разработчиков
> из каноникал сманил). Вряд ли убунту, практически не имеющую собственных разработчиков,
> устраивает такой курс развития.вы в курсе, сколько в каноникал разработчиков, или так просто лулзов подоставлять пришли?
> Разумеется. Это же просто темка для GNOME3, нарисованная дизайнерами и пропиаренная маркетологами.
> Разработчики для таких проектов не требуются.просто темка для gnome 3. господи, чего только на опеннете не наслушаешься. а также они там clutter выбросили и запилили старый wm вместо нового гомовского. но в целом - чиста темка, не требующая девелоперов. вынимательно вас слушаю дальше.
>> Разумеется. Это же просто темка для GNOME3
> просто темка для gnome 3. господи, чего только на опеннете не наслушаешься.Видимо, с цитрамоном перепутали... (и то не темка, а расширение тогда уж -- ну и как там дальше в анекдоте было)
а вот кто-нибудь мне пояснит, что такое consolekit, зачем оно надо, и что я теряю, не имея его в системе?ставить я пробовал, ничего улучшеного не заметил. снёс. тоже ничего не отвалилось. читал интернеты. не понял.
точнее, я понял, что это ненужный крап какой-то. но, возможно, я не прав?
> а вот кто-нибудь мне пояснит, что такое consolekit, зачем оно надо, и
> что я теряю, не имея его в системе?
> ставить я пробовал, ничего улучшеного не заметил. снёс. тоже ничего не отвалилось.
> читал интернеты. не понял.
> точнее, я понял, что это ненужный крап какой-то. но, возможно, я не
> прав?http://ru.wikipedia.org/wiki/PolicyKit
http://www.freedesktop.org/wiki/Software/ConsoleKitНапоминает API для "улучшенного" sudo.
Порадовало:
ConsoleKit is currently not actively maintained. The focus has shifted to the built-in seat/user/session management of Software/systemd called systemd-loginctlНе успели в нем разобраться, а он уже заменяется systemd-loginctl)
В deb-based его тоже чем-то заменяют.
я вполне в состоянии спросить у гугеля, tnx. меня таки интересует, что в нём инновационного, что его везде пихают. ну, кроме того, что какие-то дурацкие DE его хотят.
> ну правильно. всякие редхаты с центосами и дебианы с убунтами - это
> маргиналы, а федора и опенсусе, которые в сумме дай бог, чтоб
> десять процентов от общего числа установок имеют, - мейнстрим, ага.Редхаты с центосами (и ораклами) - это тоже мейнстрим, просто с отставанием по времени. Например, от Upstart в федоре уже давно отказались, а в RHEL6 и его клонах он пока сохраняется (systemd по умолчанию можно ожидать не ранее, чем в RHEL7).
Насчет дебиана и генты разработчики ядра уже предупреждали - мол, фрибсд вам дороже линукса, ну и катитесь колбаской.
> Редхаты с центосами (и ораклами) - это тоже мейнстрим, просто с отставанием
> по времени. Например, от Upstart в федоре уже давно отказались, а
> в RHEL6 и его клонах он пока сохраняется (systemd по умолчанию
> можно ожидать не ранее, чем в RHEL7).а это у нас с вами разные понятия о мейнстриме. у вас мейнстрим - очередной shitkit запиленный в самой последней федоре, а для меня - то, с чем приходится постоянно сталкиваться на 30%-20% установок.
> Насчет дебиана и генты разработчики ядра уже предупреждали - мол, фрибсд вам
> дороже линукса, ну и катитесь колбаской.Дреппер тоже однажды Дебиан предупреждал.
> а это у нас с вами разные понятия о мейнстриме. у вас
> мейнстрим - очередной shitkit запиленный в самой последней федоре, а для
> меня - то, с чем приходится постоянно сталкиваться на 30%-20% установок.Все равно этот shitkit придет в убунту. Только чуть позже (потому что она - только копипастер, а не первоисточник).
> Дреппер тоже однажды Дебиан предупреждал.
Это по поводу "рандомных" ключей у OpenSSH? Да, дебиан тогда красиво лажанулся.
> Это по поводу "рандомных" ключей у OpenSSH?OpenSSL.
> Насчет дебиана и генты разработчики ядра уже предупреждали - мол, фрибсд вам
> дороже линукса, ну и катитесь колбаской.Не все разработчики ярда, а только торлли из RedHat-а.
Вот мы и докатились до того, что всей низкоуровневой экосистемой линукса заправляет одна кампания, которая диктует свои условия сообществу. Печально.
Короче, нужно форкать udev, выпиливать *kit-ы и выдавливать RedHat из сферы слияния на экосистему.
> Не все разработчики ярда, а только торлли из RedHat-а.Разработчики Linux, проще говоря.
> Вот мы и докатились до того, что всей низкоуровневой экосистемой линукса заправляет одна кампания, которая диктует свои условия сообществу. Печально.
Кто разрабатывает, тот и определяет направления развития.
> Короче, нужно форкать udev, выпиливать *kit-ы и выдавливать RedHat из сферы слияния на экосистему.
Прекрасный план, займитесь на досуге :D
>Кто разрабатывает, тот и определяет направления развития.Не стОит только совсем игнорировать тот факт, что над каждым фултаймером стоит управленец, который, как правило, указывает ему что делать, в то время как разработчик решает, как он будет это делать. Иногда происходит и наоборот, но правда редко. Кроме этого, над каждым таким управленцем обычно нависают мрачные фигуры заинтересованных продаванов во главе с исполнительным директором, которому, заметим, им всем платить зарплату...
> ну правильно. всякие редхаты с центосами и дебианы с убунтами - это
> маргиналы, а федора и опенсусе, которые в сумме дай бог, чтоб
> десять процентов от общего числа установок имеют, - мейнстрим, ага.Конечно. Фичи ведь таскают из федоры в убунту, а не наоборот.
настоящие анонимы не только по ссылкам не ходят, но и новость не читают>В состав ядра включён модуль Yama, разработанный компанией Canonical и используемый в Ubuntu для блокирования некоторых типов атак.
ггг кстати security.bsd.hardlink_check_gid передавал привет братьям по разуму из далекого 2006 года.
>> В состав ядра включён модуль Yama, разработанный компанией Canonical
>> и используемый в Ubuntu для блокирования некоторых типов атак.
> ггг кстати security.bsd.hardlink_check_gid передавал привет братьям по разуму
> из далекого 2006 года.Далёкого? В 2006 или 2007 lakostis@ сделал частичный порт того самого соларовского ow patch на Linux 2.6, включая и restricted symlinks. А накладывали оригинал на 2.0.x в конце девяностых ещё, помнится.
ключевое слово - "включен в состав ядра" :)
> ключевое слово - "включен в состав ядра" :)Microsoft и то больше кода в состав ядра включила :)
> настоящие анонимы не только по ссылкам не ходят, но и новость не читают
>>В состав ядра включён модуль Yama, разработанный компанией Canonical и используемый в Ubuntu для блокирования некоторых типов атак.Очень важное замечание :)
Сколько процентов представляют эти 50 строчек по сравнению с кодом, внесенным редхатом за все время разработки Linux?
>> настоящие анонимы не только по ссылкам не ходят, но и новость не читают
>>>В состав ядра включён модуль Yama, разработанный компанией Canonical и используемый в Ubuntu для блокирования некоторых типов атак.
> Очень важное замечание :)
> Сколько процентов представляют эти 50 строчек по сравнению с кодом, внесенным редхатом
> за все время разработки Linux?очень важное замечание от человека, который меряет работу по SLOC. как там у вас погода в Индии?
> настоящие анонимы не только по ссылкам не ходят, но и новость не читают
>>В состав ядра включён модуль Yama, разработанный компанией Canonical и используемый в Ubuntu для блокирования некоторых типов атак.А еще в состав ядра включены паравиртуальные драйверы для Hyper-V, разработанные компанией Microsoft. Причем по объему и сложности код значительно превосходит эту самую яму.
Тем не менее, никто не спрашивает мнения M$ о направлениях развития Linux. И Canonical никто не спрашивает, о чем они давеча заявляли (мол, не спрашивают - а нам и так пофиг, мы не разработчики).
> Тем не менее, никто не спрашивает мнения M$ о направлениях развития Linux.
> И Canonical никто не спрашивает, о чем они давеча заявляли (мол,
> не спрашивают - а нам и так пофиг, мы не разработчики).ггг микрософт это устраивает, они и так с хайперви уже раз в пять kvm по инсталляциям обходят, дальше будет еще больше. если их и спросят, ответ наверняка будет "Верной дорогой идете товарищи правильной!"
>> systemd - это не маргиналы, это мейнстрим.
> мейнстрим теперь федора и опенсусе. буду знать.Как там в пословице. Кто первый поттер^системд ужинает, того и мейнстрим.
> Сейчас некоторые незначимые дистрибутивы еще страдают от немотивированной ненависти к
> systemd, а ведь именно его разработчики продавили эту фичу в ядроДа я и говорю - засунуть фичу сразу в ядро, systemd в юзермоде вообще прибить. И всех будет запускать ядро сразу.
да вообще всё в ядро! а то столько времени тратится на переключение контекстов…
> Да я и говорю - засунуть фичу сразу в ядро, systemd в юзермоде вообще прибить. И всех будет запускать ядро сразу.Сферическая в вакууме аргументация противников systemd.
> Сферическая в вакууме аргументация противников systemd.Я не противник "systemd вообще", а просто сторонник здорового троллинга чрезмерно неуемных личностей перегибающих палку :)
> Указанная возможность уже используется в продуктах Chrome OS и Netflix для того, чтобы гарантировать, что образ системы загружается в неизменном виде;Да здравствует тивоизация!
>Размер блоков может быть задан на этапе создания ФС через утилиту mkfs (например, "mkfs.btrfs -l 32K").Т.е. обновить\сконвертировать существующую фс никак? Опять заново всё заливать?
> Т.е. обновить\сконвертировать существующую фс никак? Опять заново всё заливать?Английским же по белому предупреждали: unstable disk format!
disk format давно стабле.
>>Размер блоков может быть задан на этапе создания ФС через утилиту mkfs (например, "mkfs.btrfs -l 32K").
> Т.е. обновить\сконвертировать существующую фс никак? Опять заново всё заливать?А как вы себе это представляете?
Что слышно по поводу режима wake-lock, для полноценной поддержки Android-устройств? В предыдущем релизе 3.3 упоминалось, что режим будет реализован в ядре 3.4, но в новости об этом не слова. Кто в курсе ситуации?
Для гугления: linux 3.3 android 3.4
с вейк-локами у них там небольшая война была. читал рассылку, в которой автор вейклоков присылал эти патчи, долгое время ядерщики ругались, что этот механизм нелогичен и пересекается с уже существующим в ядре. может и до сих пор не приняли. хотя вроде проделана большая работа по притирке этих вейклоков к мнению ядерщиков и уже должны бы запихнуть. но на самом деле подозреваю, что кроме андроида оно нигде больше не будет использоваться
штука такая, что это нужно только вашему ведроиду, по гамбургскому счёту. ну вот пусть гордые владельцы ведроидов и тянут патчи сами, на кой это всем остальным?
Ульрих Дреппер одобряет ваш пост.
> Ульрих Дреппер одобряет ваш пост.ты, кажется, думал, что язвишь? Ульрих — умный человек, это комплимент.
>думал, что язвишь? Ульрих — умный человек, это комплимент.Ульрих устранился от непринятия патчей. Карму залечивает, видимо. В отличие. Не комплимент.
stop reopening!
> Что слышно по поводу режима wake-lock, для полноценной поддержки Android-устройств? В предыдущем
> релизе 3.3 упоминалось, что режим будет реализован в ядре 3.4, но
> в новости об этом не слова. Кто в курсе ситуации?
> Для гугления: linux 3.3 android 3.4Добавлю. Видимо, грусть-печаль в дружбе пингвина и андроида. Копипаста с одного ресурса:
RankoR:
А 3.3 под Андроид, несмотря на обещанную поддержку, не собиралось. Даже на stackoverflow гуру почесали репу и ответа дать не смогли, почему оно так. Надо 3.4 попробовать :)
>> релизе 3.3 упоминалось, что режим будет реализован в ядре 3.4, но
>> Для гугления:android mainline kernel site:lwn.net
> Добавлю. Видимо, грусть-печаль в дружбе пингвина и андроида. Копипаста с одного ресурса:
> RankoR:
> Даже на
> stackoverflow гуру почесали репу и ответа дать не смогли, почему оно
> так. Надо 3.4 попробовать :)""The Android patches are largely in the mainline at this point (in staging), Kroah-Hartman said, except for the wakelocks code. The 3.3-rc3 kernel can boot an Android user space, but lacks the power management features that wakelocks provide, so battery life is poor. Bergmann said that he had seen a demo of Android running on a mainline kernel, and there is "still a long way to go"."" -- http://lwn.net/Articles/481661/
Но да, с января-февраля (и в цикде 3.4?), вроде, ничего не слышно больше...
> Также Yama поддерживает средства борьбы с атаками через подстановку символических ссылок (следование по символическим ссылкам разрешается в общедоступных каталогах только при совпадении UID ссылки и пытающегося перейти по ссылке процесса) и манипулирование жесткими ссылками (запрещается создание жестких ссылок, если у пользователя нет прав на доступ к файлу, на который направляется ссылка);Нет. В той версии YAMA, которую добавили в ядро, остался только контроль ptrace. Остальные "защиты" выкинули по требованию рецензентов (и правильно, а то захотел сходить по чужому симлинку - пересобери ядро, дух Ubuntu as is).
Кстати, создал его тот же самый человек, который админил kernel.org на момент взлома.
> Кстати, создал его тот же самый человек, который админил kernel.org на момент
> взлома.Эта теория далека от реальности, хотя появилась она не на пустом месте. Насколько мне известно, Kees (и не только он) администрировал систему mirror'ов kernel.org, при этом не отвечая за сами сервера kernel.org и не выбирая политику безопасности. Правильно ли его упрекать за то, что он взялся за такой участок работ, при этом не заставив остальных переделать всё остальное (что, думаю, без взлома и не удалось бы - если посмотреть как сложно продвигаются те же hardening-патчи в ядро)? Думаю, нет.
Также, две из трех обсуждаемых hardening-возможностей (т.е. kernel.yama.protected_sticky_symlinks и kernel.yama.protected_nonaccess_hardlinks, но не kernel.yama.ptrace_scope) исходно разработаны не Kees'ом, а пришли из -ow патчей и долгие годы существовали в grsecurity. Kees обернул их в форму, пригодную для использования в Ubuntu и для потенциального включения в mainline kernel. За что ему спасибо.
> Я обожаю тебя линус// fixed
> В той версии YAMA, которую добавили в ядро, остался только контроль ptrace.Да. А жаль.
> Остальные "защиты" выкинули по требованию рецензентов
Патчи в mainstream-ядра продвигаются по частям. Это не значит, что остальные части не будут включены несколько позже, когда удастся получить ACK'и.
> (и правильно, а то захотел сходить по чужому симлинку - пересобери ядро, дух Ubuntu as is).
Во-первых, говоря именно о симлинках, ограничение распространялось бы лишь на симлинки в каталогах с +t (таких как /tmp). Сознательно ходить по чужим симлинкам в /tmp может быть нужно очень-очень редко (возможно, для проверки какого-нибудь exploit'а). Во-вторых, никакой пересборки ядра не требуется - есть sysctl'ы kernel.yama.protected_sticky_symlinks и kernel.yama.protected_nonaccess_hardlinks. Если не нравится, что эти вещи включены по умолчанию, их можно выключать при загрузке системы с помощью /etc/sysctl.conf. Если такое умолчание не нравится maintainer'ам ядра, оно может быть другим (т.е. эти ограничения могут быть по умолчанию выключены), что на мой взгляд не является существенным поводом не принимать патчи, которые иначе придется продолжать поддерживать на уровне дистрибутивов.
Кстати, по моему опыту, из этих трех ограничений иногда слегка мешает лишь принятое сейчас ограничение ptrace - да и то только при разработке/отладке (возможность не-root'у присоединить отладчик к отдельно запущенному процессу). А еще Wine этому смущается когда Win64-программа падает и он хочет выдать диагностику. Но я тем не менее за наличие этой вещи в ядре. Отключить ее на системах, использующихся для разработки/отладки, не сложно (kernel.yama.ptrace_scope = 0 в /etc/sysctl.conf). Ограничения симлинков и хардлинков же не мешают вообще.
> Ограничения симлинков и хардлинков же не мешают вообще.Когда-то порой мешали -- только догадавшись заглянуть в dmesg, можно было понять, какой privsep'нутый процесс по какому созданному другим privsep'нутым процессом симлинку не пущают ;)
Но в основном они того стоили, конечно. Спасибо.
>> Остальные "защиты" выкинули по требованию рецензентов
> Патчи в mainstream-ядра продвигаются по частям. Это не значит, что остальные части не будут включены несколько позже, когда удастся получить ACK'и.На днях их включили:
http://www.openwall.com/lists/kernel-hardening/2012/08/03/17
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git...
Какой-нибудь дистрибутив уже собрали с x32 abi?
LFS
Гык, они прям как индусы с мозиллы релизы штампуют...
Релиз-цикл 2 месяца.
Несколько лет уже так.
Сижу на 2.6.xxx есть-ли смысл идти даее?
есть для тех, у кого что-то не поддерживается в старом ядре,
хочет использовать новы вкусные фичи,
у кого шило в ...е
Если возникает вопрос, точно не имеет смысла.
> Сижу на 2.6.xxx есть-ли смысл идти даее?Да хоть на 2.4 - кому хуже то...
Еще в этом релизе добавлена начальная поддержка штрихкод сканеров Metrologic (Metrologic MS7120, Metrologic MS9540 Eclipse и подобных).Модуль metro-usb.
Поддерживается Bi-Directional режим эмуляции ком порта.
Поддержка Uni-Directional режима будет в Linux 3.5
Поддержка записи в Bi-Directional режиме ожидается в linux 3.6Бекпортированный модуль на старые ядра тут: https://gitorious.org/other/metro-usb
Вон на новости есть кнопка "исправить", ей можно пользоваться, я серьёзно.
>ей можно пользоваться, я серьёзно.Но не нужно. Ссылки на kernelnewbies достаточно.
> в драйвер rtl8187 добавлена поддержка режима AD-HOC;А в 8192se? А то, как сломалось в 3.0, так и не работает толком ad-hoc :( Приходится использовать 2.6.39.
Где LZ4!?
>Linux 3.4
>GUI на базе GTK2+ для анализаА GTK2+ вообще живо еще? :)
http://git.gnome.org/browse/gtk+/log/?h=gtk-2-24
Последний коммит 7 дней назад
> А GTK2+ вообще живо еще? :)а зачем ему умирать? только потому, что у кого-то свербят свистоперделки? софта много, никуда он не денется.
Нет, я просто спросил, учитывая бесповоротный переход на gtk3... Гном три и все такое. Или то только второй гнум умер, а gtk будет и дальше жить?
> А GTK2+ вообще живо еще? :)Ну да. Потихоньку ползет на GTK3, но пока там вся масса софта раздуплится...
> Потихоньку ползет на GTK3кстати, а зачем? ну, кроме той причины, что разработчики устали от gtk2 (что никак не причина: даже софт на gtk1 до сих пор собирается и работает, хоть и не без некоторого шаманства). что там есть такое убойное, ради чего надо уже позавчера бежать делать поддержку gtk3?
wayland же и корректировка цвета ещё
> wayland же и корректировка цвета ещёкак ты изящно написал «таки не нужно».
ath5k не починили?
> ath5k не починили?Не знаю что там с ath5k но можете считать что он околел в пользу ath9k, который давно уж живет, здравствует, развивается и работает с практически всеми чипами атероса.
А если AR5212/AR5213?
До сих пор не добавили профиль для процессоров AMD FX !! =(
Ну как так.. как .. так...
...ну хоть CPU Freq стал работать, и напряжение на процессор подаётся меньше при простое. Но надпись unable to load AMD Microcode fam15h - меня вымораживает.
> Но надпись unable to load AMD Microcode fam15h - меня вымораживает.Так может микрокода тупо нет на диске? :)
Ну само собой, если я не ошибаюсь, это как раз зависит от того, что в ядре linux пока не добавили всё что нужно для AMD Family 15 .....
хмм, сделал "$ lscpu"
CPU family: 21
Очень интересно) Пойду-ка погружусь в гугление
Как минимум могу припомнить что как минимум в некоторых дистрах файл с микрокодом надо явно куда-то подкладывать.Более того, проц и так стартует с неким фабричным микрокодоа а BIOS и так грузит в проц более свежий микрокод, если он был на момент создания биоса. Поэтому самому лить микрокод опосля загрузки есть смысл только если известно о каких-то мешающих жить багах проца и есть файл микрокода который их чинит.
> . . .
> Добавлена новая утилита btrfs-restore для выполнения недеструктивного восстановления
> файлов с повреждённой ФС - утилита не занимается непосредственным восстановлением
> целостности ФС, а лишь пытается выделить и отдельно сохранить файлы из повреждённой ФС;
>
> В утилиту fsck добавлена начальная поддержка восстановления целостности повреждённой ФС
> (опция "--repair"). В настоящее время реализована только поддержка восстановления
> повреждений в дереве распределения экстентов;Ага, ого, кажется 14-е февраля ужо скоро таки наступит, подождём-с...
А как вернуть модуль для WiFi "brcmsmac"? А то ево с 3.0 вьіпиляли, а он мне очень нужен... (для режима "Monitor" у вафле)
Внезапно, не знал что по криптографическим хешам можно проверять целостность данных =)))
O_O
> Внезапно, не знал что по криптографическим хешам можно проверять целостность данных =)))о сколько нам открытий чудных... :)
Чёй-то про pipe2(fd, O_DIRECT) забыли, а тем временем, на записи 1Gb файла,
с этим флагом, скорость почти в два раза больше.http://pavlinux.ru/src/pipe2bench/pipe2bench.c
Для полного кайфу берите файлик потолще, напр. VOB иль mkv.
Ralink RT3060 до сих пор не запилили ?
Когда починят наконец драйвер brcmsmac? Чтобы можно было ловить точки дальше собственного носа.
А чо, машину времени изобрели?
mainline: 3.4Ниче не пойму %)
Генточка x32 http://lwn.net/Articles/500482/