Да, я слоупок: более 5 лет пользуюсь линуксом, даже программист вроде как, и только сейчас обнаружил эти отличные опции для `/etc/sysctl.conf`:

vm.overcommit_memory = 2
vm.overcommit_ratio = 100

Перегрузил опции командой `sudo sysctl --system` и попал прямо в райские кущи. Можно открыть браузер, три IDE и запустить виртуалку Virtual Box - и результатом станет не зависание системы намертво с необходимостью делать hard reset, а просто ошибка в Virtual Box (работа виртуальной машины прервана).

Своп отключил ещё раньше, я не хочу, чтобы моя система висла намертво под девизом «я тут данные программы в своп скину, как будто бы памяти достаточно, ты тут посиди пару дней, подожди, пока я закончу». Хотя конечно с точки зрения разработчиков Linux это не зависание намертво, это просто долгая работа со свопом - но я так не считаю и считаю что в линуксе своп надо отключать.

А как вы боретесь с традиционным для Linux зависанием намертво при нехватке памяти?

P.S. для справки, настройку выполнял согласно этому былинному посту: http://avz.org.ua/wp/2011/04/24/overcommit-memory/

В каждой ОС есть удобные для разработчика способы настроить окружение: например, для C++ это

• conan.io, brew (linuxbrew) и checkinstall на онтопике
• brew (homebrew) на полутопике
• vcpkg (для Visuals C++) или pacman (в составе MinGW) на оффтопике.

Во всяких нодах и питонах есть свои npm и pip.

Есть известные требования современных хипстеров:

• Если Javascript, то надо поставить свежий Node.js, настроить linter, настроить автофоматирование, настроить Google Closure Compiler
• Если Typescript, то примерно как JS, только вместо Google Closure Compiler будет компилятор Javascript
• Если C++, то надо поставить свежий GCC или Clang + разобраться с линковкой STL (желательно линковать статически), накатить серию библиотек (типа boost, glm, SDL2 и т.д.), настроить себе clang-format и clang-tidy
• И ко всему бы ещё поднять continious integration где-нибудь в Jenkins или Travis

Да вот беда, когда начинаешь разбираться что к чему настроить, вылезает куча древних руководств, которые в огромных талмудах, часто разбитых на десятки страниц, льют воду о вещах, не нужных хипстеру. И на выходе какое-нибудь старое окружение, например без C++17 и без линтеров. Или сайты с такой ужасной вёрсткой, что даже очки в толстой оправе не спасут и хочется просто закрыть их навсегда.

А встречались ли нормальные, хипстерские туториалы или воркшопы? Из разряда: здесь у нас будет окружение для $LANGUAGE_NAME, так оно будет выглядеть, такие входные требования к системе/окружению, вот серия статей, где модуль за модулем мы будем настраивать всё это. Не хочешь ставить отдельный модуль - пропускаешь статью и читаешь дальше.

Пока видел только такой воркшоп: Continuous integration для C++ разработчика. Там сразу понятно что на входе, на выходе и как это будет выглядеть.

Ну или хороший воркшоп по libFuzzer: Modern fuzzing of C/C++ Projects

Не то чтобы я новичок и нуждаюсь в пошаговых указаниях, но полгода назад самому пришлось разбираться, как нормально собрать себе свежий Clang и CMake для экспериментов с C++17 (в итоге написал небольшой shell-скрипт для сборки и для запуска checkinstall).

А сейчас на оффтопе так же разбираюсь с MinGW, который как оказалось существует в трёх вариациях (MinGW, MinGW-w64 и TDM GCC), из которых первая ещё и самая зашкварная (в ней даже заголовок <mutex> не работает, вот стыдоба-то).

GNU Make неспособен обрабатывать файлы, содержащие пробелы в путях. О нём пишут книги, он считается выбором по-умолчанию в Linux, на него опираются CMake и autotools. Но и они не могут исправить проблему: стоит положить всё в каталог, в пути которого пробелы, и сборка сыплется.

