немного протухшая новость от 17го числа:
http://www.xda-developers.com/android/mediatek-android-one-source/
Для Ъ: медиатек запилил гит для своего ядра на https://android.googlesource.com/kernel/mediatek/
Посмотрим, что из этого выйдет...
в одной из операционных систем есть такая подсистема:
msdn.microsoft.com/ru-ru/library/windows/desktop/ms685150(v=vs.85).aspx
Мне в ней важно то, что там определен протокол запуска и остановки сервисов и интерфейс, который должны поддерживать сервисы, чтобы считаться сервисами. А ещё сервисы могут взаимодействовать с десктопом (создавать окна).
Где про systemd прочитать то же самое? (напишите, пожалуйста, правильные ссылки) особенно про графическую пользовательскую сессию, но и про спецификацию интерфейса для демонов тоже интересно (утверждена ли она как открытый стандарт)...
Ещё такой вопрос - наверняка в DE есть способы запуска приложений при старте DE. И они как-нибудь могут повисать в трее. В принципе, эта вторая компонента могла бы коннектиться к сервису и по его запросам открывать окна...
Давно в чертогах разума есть у меня идея принципиально нового дистра.
Зачем оно надо: для увеличения модульности системы так, чтобы стало проще и безопаснее, но при этом ничего не сломалось.
Суть: как кажется на первый взгляд, посылаем FHS лесом, кладём базовую систему отдельно, обновления отдельно, программы отдельно. Вместо точкопомойки в хомяке каждому приложению заводится отдельная директория в ~/.appdata.
Чтобы запустить приложение, монтируем в отдельную директорию с помощью unionfs базовую систему, обновления к ней, собственно программу, аппдату из хомяка и куски реального пользовательского хомяка, которые пользователь хочет отдать в распоряжение программе (тут надо сделать красивые cli и gui, чтобы в рантайме можно было добавлять/удалять доступ к пользовательским директориям). И запускаем приложение в чруте.
Структура файловой системы получится примерно такая:
/meta/
home/
user/
Pron/
Documents/
Downloads/
...
.appdata/
firefox/
.mozilla/
pidgin/
.purple/
base/
bin/
usr/
...
updates/
2013-10-10/
usr/
...
2013-11-15/
usr/
...
apps/
firefox/
root/
usr/
bin/firefox
...
icon.png
manifest
pidgin/
root/
usr/bin/pidgin
...
...
roots/
0000/ # mounted with base, updates, home and running system ui
usr/
home/
...
0001/ # mounted from base, updates, firefox root, /home/user/Downloads and /home/user/.private/firefox
usr/
bin/firefox
...
home/user/
Downloads/ (/meta/home/user/Downloads)
.mozilla/ (/meta/home/user/.appdata/firefox/.mozilla)
...
0002/ # mounted from base, updates, pidgin root and /home/user/.private/pidgin
usr/bin/pidgin
home/user/.purple
...Плюсы:
Минусы:
К велосипедостроению приступлю ориентировочно после закрытия сессии.
сабж
Делаю пост сюда, чтобы линковать его людям. Ибо на лоре есть разметка
Ситуация: Живём много лет на sysvinit, появляются всякие openrc и upstart, на которых работают две системы их большого количества. Появляется systemd и сразу большое количество систем переходят на него. Почему? Обьясню на примере debian, тестовой ветки и systemd из этой же ветки.
Почему появилось желание поменять sysvinit на чтото другое?
1) Структура скриптов для sysvinit подразумевает только возможность запуска скриптов с флагами start и stop. Внутреннее устройство скрипта ЦЕЛИКОМ на совести разработчика. Конечно это не повод считать что все скрипты для sysv говно, но всётаки встречаются такие экземпляры, что хочется просто плакать, когда их читаешь. Особенно изза того, что большую часть логики слежением за стотоянем службы пишется на баше. Хотя нынче половина инит скриптов завязанны на start-stop-service. В итоге - каша.
2)Никаких средств для учёта очерёдности запуска сервисов и паралельной их загрузки. Да, есть insserv, только оно ещё больше каши добавляет в скрипты инициализации.
Почему не upstart?
Уже несколько лет в дебиане висит, и ещё не пыталось стать стандартной системой инициализации. В нынешней ситуации, когда говорят о фичах, которые уже есть в других системах инициализации - говорят - «пфф, мы можем тоже такое написать» (тот же cgroup). В итоге функционал апстарта в текущем его состоянии ушёл не дальше sysvinit+insserv+start-stop-daemon. Зато хипстер-аура вокруг него просто знатная.
Почему не openrc?
Оно ещё старше, чем upstart, но разговоры о нём толком начались только при выборе между upstart и systemd. В итоге оно на бумаге конечно лучше чем systemd, но практически это даже проверить не возможно. Некая мифическая сущность, сферическая и в вакууме.
Почему systemd?
1) Он уже работает в тестинге, и не полагется на fallback на sysvinit. Когда я последний раз пробовал upstart без sysvinit скриптов он не работал, и все его преимущества скатывались в ничто. Просто не использовались. В итоге ситуация выглядит так:
systemd - сначала сделали поддержу, потом ещё предложили как стандарт.
openrc и upstart - сначала предложили, а поддержки нету, никакой. Вот если выберут - то поддержка будет. По мне - нарушение причинно-следственной связи.
2) Использование cgroup невероятно упрощает внутреннюю логику юнитов для запуска сервисов. СИИИИИИИИИИИИИИИИИИИИИИИИИИИИИИИИИЛЬНО.
Вот например юнит для bluetooth демона
[Unit]
Description=Bluetooth service
[Service]
Type=dbus
BusName=org.bluez
ExecStart=/usr/sbin/bluetoothd -n
[Install]
WantedBy=bluetooth.target
Alias=dbus-org.bluez.service
а теперь выполним одну весёлую комманду
khades@debian:/etc/init.d$ cat /etc/init.d/bluetooth |wc
201 584 4474
А теперь о мифах про systemd.
JOURNALD БИНАРНЫЕ ЛОГИ ХУЖЕ ЧЕМ В RSYSLOG
syslog - это стандарт отправки и регистрации сообщений о происходящих в системе событиях
rsyslog - программа для организации хранения этих сообщений, полученных по системной шине, реализованной в ядре linux (/dev/log)
journald - легковесный сервис для хранения и чтения логов с хранением их в памяти для ускорения процессов ввода\вывода во время загрузки с ОПЦИОНАЛЬНЫМ хранением бинарей на диске. НЕ ЛОМАЕТ rsyslog.
PID 1: ВСЁ УПАДЁТ ЕСЛИ УПАДЁТ SYSTEMD
1) Почему systemd должен упасть?
2) Ядро тоже падает, давайте все ненавидеть ядро
PID 1: СИСТЕМД МНОГО ВСЕГО В ОДНОМ ПРОЦЕССЕ ДЕРЖИТ И МНОГО НА СЕБЯ БЕРЁТ!!!!
1) Для изоляции запускаемых процессов и придуман CGROUP.
2) khades@debian:~$ ps aux |grep systemd root 284 0.0 0.1 297788 11032 ? Ss фев13 0:01 /lib/systemd/systemd-journald root 295 0.0 0.0 42944 1924 ? Ss фев13 0:00 /lib/systemd/systemd-udevd root 2448 0.0 0.0 36928 1636 ? Ss фев13 0:00 /lib/systemd/systemd-logind
ПОТЦЕРИНГ ЧТОТО ПОМЕНЯЕТ И ВСЁ СЛОМАЕТСЯ
Даа, и это сразу попадёт в стейбл дебиана. инфа 100%.
И последнее, касаемо непортируемости на другие ядра. В нашем случае глупо не использовать передовую технологию (CGROUP) ради совместимости с принципиально другой системой, учитывая то количество ништяков, которое оно нам даёт реализовать. Я вообще в далёком будущем представляю как на помойку выкидывают selinux, потому что домены безопасности реализуют на основе namespaces и cgroup. Ах мечты, мечты.
Казалось бы, в современном Linux благодаря стандартам freedesktop можно просто взять и собрать кросс-дистрибутивный пакет для любого графического приложения, который будет располагаться в хомяке и таскать с собой все нужные библиотеки.
Делается это так:
И всё работает, и любая DE видит эту программу, и пользователи плачут от радости.
Но не тут-то было. Потому что в Linux нет API с обратной бинарной совместимостью. Потому что LSB — лживый недостандарт, предназначенный исключительно для подсаживания дурачков на вендорную иглу и сколачивания бабла (Ульрих Дреппер, бывший лидер проекта GLIBC, писал об этом ещё в 2005-м; я проверил ситуацию пару дней назад — и увидел, что LSB dll hell проявится даже в таких «правильных» дистрибутивах, как OpenSUSE).
А как бы всё-таки мог выглядеть этот API, который должен быть на любом CD с любым дистрибутивом и должен появляться сразу после установки в любом дистрибутиве? Тут три критерия: минималистичность, привлечение разработчиков с других платформ и самодостаточность.
По моим современным личным представлениям, любая библиотека в идеале выполняет ровно одну из двух задач: предоставляет API или является фреймворком. Библиотека-API минималистична и массштабируема, но требует знания матчасти и множественных проверок кодов возврата: на ней можно написать быстрый и качественный движок (графический, звуковой, рендеринг шрифтов), но использовать такое в приложении напрямую без обёрток может только недалёкий человек. Библиотека-фреймворк, напротив, выполняет общие задачи не задаваясь максимальной гибкостью, но зато с удобством; при этом фреймворк должен либо иметь обратную бинарную совместимость в течение многих лет, либо его надо встраивать в пакет с приложением; примером первого подхода является Qt, примером второго - cocos2d-x.
Исходя из этих представлений, я вижу так:
Какие ещё библиотеки должны попасть во второй слой API? И может быть, я что-то упустил из виду?
P.S. Генту идёт в лес. Если вы готовы собирать то же приложение из исходников или оптимизируете работу сервера — флаг вам в руке, но о готовых пакетах с десктопными приложениями забудьте, сами же отказались от этого в своей идеологии.
Итак, пожалуй уже есть чем похвастаться. Самый, так сказать первый вариант, преальфа. Надоело мне ждать пока KDEшники запилят свой планшет, потому решил сделать это сам.
Да, девочки, Debian Wheezy на armhf это вам не розовая Gentoo на x86. Это свое, особое красноглазие не для слабонервных ;) После чудных приключений в 4х сериях я таки запустил (пока поверх fb и с sd карты (ядро в нанде)) KDE4 на RK3188. Как это не странно, но гуй не особенно тормозит даже на позорном тормозном софтовом рендере, включая перетаскивание и ресайз (хотя матрица-то 2048х1536). Артефакты имеются на сложных лейаутах но отчего и почему только предстоит выяснять.
Прошлые серии детектива: [ один | два | три | четыре ]
Собственно, с 4й серии изменилось немного. Я немного докрутил драйвер lcdc0, чтобы завелся без проблем fbcon по дефолту. Заодно теперь оно не паникует при попытке прочитать disp_info в /sys/class/graphics/fb0/. Более того, оно и лог загрузки теперь стало без проблем выводить и даже с цветом. Жаль только лого при включенном fbcon оно не рисует.
Выпилил к чертям свинячьим RK_EARLYPRINTK и эпичный костыль с консолью поверх FIQ дебаггера (sic!). Там где-то был рейс намертво вешавший иногда систему, потому как только я избавился от этой содомии все стало намного стабильнее и отзывчивее.
Немного разгреб костыли в board файле и добавил поддержку звука, хотя пока еще не проверял еще.
Прошелся по сырцам dwc_otg драчовым напильником повырубав к чертям свинячьим лишний и весьма раздражающий дебаг.
Немного докрутил степпинг частоты DDR, на 600 Mhz работает стабильнее и сильно быстрее.
Немного докрутил степпинг проца по частоте, выставив заявленные 1.8Ghz вместо 1.6Ghz в пределе. Пока полет нормальный.
Ну и, наконец, самое главное - я запустил KDE4. Пока поверх /dev/fb0, без мали, в моем ядре нет даже упоминания о том, что оно существует. Есть в соседнем бранче ядра откуда надо это дело перетаскивать и раскуривать если что будет не так.
Тачскрин не подхватился evdev'ом, подозреваю что неправильно прописаны капсы и надо его будет немного того, докрутить немного. Так что пока залогинился при помощи усб клавиатуры и мыши.
В общем медленно и уверенно движусь к победе, раз за разом убирая элементики из чеклиста того, что еще предстоит сделать и с каждым разом убивая все больше и больше спагетти. Так что достаточно скоро я дойду до момента, когда можно будет сказать гудбай ведроеду и с чистой совестью прошить все это хозяйство в NAND.
Следите за новостями и подписывайтесь на тег rk3188. Образы и сырцы будут выложены на шитхаб сразу, как только будет рабочая (более или менее) система с работающим более или менее мали. А еще там on2 нетыканный...
>>> Просмотр (2048x1536, 1018 Kb)
Я просто решил оставить тут несколько фактов о принципах работы 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² раз. Как мы все уже знаем, современные тулкиты рисуют готовую картинку и отправляют её серверу, но делать это можно четырьмя способами
Впрочем, замечу, что 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 более-менее поддерживают последние решения вейланда. Итак, нюансы:
Напоследок процитирую слова Мартина Грэсслина:
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.
Пользователь Gnome3, инженер по имени Rob Rhinehart полностью отказался от натуральной пищи и теперь питается исключительно специально разработанной им питательной жижей. Роб пропагандирует свой способ питания и призывает всех присоединяться к нему.
Ребят, такая проблема-у меня смартфон sony xperia tipo. Решил поставить CM10 делал так: 1.Получил рут-здесь все понятно. 2.Разблокировал загрузчик-тут тоже все понятно 3.Поставил cwm-рекавери чтобы поставить СМ10 4.Прошил ядро 5.Установил через рекавери см10 Все запустилось и прекрасно работает. Ой, простите, работало. Ну так вот, у меня не устанавливались приложения. Тут я совершил роковую ошибку-зашел в настройки и нажал общий сброс. Кто меня просил? Можно было через рекавери сделать общий сброс. Но нет!!! Мне захотелось именно так! Телефон погас и больше не включился. Есть тулза для восстановления прошивки, но вот беда, телефон не входит в flash mod. Еще появилась классная особенность-комп распознает телефон даже если из него вынуть батарею. Венда распознает его как «неизвестное устройство». Судя по-всему я затер бутлоадер к чертям. Может кто подскажет как его можно восстановить или еще что нибудь. Телефон на гарантии, но меня пошлют, гаверное...
А на подходе 8 издание OpenGL Programming Guide http://www.amazon.com/OpenGL-Programming-Guide-Official-Learning/dp/0321773039
Ну что вы, бетмены, стоит заказывать?
На курсере открылся курс «Exploring Quantum Physics»
https://class.coursera.org/eqp-001/class/index
AiFiLTr0, Лор Стади Груп есть, присоединяйся!
Кому интересно, можете посмотреть (виртуальные туры):
http://clck.ru/4CjY2 - музей в махачкале (добавил экспонаты. 52шт);
http://clck.ru/4CjY6 - крепость в дербенте (еще не показывал);
http://clck.ru/4CjZG - руины села (не показывал).
Отпишитесь о багах - скажу спасибо. Тестов мног оне бывает. Пока известен баг при входе в музей на территории крепости (черный экран). Исправляю.
Сейчас занят финальной волной ретуши, чищу пыль на панорамах.
Ссылки сокращанны нормальным сервисом, цель - не палить их в гугле раньше времени. js - требуется. флеш - желателен, хтмл5 - поддерживается, но с ограничениями (нет мультирезолюшена изображений и нет отработки события onhover).
Если вы уже смотрели музей - лучше сросить кэш. иначе, к примеру, ФФ - тупо покажет старый контент.
Независимый разработчик Marek Olšák продолжил оптимизировать узкие места в открытом графическом стеке. На этот раз он решил вынести ряд тяжелых операций в нити (thread offloading). В частности, ведется работа над реализацией асинхронных SwapBuffer-ов, работа с которыми ведется в отдельной нити.
Подобная инициатива позволит заметно увеличить скорость работы программ, которые ограничены производительностью CPU, например таких как игра OpenArena. Общая идея состоит в том чтобы с буферами работала отдельная нить драйвера, а библиотека libGL только инициировала эту операцию и получала уведомление о ее завершении через callback-функцию. К этому моменту можно обработать часть нового кадра не дожидаясь завершения (потенциально длительной) операции с буфером.
Сабж.
И еще хороший учебник по квант.механике. (с курсу универа помню мало).
Основные удаленные фичи в новой версии:
Другие улучшения:
С улучшенным Наутилусом можно ознакомиться в Ubuntu 12.10 Alpha 3.
Продолжаем славную традицию ckotinko по созданию злых тредов.
Иксы 1.12.3, nouveau, карточка gf5500. Обнаружил сейчас, что наш распрекрасный nouveau не умеет в аппаратный композитинг. Ага. XRenderComposite выполняется программно. То-то я смотрю: compton тормозит. Запустил sysprof, а там 40% CPU система проводит в модуле libpixman. И в самом деле — зачем мне видеокарта^Wхолодильник, если я не курю?
Вот не знаю теперь... может compton на OGL переписать? Ну это всяко проще, чем переписывать иксовую часть нувы — такое я точно с разбегу не осилю. OGL-то хоть этот чудо-драйвер умеет ускорять? Сейчас поставлю что-нибудь OGL-ное проверить.
Безобразие, господа. Вот при Сталине^W^Wв блобе такого не было!
Кто не в курсе, речь о практически официальном форуме поддержки Linux-блоба nVidia, на который захаживали разработчики драйвера. MikeC - его администратор, и сотрудник техподдержки nVidia.
В общем, Задорнову понравилось бы:
This strange MikeC behaviour was because of me.
Here is what happened:
Someone started a new topic about Linus middle finger shown to Nvidia with link to youtube video showing this. MikeC posted below response that all discussion about bad and unacceptable Linus behaviour is forbidden on this forum and locked the topic. The problem with MikeC was that he focused on Linus finger and bashing at him but didn't say a word about why Linus had shown the finger. I understand MikeC behaviour because he is American and people there focuses on «wow Linus has shown a finger to Nvidia» where European people usually would ask why Linus has shown the finger. What was his motivation to make such unusual for him gesture? I made a new topic saying this is censorship and tried to explain what was Linus feelings about Nvidia. (I live in Eastern Europe/former soviet block so maybe I'm too sensitive when freedom of speech is limited.). I also told that there is more people who would like to show finger to Nvidia and have good reason to do that (then described usb 1.1 freezing on geforce 8200 chipset - Nvidia reproduced and confirmed this bug but never provided patch to fix it - this is fixable because Solaris/FreeBSD/Windows does not have this bug). People wrote in comments that I'm whining and Nvidia makes great GPUs completely ignoring the fact that I was talking about mainboard chipset and usb problem in it. MikeC locked the topic so I could not explain that I do not have problems with GPUs but chipset and Nvidia should be ashamed not fixing it. Try to use PC without usb these days.
MikeC created statement and made it sticky that:
- he would like to kick Linus and my (@zbiggy nvnews nick) ass because of what we have done,
- nobody accused him and his family so badly like me,
- he would close Linux forum on nvnews because of me if it wouldn't be his only way of earning money for him and his family,
- he asked forum ISP to close and send him Nvidia Linux forum content.
Nvidia Linux forum then became read only. He made my post about censorship sticky. Later Nvidia Linux forum was not available.
Then it was restored. I wrote pm to MikeC with apology I told him I understand that in US there is no censorship but private property and understand that forum owner has right to block posts he do not like and decide what will (not) be discussed. I asked him to make my topic about censorship not sticky to let it fall down in forum history out of users view. I removed my name and other personal details from my profile. Tried to delete all my post but could not. I visited nvnews daily since 2003 and made many posts. Now this is over. I will never go back there. nvnews will be better without me. It is sad that people focused on Linus and his finger but not the reason of showing it. It is sad that Nvidia became victim when actually was source of all this evil.
| ← назад | следующие → |
