Как понимаю, чтобы скомпилить пару пакетов, можно ничего из этого не ставить, а воспользоваться build.opensuse.org
На комп не обязательно ничего ставить — все можно делать через web-интерфейс.
И пакет автоматом станет доступным для всех на software.opensuse.org (если включить опцию поиска по всем репам).
Значит, в OMAP 6 уже не будет такого прогресса в энергосбережении, а будет в чем-то другом.
Производительность, например, выведут на уровень современных x86, чтобы использовать в беспилотных автомобилях. В той статье написано что-то про приоритетное направление car…
Имелось в виду, меняться статически, от ядра к ядру. Не уверен, что такое часто происходит. По крайней мере, в ядре таблица системных вызовов лежит во многих местах — в зависимости от платформы в arch/*/ketnel/syscall*.S
К тому же, когда добавляют свой системный вызов, его добавляют в конец — каждый по-своему — и никакой стандартизации
Автор открыл для себя VFS. И заодно, как работают системные вызовы в Linux.
На мой взгляд, ядро Linux уже достаточно большое, чтобы изучать его эмпирически. Лучше почитать какую-нибудь толковую книжку сначала (например, Роберт Лав, «Linux. Системное программирование»).
Кстати, интересно, что таблица системных вызовов может изменяться от ядра к ядру. Если вы перекомпилируете ядро, mkdir может уже стать не 83-м. Кажется, это разруливается где-то на уровне libc
Слежение за буфером в Punto подглючивает частенько. Особенно, когда работаешь, через RDP. Стоит ли говорить, что сам Punto с RPD не очень дружит. Спасибо за информацию о замене — попробую!
Беда еще в том, что Хром, по всей видимости, сильно оптимизируют под ходовые камни Интел, из-за чего не всякой экзотике, типа моего VIA Nano, невооруженным глазом видно, что Opera обходит его по скорости :)
И как после этого смотреть в браузере этого компьютера на рекламу того, что Хром самый быстрый — хоть бы звездочку там поставили
Здесь достаточно запутано изложено, студенты не поймут.
Простыми словами, автор хотел сказать, что если нельзя использовать числа с плавающей запятой (долго, дорого и т. п.), то нужно ввести числа с фиксированной запятой. Можно записать число, обратное делителю, с точностью до M-го знака после нуля (в двоичной системе) и работать как с целым. У автора M=19.
Это дает возможность «делить» умножая целые числа до 19 знаков — точными получатся только первые 19 цифр. Поэтому если больше 19 знаков, то точность падает.
Видимо, автор это понимает, и в конце привел информацию о том, что в x86 можно делить таким образом без потери точности — результат умножения 32-битных помещается в 64-битный регистр, результат будет в верхних 32-х.
В данном примере оптимальнее было бы M=16.
Кстати, прибавлять 1 к B не надо — нужно просто округлять результат в большую сторону.
Но все равно спасибо за изложение интересного метода. Во встраиваемой ВТ такое используется сплошь и рядом.
Сразу вспомнилась эта история. Только там было наоборот
На комп не обязательно ничего ставить — все можно делать через web-интерфейс.
И пакет автоматом станет доступным для всех на software.opensuse.org (если включить опцию поиска по всем репам).
Производительность, например, выведут на уровень современных x86, чтобы использовать в беспилотных автомобилях. В той статье написано что-то про приоритетное направление car…
К тому же, когда добавляют свой системный вызов, его добавляют в конец — каждый по-своему — и никакой стандартизации
На мой взгляд, ядро Linux уже достаточно большое, чтобы изучать его эмпирически. Лучше почитать какую-нибудь толковую книжку сначала (например, Роберт Лав, «Linux. Системное программирование»).
Кстати, интересно, что таблица системных вызовов может изменяться от ядра к ядру. Если вы перекомпилируете ядро, mkdir может уже стать не 83-м. Кажется, это разруливается где-то на уровне libc
Оказывается, у этого слова есть и другие значения
И как после этого смотреть в браузере этого компьютера на рекламу того, что Хром самый быстрый — хоть бы звездочку там поставили
Простыми словами, автор хотел сказать, что если нельзя использовать числа с плавающей запятой (долго, дорого и т. п.), то нужно ввести числа с фиксированной запятой. Можно записать число, обратное делителю, с точностью до M-го знака после нуля (в двоичной системе) и работать как с целым. У автора M=19.
Это дает возможность «делить» умножая целые числа до 19 знаков — точными получатся только первые 19 цифр. Поэтому если больше 19 знаков, то точность падает.
Видимо, автор это понимает, и в конце привел информацию о том, что в x86 можно делить таким образом без потери точности — результат умножения 32-битных помещается в 64-битный регистр, результат будет в верхних 32-х.
В данном примере оптимальнее было бы M=16.
Кстати, прибавлять 1 к B не надо — нужно просто округлять результат в большую сторону.
Но все равно спасибо за изложение интересного метода. Во встраиваемой ВТ такое используется сплошь и рядом.
Пока что напрашивается один вывод — забил Google на свой Chrome Store