Иногда мне кажется, что этот проект сопровождают дегенераты. В конце концов, в любом коммерческом проекте такое считается багом.

Вот вам пример нормального современного C++, который, кстати, скоро может войти в состав SDK для оффтопа: github.com/kennykerr/modern

Вот вам пример, как библиотечные возможности STL и boost помогают отказаться от большинства паттернов GoF и тем самым избежать мусорных типов, таких как IXxxListener, IXxxObserver и т.д и т.п: accu.org/content/conf2013/Tobias_Darm_Effective_GoF_Patterns.pdf

Это всё - примеры нормального, простого языка, в котором авторы библиотек где-то далеко пишут мощные средства, работающие по принципу чёрного ящика с детальным описанием поведения, а обычные разработчики пишут просто и понятно даже джуниору.

Глядя же на большинство статей по С++11 и C++14, начинает уже тошнить от мета-программирования, супершаблонов с мегавариадиками, гипердеклтайпов с невероятно компильтаймовым вычислением абсолютно ненужных вещей (которые в 99% программ вообще незачем считать в компильтайме).

Почему так?

Столкнулись со следующей проблемой: есть отдельный SVN репозиторий с подпроектом (C++ и примерно 5-6 разных продуктов сборки) с немалой историей. Хочется перенести это в Git, но в Git репозиторий должен стать лишь подпапкой в более крупном проекте. Одновременно хочется сохранить историю.

История изменений и работоспособный git blame важны, так как весь код legacy, имеет кучу ad-hoc решений (т.е. костылей) и его надо сопровождать.

Насколько я знаю, есть средства переноса из svn в git, в которых можно настраивать отображение авторов коммитов и тому подобные настройки. Можно попробовать импортировать отдельный svn в отдельный git, а затем использовать git subtree или другую технику включения вложенного git-репозитория в более крупный git-репозиторий.

Есть что посоветовать на эту тему? Сохранится ли после такого (или иного) переноса история изменений и работоспособный git blame?

Представлен новый выпуск Mesa — 10.6. Из изменений:

• В драйверах ещё больше расширений и оптимизаций
• Почищен очень старый легаси
• Прекращена поддержка OpenVG.

Вот так окончательно сдулся несостоявшийся стандарт ускорения двумерной векторной графики. Разработчикам приложений остаётся использовать Qt-шный QPainter, простенький и широко распространённый Cairo, навороченный и более трудный в поддержке Google Skia или построенный поверх Skia/Direct2D движок Moz2D. Из аппаратного ускорения — шейдеры и NV_path_rendering (только для проприетарных драйверов NVIDIA, поддерживается в Skia и Moz2D).

Kubuntu с закосом под Unity, с иконками и темой курсора KDE Breeze.

После возвращения из армии сперва сделал апгрейд ноутбука: поставил 12ГБ памяти вместо 4ГБ; хотел заменить HDD на SSD, но обнаружил, что в моей модели от DNS есть два места под жёсткие диски, просто вместо второго HDD всегда стояли пустые салазки. В итоге стоит SSD на 256ГБ (порт SATA), HDD на 700ГБ (тоже SATA) и CD/DVD привод убирать не пришлось.

Затем пришло время переустановить Ubuntu. Ubuntu 12.04 уже имеет слишком мало сторонних пакетов в сторонних репозиториях и PPA, а Ubuntu 14.04 не встаёт. В итоге поставил Kubuntu 14.04 и постарался сделать закос под интерфейс Unity, который мне оче нра.

Ищу работу — точнее уже нашёл варианты, теперь выбираю. На фоне тестовое задание, которое делаю на Qt для компании, куда недавно собеседовался. Гибрид C++ и QML, хотя так-то задание надо делать под винду и на WTL или MFC, но я решил, что сделать прототип на QML и потом просто перенести отлаженный C++ код бизнес-логики будет проще, чем сразу копаться в WTL.

Из недостатков закоса:

