https://www.opennet.dev/openforum/vsluhforumID3/42386.html "Notes on the Future of GNOME: Problems and Questions (http://blogs.gnome.org/lucasr/2008/06/15/notes-on-the-future-of-gnome-problems-and-questions/)" - автор статьи размышляет над проблемами мешающими развитию GNOME. Сообществу разработчиков предлагается:<br><br><br>- Сформировать четкую позицию по поводу целевой аудитории для продуктов GNOME;<br>- Определить место в экосистеме, GNOME как продукт для конечного пользователя или как набор компонент для создания таких продуктов;<br>- Пересмотреть процесс разработки: повысить эффективность принятия решений, спланировать внесение коренных изменений, улучшить взаимодействие со сторонними разработчиками. Текущие требования к обеспечению совместимости, мешают внедрению инноваций и не дают проекту вырваться за определенные рамки. <br><br>URL: http://blogs.gnome.org/lucasr/2008/06/15/notes-on-the-future-of-gnome-problems-and-questions/<br>Новость: http://www.opennet.ru/opennews/art.shtml?num=16492<br> https://www.opennet.dev/openforum/vsluhforumID3/42386.html#20 Mon, 14 Jul 2008 06:08:55 GMT Типичная ошибка, Я говорил про убунту и ее DE по-умолчанию - Gnome, а ты с какого-то боку пррикрутил к моему посту Kubuntu с ее DE -KDE, а речь шла о нетормознутости гнома как раз... В общем перепутал теплое с мягким...<br> https://www.opennet.dev/openforum/vsluhforumID3/42386.html#19 Mon, 30 Jun 2008 16:19:43 GMT Неправда!<br> https://www.opennet.dev/openforum/vsluhforumID3/42386.html#18 Mon, 30 Jun 2008 16:17:25 GMT http://linfoline.homedns.org/API/glib/glib-Memory-Allocation.html#g-malloc<br> https://www.opennet.dev/openforum/vsluhforumID3/42386.html#17 Tue, 17 Jun 2008 17:13:09 GMT Пишите на C++. Оператор new в случае неудачи вызывает исключение bad_alloc. glib must die.<br>PS: Не нравиться C++, пишите на Java, C#, python, или хотя бы на простом C, но только не на glib!!!<br> https://www.opennet.dev/openforum/vsluhforumID3/42386.html#14 Tue, 17 Jun 2008 04:36:38 GMT Ты &lt;тук-тук&gt; или притворяешься?<br>Давай пройдём с транспарантами по Красной площади: "Долой gmalloc(), даёшь malloc()!"<br>Чтобы все-все-все разработчики в мире, использующие GTK, нас услышали и заменили все gmalloc()'и на malloc()'и.<br> https://www.opennet.dev/openforum/vsluhforumID3/42386.html#13 Tue, 17 Jun 2008 01:58:07 GMT &gt;&gt;Я правильно понял, что просто после запуска gtk-demo и недолгого в нём <br>&gt;&gt;клацанья утекло 300 килобайт оперативной памяти? <br>&gt;<br>&gt;Да дорогуша, ты правильно понял, а еще это дерьмо (gmalloc) вылетает в <br>&gt;Seg.fault если не может выделить память, т.е. не NULL возвращает (как <br>&gt;обычный malloc) а конкретно выходит из проги, стразу. <br><br>А кто мешает использовать обычный malloc?!!<br> https://www.opennet.dev/openforum/vsluhforumID3/42386.html#12 Mon, 16 Jun 2008 23:44:19 GMT &gt;Я правильно понял, что просто после запуска gtk-demo и недолгого в нём <br>&gt;клацанья утекло 300 килобайт оперативной памяти? <br><br>Да дорогуша, ты правильно понял, а еще это дерьмо (gmalloc) вылетает в Seg.fault если не может выделить память, т.е. не NULL возвращает (как обычный malloc) а конкретно выходит из проги, стразу.<br><br><br> https://www.opennet.dev/openforum/vsluhforumID3/42386.html#11 Mon, 16 Jun 2008 21:11:58 GMT &gt;Привлекают именно простота и нетормознутость...<br><br>Пробовал на своем поставить Kubuntu 7.04 ждал пока загрузится, вытерпел минут 15, а курсор-ожидания так и вертелся не переставая, может ему 400 метров оперативы мало? ггг )))))<br> https://www.opennet.dev/openforum/vsluhforumID3/42386.html#10 Mon, 16 Jun 2008 20:14:00 GMT ~ % valgrind gtk-demo<br>==6229== Memcheck, a memory error detector.<br>==6229== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al.<br>==6229== Using LibVEX rev 1854, a library for dynamic binary translation.<br>==6229== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP.<br>==6229== Using valgrind-3.3.1, a dynamic binary instrumentation framework.<br>==6229== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al.<br>==6229== For more details, rerun with: -v<br>==6229==<br>==6229==<br>==6229== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 70 from 2)<br>==6229== malloc/free: in use at exit: 8,610,919 bytes in 38,947 blocks.<br>==6229== malloc/free: 388,996 allocs, 350,049 frees, 80,597,663 bytes allocated.<br>==6229== For counts of detected errors, rerun with: -v<br>==6229== searching for pointers to 38,947 not-freed blocks.<br>==6229== checked 12,283,288 bytes.<br>==6229==<br>==6229== LEAK SUMMARY:<br>==6229== definitely lost: 300,240 bytes in 6,120 blocks.<br>==6229== possibly lost: 286,368 bytes in 21