Две части статьи, линк с опеннета. Для Ъ не будет, ибо много букав.

http://www.linuxspace.org/archives/4356

http://www.linuxspace.org/archives/4371

Взял у друга калибратор Spyder2Pro на попробовать. Калибровал как в винде (родной софтиной), так и в линуксе (dispcalGUI). Моник - дерьмо, LG L1730B 7 лет от роду, но всё же. Также пробовал калибровать моник у друга (тоже лин+вин) и у девушки (винда). У них обычные TN+Film, но более новые и в целом должны быть хоть чуть лучше.

Везде результат один и тот же - подстройка белого для 6500K дает необходимость в сильном увеличении синего в RGB настройках монитора. Становится очень видна синева в промежуточных цветах, про белый ничего сказать не могу - не вижу. После создания профиля ситуация почти нормализуется, но всё равно ощущается существенный уход в синеву, теплые фотки (снятые на солнце с соотв. ББ камеры) становатся холодными. И так на всех мониторах. В добавок к тому на своем компе создал отчет в dispcalGUI - показывает, что цвета в целом соответствуют требуемым (ну кроме ж*пы в чёрном).

Что это - глючит калибратор или у троих человек глаза? И как можно что-то проверить?

В последнее время замечаю, что при каких-то проблемах (к примеру с компом или около того) я отдаю предпочтение тому решению проблемы, которое предполагает покупку. Тупо нравится покупать - вот такое вот потреблядство. Купил SSD, но при трезвом мышлении мне она не сильно и нужна, а запуск OOo/LO вскоре ускорили и без того. Покупаю новую фототехнику. Купил новый дорогой кулер на CPU и радуюсь как дебил потере 70$ на него. Да, работает хорошо, просто отлично, но стоит ли оно тех денег? Основное снижение шума всё равно получилось за счет echo low > /sys/class/dri/card0/power_profile на моей ATI. И так далее.

Как с этим всем бороться?

!Ъ

Проект MemShrink, в рамках которого развернулась борьба за снижение потребления памяти в Firefox, уже позволил добиться неплохих результатов. Проведя стресс-тестирование свежей ночной сборки Firefox и Chrome были получены интересные результаты.

На автоматизированное открытие скриптом 150 вкладок с типовыми сайтами Firefox затратил 6 мин 14 сек и 2 Гб ОЗУ, сохраняя возможность реагирования на действия пользователя. На выполнение аналогичного теста Google Chromе затратил 27 мин 58 сек и 5 Гб ОЗУ (показатель RSS из about:memory), при этом в процессе тестирования браузер не отвечал на действия пользователя на 100% загружая CPU (проблемы и задержки начались после открытия 70 вкладок).

opennet

В дополнение, можно упомянуть публикацию отчета, подготовленного компанией Microsoft с целью выявления предпочтений в выборе хостинга свободных проектов, использующими различные операционные системы разработчиками. Опрос проводится через Twitter. Самым популярным хостингом для связанных с Windows открытых проектов оказался поддерживаемый компанией Microsoft сервис CodePlex (38%), с минимальным отрывом на втором метсте оказался GitHub (37.9%). Год назад CodePlex предпочли 43.4% разработчиков, а GitHub 26%. Позиция Google Code понизилась за год с 14.7% до 6.6%, а SourceForge с 8.8% до 6%.

В рейтинге разработчиков, использующих Linux и Mac OS X, CodePlex оказался на последнем месте (~ 1%), а предпочтение было безоговорочно отдано GitHub (66% и 86%), позиции которого за год укрепились (было 55.8% и 84.7%). На втором месте у тех кто предпочитает Linux хостинг SourceForge (10.4%, год назад было 9.1%), на третьем - BitBucket (8%, год назад было 18.2%), на четвертом - Google Code (7.4%, год назад было 10.4%).

При рассмотрении популярности систем управления исходными текстами, разработчики, вне зависимости от типа используемой операционной системы, поставили на первое место Git (30.7% Windows, 65.4% Linux и 78.3% Mac OS X). При этом популярность Git за год заметно выросла. После Git работающие в Windows разработчики выбирают Subversion (23.9%), Mercurial (20.7%) и TFS (Microsoft Team Foundation Server, 20.6%). Работающие в Linux, кроме Git, активно используют Mercurial (15.4%) и Subversion (12.3%). При этом популярность Mercurial со временем падает (с 25% до 20.7%), а Subversion растет (рост с 8.8% до 12.3%). Доля пользователей Bazaar (3.7%) и TFS (0.6%) среди опрошенных незначительная.

Скачал билд 7989 на потыкать, поставил в ящик. Винда отчаянно пыталась свистеть и пердеть в ящике без guest additions с жесткими тормозами.