• От Breeze только иконки и курсор, стиль приложений — унылый Oxygen
• Нет HUD (убунтовский поиск по меню приложения), а ведь было удобно выполнять команды git из QtCreator через него
• Global menu глючит в Firefox и не работает в LibeOffice
• Обычная проблема кед - файловые диалоги Qt-приложений (не KDE-) не видят закладок, не переведены и вообще убогие

>>> Просмотр (1920x1080, 270 Kb)

Сам не пойму, чего меня тянет на подобное. Но ведь жизненный опрос, не правда ли?

Поскольку меня уже достали танцполом в адрес России, то я разбавлю эту реку русофобского дерьмеца отборным вбросом со стороны Франции.

Французская железнодорожная компания SNCF купила две тысячи поездов, которые оказались шире большинства станционных путей страны. Теперь эти станции нужно перестраивать, за что обычно платят местные власти — но в этом случае представители регионов категорически отказались исправлять чужие ошибки: «Мы не собираемся платить ни сантима за эту реконструкцию. Мы не хотим ,чтобы финансисты держали нас за дураков».

Реконструкция обойдётся в десятки, если не сотни, миллионов евро.

!Ъ.

Пишется, скажем, приложение для андроида или ubuntu touch. У приложения есть локализация на несколько языков (далеко не 50, и даже не 10). Если для данного языка локализации нет, обычно используется английская локализация.

Вопрос: надо ли для телефона с украинской локалью делать фоллбеком русскую локализацию приложения, при условии что украинской нет и не будет?

Казалось бы, в современном Linux благодаря стандартам freedesktop можно просто взять и собрать кросс-дистрибутивный пакет для любого графического приложения, который будет располагаться в хомяке и таскать с собой все нужные библиотеки.

Делается это так:

• .desktop кладём в ~/.local/share/applications
• иконку к .desktop кладём в ~/.local/share/icons
• приложение и его библиотеки кладём в ~/.local/share/$VENDOR/$APP
• типовой shell-скрипт с LD_LIBRARY_PATH кладём в ~/bin
• приложение пишется так, чтобы не мусорить в хомяк и использовать /tmp, XDG_DATA_DIR, XDG_CONFIG_DIR

И всё работает, и любая DE видит эту программу, и пользователи плачут от радости.

Но не тут-то было. Потому что в Linux нет API с обратной бинарной совместимостью. Потому что LSB — лживый недостандарт, предназначенный исключительно для подсаживания дурачков на вендорную иглу и сколачивания бабла (Ульрих Дреппер, бывший лидер проекта GLIBC, писал об этом ещё в 2005-м; я проверил ситуацию пару дней назад — и увидел, что LSB dll hell проявится даже в таких «правильных» дистрибутивах, как OpenSUSE).

А как бы всё-таки мог выглядеть этот API, который должен быть на любом CD с любым дистрибутивом и должен появляться сразу после установки в любом дистрибутиве? Тут три критерия: минималистичность, привлечение разработчиков с других платформ и самодостаточность.

По моим современным личным представлениям, любая библиотека в идеале выполняет ровно одну из двух задач: предоставляет API или является фреймворком. Библиотека-API минималистична и массштабируема, но требует знания матчасти и множественных проверок кодов возврата: на ней можно написать быстрый и качественный движок (графический, звуковой, рендеринг шрифтов), но использовать такое в приложении напрямую без обёрток может только недалёкий человек. Библиотека-фреймворк, напротив, выполняет общие задачи не задаваясь максимальной гибкостью, но зато с удобством; при этом фреймворк должен либо иметь обратную бинарную совместимость в течение многих лет, либо его надо встраивать в пакет с приложением; примером первого подхода является Qt, примером второго - cocos2d-x.

Исходя из этих представлений, я вижу так:

