!Ъ

Проект 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

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

Отлаживаю kopete, который стабильно падает при каждом закрытии. Ловит сегфолт в деструкторе класса Client. Выкинул из деструктора всё - не помогло. Из членов у класса - только ClientPrivate* d;.

Класс наследуется от QObject.

Итак, пустой деструктор:

Dump of assembler code for function Client::~Client():
=> 0x00007fa293639900 <+0>:     push   %rbx
   0x00007fa293639901 <+1>:     mov    %rdi,%rbx
   0x00007fa293639904 <+4>:     callq  0x7fa293633dd0 <_ZN6ClientD1Ev@plt>
   0x00007fa293639909 <+9>:     mov    %rbx,%rdi
   0x00007fa29363990c <+12>:    pop    %rbx
   0x00007fa29363990d <+13>:    jmpq   0x7fa2936352f0 <_ZdlPv@plt>
End of assembler dump.

_ZdlPv - это обычный operator delete(void*). Что такое _ZN6ClientD1Ev - это тот же Client::~Client(). Падает в нём:

Dump of assembler code for function _ZN6ClientD1Ev@plt:
=> 0x00007fa293633dd0 <+0>:     jmpq   *0x2fb242(%rip)        # 0x7fa29392f018
   0x00007fa293633dd6 <+6>:     pushq  $0x41
   0x00007fa293633ddb <+11>:    jmpq   0x7fa2936339b0
End of assembler dump.

(gdb) disassemble 0x7fa29392f018
No function contains specified address.
(gdb) disassemble 0x7fa2936339b0
No function contains specified address.
(gdb) display/i $pc
1: x/i $pc
=> 0x7fa293633dd0 <_ZN6ClientD1Ev@plt>: jmpq   *0x2fb242(%rip)        # 0x7fa29392f018
(gdb) si
0x00007fa293633dd6 in Client::~Client () from /home/valentine/usr/lib/liboscar.so.1
1: x/i $pc
=> 0x7fa293633dd6 <_ZN6ClientD1Ev@plt+6>:       pushq  $0x41

Это как? Проигнорили jump? Идем на второй jmpq. Прыгаю внутрь:

(gdb) si
0x00007fa2936339b0 in ?? () from /home/valentine/usr/lib/liboscar.so.1
1: x/i $pc
=> 0x7fa2936339b0:      pushq  0x2fb44a(%rip)        # 0x7fa29392ee00
(gdb) si
0x00007fa2936339b6 in ?? () from /home/valentine/usr/lib/liboscar.so.1
1: x/i $pc
=> 0x7fa2936339b6:      jmpq   *0x2fb44c(%rip)        # 0x7fa29392ee08
(gdb) si
_dl_runtime_resolve () at ../sysdeps/x86_64/dl-trampoline.S:30
1: x/i $pc
=> 0x7fa2abf862c0 <_dl_runtime_resolve>:        sub    $0x38,%rsp

И т.д. и попадаю в libfam, откуда выхожу назад в ZN6ClientD1Ev (по более ранему адресу, чем был там раньше) и попадаю в SIGSEGV:

#0  0x000000000000000b in ?? () at /usr/include/qt4/QtCore/qlist.h:494
#1  0x00007fa293639909 in Client::~Client (this=0x2a95560, __in_chrg=<value optimized out>)
    at /home/valentine/tmp/1/kdenetwork-4.6.1/kopete/protocols/oscar/liboscar/client.cpp:222

В 1-ом фрейме видно, что я и не выходил из _ZN6ClientD1Ev, а словил лажу там.

Может кто подскажет, где может быть проблема?

Верните приписку в теме «Перенесено <moderator_name> из <forum_section>» при переносе. 1. Хочется знать, кто перенес (страна должна знать своих героев). 2. Без этого часто существующие комментарии становятся непонятными.

Навеяно удаленным тредом про LucidFox.

Есть LGPLv2 библиотека (id3lib), которая поставляется с zlib. zlib нужен для сборки и его исходники прямо вложены в id3lib. id3lib статически линкуется с zlib.

Вот лицензия zlib:

(C) 1995-2004 Jean-loup Gailly and Mark Adler

This software is provided 'as-is', without any express or implied warranty. In no event will the authors be held liable for any damages arising from the use of this software.

Permission is granted to anyone to use this software for any purpose, including commercial applications, and to alter it and redistribute it freely, subject to the following restrictions:

1. The origin of this software must not be misrepresented; you must not claim that you wrote the original software. If you use this software in a product, an acknowledgment in the product documentation would be appreciated but is not required. 2. Altered source versions must be plainly marked as such, and must not be misrepresented as being the original software. 3. This notice may not be removed or altered from any source distribution.

Jean-loup Gailly Mark Adler jloup@gzip.org madler@alumni.caltech.edu

Вопрос №1: насколько это легально? Разрешает ли это LGPL?

Вопрос №1: насколько легально сделать динамическую линковку с zlib? Разрешает ли это LGPL?

Интересует именно формальная сторона вопроса.