По теме: от вин7 отличается только Ribbon-интерфейсом explorerа и наличием экранной клавы для таблеток. Больше изменений не вижу. Они что, будут релизить ту же семерку?

P.S. тред с видео нового гуя видел, но его в билде нет.

http://www.opennet.ru/opennews/art.shtml?num=31107

Разработчики открытых драйверов для видеокарт AMD/ATI получили подмогу: на работу в AMD приняты Мишель Дэнцер (Michel Dänzer) и Кристиан Кёниг (Christian König), уже продолжительное время занимающиеся разработкой свободных драйверов для карт AMD/ATI. Ранее над свободными драйверами в AMD работали только Джон Бридгман (John Bridgman) и Алекс Дейчер (Alex Deucher).

Мишель Дэнцер перешел в AMD из компании VMware. В качестве разработчика Дэнцер занимался преимущественно Mesa и Gallium 3D. До VMware он работал в компании ATI в группе по развитию закрытых драйверов Catalyst для Linux.

Кристиан Кёниг разрабатывал аудио-поддержку HDMI в открытых драйверах Radeonhd. Благодаря обратному инжинирингу стало возможным использовать интегрированные устройства обработки звука некоторых графических чипов. В последнее время Кёниг работал над Gallium 3D.

http://www.opennet.ru/opennews/art.shtml?num=31110

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

Созданный в процессе разбирательства патч продемонстрировал неожиданные результаты: без патча Firefox в процессе тестового сеанса израсходовал 239 Мб ОЗУ, а с патчем 189 Мб (меньше на 20%). При работе в режиме минимального потребления памяти без патча был израсходован 108 Мб ОЗУ, а с патчем - 21 Мб (в пять раз меньше). Подготовленный патч войдет в состав релиза Firefox 7, который ожидается в начале осени. В Firefox 7 также планируется включить еще один патч с реализацией для JavaScript-движка механизма увеличения эффективности работы сборщика мусора.

Apple-ch - толстота про мак в каждом втором сообщении, все сообщения в толксах, бесполезность присутствия пользователя на ресурсе.

По поводу https://bugs.kde.org/show_bug.cgi?id=268439 - накатал патч. Криво, но вроде работает. Кому не лень - потестите и отпишитесь тут. Накладывать на kdebase-workspace (делал на 4.6.4).

Есть ли книги о Linux для людей, которые вообще до этого не имели дела с компом?

Причем интересует именно работа как пользователя, а не описание консоли и команд. Т.е. подразумевается что человеку систему поставили и настроили, а дальше с книгой разберется.

Цена 650$. 15 дюймов, предположительно Core i3 и 4Gb RAM. Вижу кучу ноутов и хз на чем остановиться.

Сабж.

По-моему, это было нечто.

В гугле забанили... Где можно скачать много фоток в большом размере (>20МП)? Нужно для проверки одного алгоритма.

Выбило соединение, не принимает пароль. И ладно бы это только у тебя произошло. Сайтец http://icq.com лежит на ремонте.

opennet

Разработчики проекта NEXT3, в рамках которого уже несколько лет развивается неофициальная реализация поддержки мгновенных снимков состояния файловой системы Ext3 (снапшотов), представили первый выпуск набора патчей ext4-snapshots, обеспечивающих работу снапшотов в файловой системе Ext4.

Вопрос об интеграции представленного набора патчей в Linux-ядро пока не решен. Набор состоит из 36 патчей и интегрируется с Ext4 через систему стандартных хуков. Предусмотрена возможность монтирования разделов с отключением поддержки снапшотов, в этом случае код никак себя не проявляет и ФС Ext4 функционирует как раньше. В качестве причины развития проекта указано желание интегрировать возможность работы со снапшотами в уже зарекомендовавшую себя и повсеместно используемую ФС Ext4, вместо использования экспериментальной ФС Btrfs или системы dm_multisnap.

Разработка проекта ведется компанией CTERA Networks, которая использует код проекта NEXT3 в своих NAS-хранилищах и гибридных системах хранения данных. Несмотря на то, что патчи уже достаточно хорошо протестированы и отлажены в недрах компании CTERA, для интеграции их в ядро требуется более широкомасштабное тестирование и оценка их влияния на производительность. По заявлению разработчиков проекта патчи готовы к интеграции в состав Linux-ядра. Так как окно по принятию патчей для ядра 3.0 уже закрыто, а следующее будет только в августе, у энтузиастов есть несколько месяцев на проведение дополнительного тестирования.

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