• Linux API должен иметь два слоя: первым будет максимально привлекательный фреймворк с обратной совместимостью, вторым будет набор кроссплатформенных массштабируемых сишных библиотек с максимальной гибкостью и производительностью.
• Первым слоем должен быть Qt5 — программы на нём практически не требуют дополнительных библиотек и легко переносимы на Windows, OSX (а теперь отчасти и на android с iOS). Вкупе с поддержкой QML и javascript это будет сильнее всего привлекать людей к разработке и портированию качественных приложений для/на Linux.
• Вторым слоем должен быть набор библиотек, позволяющих общаться с любой важной внешней сущностью. Шрифты, работа с OpenGL, создание окна и контекста OpenGL, работа со звуковыми устройствами, открытие URL по клику и вывод уведомлений — все эти штуки приложение не сможет нормально сделать само или с помощью библиотек в своём пакете. Это должен быть внешний API.
• Во второй слой точно должны попасть: OpenGL, OpenAL, fontconfig и freetype. Библиотеки png и jpeg попадать не обязаны — да, они часто используются, но они не работают с внешней средой и легко могут быть в составе пакета приложения. Надо также разработать библиотеки (а не утилиты командной строки и не dbus-интерфейсы) для работы с DE (appmenu, прогрессбар и badges на иконке приложения в лаунчере, уведомления)
• За размер пакетов бояться не стоит: zip и bz2 очень хорошо жмут бинарники, link-time optimization и strip вырезают из них лишнее, а наличие Qt5 в первом слое API уже даст кучу крайне лёгких Qt-приложений для узких задач, более опытные и уверенные в себе разработчики смогут сделать относительно лёгкое приложение на втором слое API.

Какие ещё библиотеки должны попасть во второй слой API? И может быть, я что-то упустил из виду?

P.S. Генту идёт в лес. Если вы готовы собирать то же приложение из исходников или оптимизируете работу сервера — флаг вам в руке, но о готовых пакетах с десктопными приложениями забудьте, сами же отказались от этого в своей идеологии.

Ставил тут опенсьюз в виртуалку, просто чтобы проверить, какие разделяемые библиотеки есть на чистой системе. В качестве среды выбрал гном 3, потому что параллельно проверял Росу с KDE. Из консоли вывел список библиотек, руками смержил это в один файл, нажал delete для удаления лишнего файла. Ну я думал — «сейчас появится нудный диалог подтверждения, а то и не один». Я ошибался.

Не произошло вообще ничего.

Я немного хикки, а подобных вещах ещё и нуб, поэтому прошу совета и экспертной оценки.

Есть такая общая идея, как писать быстрые программы: взять за целевое устройство нечто более слабое, чем конфигурация типичного пользователя, и писать под это устройство (желательно чтобы в самом устройстве на фоне ещё что-то висело). У программистов обычно бывает наоборот — накупят себе два монитора и фигачат кнопки на пол-экрана, как в гноме, ну а 32 гига и 4 ядра под Java+Eclipse+эмулятор андроида наверное себе хотят все.

А что, если сделать наоборот? Опросить знакомых, поспрашивать б/у устройства по минимальной цене, только желательно с более высокой версией андроида (4.x или хотя бы 2.3)?

Вопрос: во сколько примерно будет обходиться одно такое устройство, по вашим оценкам?

С 23 по 25 сентября проводилась очередная X Developers Conference, XDC2013. На ней было несколько докладов, полезных для широкой публики — и одним из них был доклад о XMir и XWayland. Автор — Chris Halse Rogers из компании Canonical, ранее занимавшийся сопровождением X-сервера в убунту и теперь привлечённый к разработке Mir и XMir. Здесь будет изложен краткий конспект этого доклада, взятый из PDF-слайдов и видеозаписи.

( читать дальше... )

>>> PDF-слайды доклада

Я просто решил оставить тут несколько фактов о принципах работы wayland и их применимости на android.

И прежде всего я обращаю внимание на тот факт, что ровно две конторы решили сделать мобильные ОС поверх драйверов android: Canonical и Mozilla. Обе перед этим разрабатывали софт под андроид, ubuntu for android и firefox for android соответственно. В ходе разработки они столкнулись с одними и теми же проблемами и интересными решениями от команды разработчиков из Google. Разумность этих решений и побудила их к тому, что они делают.

Часть I, или wayland — не дисплейный сервер

Wayland — название протокола, описанного в XML файле. Из файла генерируется документация к протоколу и код на C, позволяющий общаться посредством этого протокола (libwayland). Если кто-то из разработчиков вейланда говорит вам, что «в вейланде явно не специфицируется то-то и то-то», его слова следует просто игнорировать: протокол-то не специфицирует, но реализация у него была и есть одна — weston — а он как раз специфицирует многие вещи; кроме того, попробуйте-ка заставить авторов тулкитов и mesa вот так взять и добавить поддержку особенностей альтернативной реализации протокола wayland (а таковой в будущем мог бы стать даже mir). С вас шкуру спустят, за то что опять фрагментируете бедное комьюнити своими забагованными альтернативными реализациями.

Часть II, pixmap <-> texture

На многих устройствах с android стоит относительно слабый процессор, и даже его мощность следует максимально беречь из-за батарейки (например, один из смартфонов самсунга имеет два ядра на 1,3 и 1,9 ГГц, но в нормальном режиме работает только слабое ядро), ОЗУ надо беречь из-за батарейки. Также на устройствах есть интеграшка вместо видеокарты и большой экран (у Samsung S3 он больше, чем у iPad без ретины). Увеличение размера экрана в n раз увеличивает число пикселей в n² раз. Как мы все уже знаем, современные тулкиты рисуют готовую картинку и отправляют её серверу, но делать это можно четырьмя способами

1. Выделять места в памяти, рисовать там картинки, отправлять серверу. Это всегда даёт оверхед на ОЗУ, даёт оверхед на передачу данных по шине для дискретных видеокарт и оверхед на копирование памяти для интеграшек. OpenGL использовать нельзя, аппаратного ускорения нет. В начале своего пути Wayland умел только так.
2. Выделять OpenGL framebuffer, рисовать туда командами OpenGL, забирать оттуда пиксели с помощью glReadPixels, а потом способ №1; про его оверхед уже сказано. Хотите я вас обрадую? У драйверов android есть баги, например, на видеокартах Qualcomm иногда пиксели из фреймбуфера читаются некорректно, потому что они оптимизировали вывод графики и потребление ресурсов с помощью тайлинга (разбиения фреймбуфера на квадраты 16x16, которые обрабатываются отдельно) и теперь не гарантируют, что весь фреймбуфер целиком может быть нормально разобран на пиксели. Отдельные баги, может быть, исправлены в android 4.2, но кто исправит их в android 4.1, на котором и основан cyanogen mode? Конкретные проблемы и сопутствующий оверхед можно пофиксить путём использования способа №4.
3. Выделять OpenGL framebuffer, рисовать туда командами OpenGL, отдавать дисплейному серверу. Используется в weston и mir. Кстати, в обоих случаях используется библиотека EGL, которая выступает связующим звеном между объектами OpenGL/OpenGLES/OpenVG и знакомыми всем программистам понятиями из мира программной отрисовки, такими как pixmap, surface, и так далее. В обоих случаях надо попросить weston или mir создать окно, потом попросить libEGL о создании EGLSurface из полученного окна, а дальше уже средствами чистого EGL создать контекст OpenGL и другие ништяки. Недостаток — невозможность использовать частично программную отрисовку, всё только через GPU.
4. В реальных устройствах на андроиде все карты — интеграшки, и выделенной памяти у них нет. Просим у драйвера видеокарты область оперативной памяти в виде EGLImage (у EGL для android есть такое нестандартное расширение), связываем его с текстурой либо фреймбуфером, рисуем в картинку софтварно и/или через OpenGL и используем дальше как текстуру. Это — идеал, именно он используется внутри андроида, но недоступен прямо через NDK или java: [1], [2], [3]. Нулевой оверхед на копирование, нулевой оверхед на ОЗУ. Поддерживают ли этот способ тулкиты на вейланде? Поддерживает ли его Weston? Зато есть заявления о работоспособности Weston под android и непонимание, зачем нужен Mir.