Снапшоты не требуют предварительного резервирования места, что позволяет гибко управлять доступным свободным пространством. Снапшоты Next3 являются компактными и требуют дополнительного места только для хранения изменений; Близкая к линейной масштабируемость - даже при огромном количестве снапшотов скорость остается на уровне, близком к Ext4; Поддержка инкрементальных снапшотов, доступных только на чтение (создаем снапшот: «snapshot.ext4dev take Monday», монтируем его: «snapshot.ext4dev mount Monday», удаляем: «snapshot.ext4dev delete Monday»); Снапшоты создаются и удаляются практически мгновенно. Сразу же после удаления снапшота занятое им пространство автоматически освобождается; Полная прямая и обратная совместимость с Ext4. Миграция с Ext4 на вариант с поддержкой снапшотов и обратно выполняется буквально в три команды («umount /dev/xxx; snapshot.ext4dev on /dev/xxx; mound -t ext4dev /dev/xxx»).

Инструкцию по установке можно найти здесь (вместо модуля next3 следует указать ext4dev, а вместо скрипта next3 - snapshot.ext4dev). Тестовые патчи подготовлены для Linux-ядра 2.6.38 и протестированы в дистрибутивах Ubuntu 11.4 и Fedora 15. Загрузить предкомпилированную версию для систем x86_64 можно здесь.

Как всегда - ждем комментариев iZEN.

Вышел релиз Lightspark 0.4.8, свободного Flash-плеера, основанного на технологиях LLVM и базирующегося на использовании JIT-компилятора, транслирующего ActionScript код в x86-инструкции. Исходные тексты Lightspark написаны на языке C++ и распространяются в рамках лицензии GPLv3. За счет тесного использования OpenGL и JIT-компиляции нагрузка на систему при работе Lightspark заметно меньше, чем при просмотре того же ролика в Gnash или Adobe Flash. Проект развивается при поддержке организации GNOME Foundation.

Из добавленных в новой версии улучшений можно отметить обеспечение поддержки видеосервиса Vimeo и улучшения поддержки YouTube. Кроме того, исправлена неприятная ошибка в коде распределения памяти, что позволило значительно сократить потребление памяти в процессе просмотра видео. Пользователи Ubuntu могут установить новую версию из специального PPA-репозитория.

Основные особенности Lightspark:

• Поддержка языка ActionScript 3.0, впервые представленного в Adobe Flash 9 (в Gnash полная поддержка ActionScript 3.0 еще не реализована);
• Задействование OpenGL при формировании вывода геометрических объектов и видео (для работы требуется видеокарта с поддержкой шейдеров);
• Возможность подключения фильтров и эффектов, изменяющих параметры видео, благодаря задействованию текстурированного вывода с использованием OpenGL;
• Реализация в виде плагина, совместимого с интерфейсом плагинов Mozilla;
• Наличие встроенных средств для отладки, профилирования и инспектирования объектов на экране;
• Состояние разработки runtime-библиотек Flash, которые предоставляют разработчикам широкий спектр функций, от вывода видео до разбора XML, в Lightspark еще далеко до завершения, но архитектура проекта позволяет создавать подобные функции на чистом C++ или в смешанном со сгенерированным в VM кодом представлении, что дает возможность вызывать подобные функции из любого контекста, не заботясь об их источнике.

Срочно нужна beta-testers army, чтобы узнать, насколько оно юзабельно.

Просто накидывайте сюда самые разные проги, что юзаете (с описанием + чем понравились).

От себя:

F1 Countdown - время до след. гонки Ф1 (+виджет).
Garfield - daily комикс Гарфилда. Прогла унылая, но комикс таки показывает.

Такое себе продолжение предыдущего треда. Есть в проекте класс

class Client: public QObject
{
public:
  Client(QObject* parent) : QObject(parent) {}
  ~Client() {}
...
private:
  class ClientPrivate;
  ClientPrivate *d;
};

Из конструктора и деструктора был выкинут весь код.

Наблюдается сегфолт при выполнении данного кода:

delete new Client(NULL);

Падает в деструкторе, непонятно с какого залезая в libfam.so. valgrind способен лишь констатировать смерть (т.е. находить проблемы уже в libfam, который никаким краем вызываться не должен).

Если рядом с Client определить точно такой же Client1, то, в зависимости от взаимного положения классов в коде, сегфолта может и не быть.

Подозревается повреждение памяти, но вопрос скорее теоретического плана: что нужно повредить, чтобы в однопоточном приложении в delete new Client(); фейлился деструктор? Причем фейлился еще до вызова operator delete(void*).

Напишите свой ТОП 5

• самых адекватных людей на этом ресурсе
• самых неадекватных людей на этом ресурсе