Впрочем, замечу, что Jolla пытается накостылить поддержку способа №4 в Weston [4].

Часть III, server allocated buffers

Wayland нам абсолютно неинтересен. Смотреть надо на Weston, и он действует так: клиент просит у видеодрайвера буфер, рисует в него что-то, а затем передаёт этот буфер и время, когда он был отрисован, для Weston через протокол Wayland с просьбой нарисовать. В Mir сделано иначе: клиент просит у Mir буфер, затем пишет в него что-то, затем просит другой буфер и одновременно передаёт имеющийся буфер для отображения на экране. Клиент работает через библиотеку mir-toolkit и не зависит от того, какие именно данные идут от него по сокету.

Преимущество подхода mir в том, что mir может воровать буферы у неактивных приложений и тем самым давать огромную экономию памяти [5]. Именно так сейчас поступает android, и, насколько известно, ios [6] [7].

Часть IV, ввод

Акселерометры, множественные касания, виртуальная клавиатура и аппаратная клавиатура, геймпады, датчики роботов — всё это уже сейчас работает в android. Mir просто взял эту часть гугловского surface flinger и перенёс к себе, отделив его от остального кода и подключив boost, добавил трансляцию в API Mir. Трансляция прямая, например, тип события мыши или касания напрямую кастуется в соответствующий enum из библиотеки mir-toolkit, и дальше передаётся клиенту (и тут же поправлюсь: 4 июля 2013 года кастования типа убрали для ещё большей совместимости с android, потому что иногда приходящее от Surface Flinger значение не укладывается в enum). Как результат, Mir поддерживает абсолютно все фичи ввода, доступные андроиду.

Тем временем в Weston всё ещё продумывают каждую мелкую деталь событий ввода в протоколе wayland. Это прекрасная работа и отличный задел на будущее, но полноценной обработки ввода на weston под android не будет в ближайшие 5-10 лет. Но тут есть выход: если в дисплейный сервер Mir будет добавлена поддержка протокола wayland, то он сможет транслировать события ввода андроида в протокол wayland и потребует для этого гораздо меньше отладки, чем Weston, потому что код mir уже покрыт тестами и может хостить Qt-шные приложения для андроида неотличимо от Surface Flinger.

Часть V, client-side decorations

Каждый тулкит рисует client-side decorations по-своему. Ниже будет список нюансов CSD, для которых должна быть поддержка со стороны каждого из тулкитов — и это очень грустная ситуация, потому что число тулкитов, способных написать и отладить весь этот код со всеми нюансами, резко сокращается. Уже сейчас только Qt5, gtk3 и EFL более-менее поддерживают последние решения вейланда. Итак, нюансы:

• Wayland не заставляет использовать клиент-серверные декорации, но мы уже знаем, что надо смотреть на Weston. Weston в общем и в целом заставляет, если не считать инициативу мейнтейнера kwin.
• Для тайлинга, полноэкранных окон и окон на пол-экрана CSD надо частично отключить. Wayland в лице его основателя предлагает [8] давать окнам подсказки, какие именно стороны окна должны быть без декораций. Кстати, именно так kwin может добиться серверных декораций — просто отключив CSD для всех четырёх сторон окна. На андроиде CSD не нужны, как и на любых устройствах с маленьким физическим размером экрана.
• Заголовок окна не рисуется для развёрнутых на весь экран окон в Unity, KDE Plasma Netbook [9] и, насколько я знаю, в GNOME. Wayland никак об этом не сообщает, но можно использовать тот же механизм, что для глобального меню.
• Порт Qt на wayland получает оверхед из-за CSD, и поэтому в Qt оставлен флаг для отключения CSD. Скорее всего, у других тулкитов будут те же трудности. Тем более CSD создают очевидный оверхед по оперативной памяти из-за того, что каждое приложение само собирает и хранит в памяти копию всей графики (растровой или векторной), необходимой для декораций.

Напоследок процитирую слова Мартина Грэсслина:

Is this fear valid? Well during said presentation Weston was running with two windows. They had different decorations. One was the terminal with minimize, maximize and close button on the right. One was a pdf viewer with a standard GNOME Shell decoration: minimize button missing. And during FOSDEM I had also a look on the decorations for Qt Wayland: again different decorations.

GNOME уже не раз убирал из своих приложений и из GTK фичи, непосредственно нужные другим DE. Например, автора Transmission попросили выкинуть что-то из уведомлений [10], причём багу присвоен тип «Улучшение» ☺. Дальше диалог развивался так:

Removing it altogether, as you suggest, will hurt XFCE users. I wish GNOME, Canonical, and everyone else involved would settle on one consistent API for this and stop fucking the app developers over.

Ответ:

I guess you have to decide if you are a GNOME app, an Ubuntu app, or an XFCE app unfortunately. I'm sorry that this is the case but it wasn't GNOME's fault that Ubuntu has started this fork. And I have no idea what XFCE is or does sorry.

Никогда у вас не будет нормальных клиентских декораций в официальном GTK 3. Забудьте об этом. Могут помочь те, кто патчит GTK в своём дистрибутиве — но пока конкретно этот тулкит более-менее патчит только Canonical.

Поддержка вейланда в GTK, раздел Client Side Decoration:

The goal here is to recreate the Adwaita-style decorations, including 
...
- rounded corners
- dark theme variant
...

Никакого единого стиля не будет. В теории в GTK есть css, но по слухам его ломают непрерывно.

Источник забавы. Для Ъ:

// 3rd variant
static bool compareCCString(const CCObject* p1, const CCObject* p2) {
    const char* obj = (const char*)p1;
    const char* obj1 = (const char*)p2;
    return strcmp(obj,obj1);
}

// 4th variant
static bool compareCCString(const CCObject* p1, const CCObject* p2) {
    CCString*  obj = (CCString*)p1;
    CCString* obj1 = (CCString*)p2;
    int temp_length1 = sizeof(obj->getCString());
    int temp_length2 = sizeof(obj1->getCString());
    int i=0;
    while ((i < temp_length1) && (i < temp_length2)) {
        if (tolower (obj->getCString()[i]) < tolower (obj1->getCString()[i]))
            return true;
        else if (tolower (obj->getCString()[i]) > tolower (obj1->getCString()[i]))
            return false;
        i++;
    }
    return false;
}

Я даже не хочу там больше ничего писать.

Это вольный перевод статьи, намедни размещённой на phoronix. Оринальная статья — обзор недостатков, их исправлений и преимуществ между X и Wayland. Её написал Eric Griffith, при участии Daniel Stone, специально для ресурса phoronix. Работа собрана по кусочкам из презентаций Keith Packard, David Airlie, Kristian Høgsberg, из страниц про X11, X12, Wayland в вики и на freedesktop.org, из прямых интервью с разработчиками.

Оригинал выпущен под Creative Commons версия 3, с указанием авторства; перевод доступен на тех же условиях (с указанием на авторов оригинала, как мне кажется).

( читать дальше... )

>>> Подробности

На ЛОРе порой появляются люди, желающие поучаствовать в любительском геймдеве, написав что угодно, но обязательно под онтопик; а в недавнем опросе нашёлся 221 человек с опытом разработки игр для себя лично.

Но дальше дело идёт по одному из двух сценариев:

• Человек хочет использовать навороченную 3D графику, не понимая, что обычно AAA игры с 3D графоном пишет целая команда, где каждый сам по себе неслабый специалист, а в сумме команда имеет такой багаж знаний и опыта в самых разных областях, что одному человеку это совершенно не грозит.
• Человек пишет сверхпростую (на его взгляд) 2D или 3D first person shooter игру с нуля, в результате не может продумать архитектуру, выделить слой абстрагирования от платформы, мечется между языками и системами сборки и в итоге увязает в проблемах с головой.

Нафига так мучиться, тем более в опенсорсе? Дело в том, что есть такой движок cocos2d-x, разрабатываемый китайскими товарищами для мобильников и используемый в ряде коммерческих игр (следовательно, смерть ему не грозит). Движок работает на Оффтопе/Онтопе/Гейтопе, куче мобильников (даже tizen), имеет пермессивную лицензию и всё своё носит с собой (благодаря чему можно спокойно патчить свою версию движка).

Линукс официально поддерживается, но качество поддержки хуже, чем у android/iphone/win32, а для сборки в разделяемую библиотеку используется Makefile (с -Werror впридачу).

Так почему бы фанатам-игроделам не сделать что-то на основе этого движка? Во-первых он действительно проще типичных 3D движков, во-вторых у компании-разработчика есть желание поддерживать все платформы, но нет рабочих рук, в-третьих качество кода во многих местах хуже желаемого (например у заведомо константных методов пропущены const, а у принципиально некопируемых классов не закрыт конструктор копирования) и написать парочку нужных патчей всё ещё достаточно просто, в-четвёртых для линуксоида мобильная разработка — отличный шанс получить работу, не сталкивая свою психику с оффтопиком и его порядками.

P.S. Кстати, могу показать, как настроить себе сборку игрушки, использующей cocos2d-x, в QtCreator.

Вот и выпустили очередную версию Tizen. И стоило мне взглянуть на список изменений, как к сердцу подкатила тоска. Я процитирую то, что меня смутило.

Одновременно для разработчиков мобильных приложений выпущен пакет Tizen SDK 2.1, в состав которого входит среда разработки на базе Eclipse, ...

Тозмоза, оперативка нынче дешёвая, проектирование интерфейса для слабаков

...эмулятор телефона на основе QEMU

Тормоза в квадрате, привет своп

Разработчикам мобильных приложений предоставлена возможность используя технологии HTML5 создавать кроссплатформенные приложения, одинаково хорошо работающие на широком спектре устройств

У мозилловцев хотя бы опыт в этом есть, и немалый.

Улучшенный фреймворк для разработки мобильных приложений с использоваинем web-технологий.

Основанный неизвестно на чём, следовательно не имеющий инструментов, кроме своих велосипедов из Chromium.

Среди компонентов графического стека: DRI2 и libdrm, композитный оконный менеджер на базе EFL, OpenGL ES 1.1/2.0, EGL 1.4, бэкенды для программного вывода (X11) и акселерированного вывода (OpenGL ES), 3D- и 2D-стеки, в том числе поддержка векторной графики через библиотеку Cairo;

...Во фреймворке задействованы такие открытые компоненты, как Appcore, DBus, GNU gettext, libICU;

...набор стандартных системных библиотек, обеспечивающих выполнение таких операций как доступ к БД, интернационализация и обработка XML;

...Для настройки 3G и Wi-Fi соединений используется конфигуратор ConnMan (Connection Manager). Для работы с Bluetooth используется пакет bluez; ...Сервисы для отправки и приёма сообщений (SMS, MMS, Email и IM);

...Мультимедиа подсистема на базе GStreamer,

...PIM

...Шифрование и поддержка SSL/TLS реализованы при помощи OpenSSL;

...Стек телефонии

И стоило ли менять унифицированный и удобный API от Qt на зоопарк?

Ну и самый главный вопрос: на что они надеются с таким SDK, если вместо улучшения существующего и облегчения работы программиста они решили пойти наперекор iOS/Android и натаскать в свою систему всего что под руку попадётся, а остальное просто скопировать, причём хреново? Где 8 разработчиков от Самсунга и Интеля, работающих над ядром Eclipse?