Brodyaga: люблю свой двор...крики маленьких детей, стук мяча об асфальт, звон стекла, визг сигнализации, крик "блять, съебываемся!" и веселый топот десятков ножек...
-------------------------------------------------------------------------------
Обитатели мегаполисов оценят...
К нам седня пришел мужик и заказал 500(!) визиток с надписью "Если моя машина мешает вам выехать, позвоните 8-903-ххххххх" О_о
Проблема возникает при установке Windows после Linux или при ошибке в процессе установки Linux. Загрузчик и его настройки меню лежат на какой-то партиции, но запись в MBR повреждена.
1. Загружаемся с какого-нибудь LiveCD, где есть Grub. Подойдет любой Ubuntu.
2. В консоли командуем sudo grub и ждем пока запустится интерпретатор команд.
3. Командуем find /boot/grub/stage1 чтобы увидеть обозначение партиции, где уже стоит Grub, у меня это (hd0,1), можно просто посмотреть в файле /boot/grub/menu.lst
4. root (hd0,1)
5. setup (hd0)
6. quit
7. Перезагружаемся, Grub ожил.
Пробовал такой способ:
1)Грузимся под LiveCD и монтируем диск с Linux в какой либо каталог (к примеру /mnt/linux).
2) #chroot /mnt/linux - меняет / на /mnt/linux
3) #grub-install /hda - устанавливаем загрузчик
Таким же способом можно восстанавливать lilo.
Пишем в адресной строке 'about:config', в полученном списке находим следующие параметры (можно воспользоваться поиском): network.http.pipelining network.http.proxy.pipelining И выставляем их в 'true'. По умолчанию браузер делает запросы к серверу последовательно, а при включении pipelining все запросы будут выполнены параллельно. Затем параметр: network.http.pipelining.maxrequests Выставляем его например в '32'. Это число - максимальное кол-во параллельно выполняемых запросов. И последний: nglayout.initialpaint.delay Выставляем в '0'. (Скорей всего такого параметра ещё не существует, - нажимаем правую кнопку мышки и выбираем в меню 'New'=>'Integer'. Вводим имя - 'nglayout.initialpaint.delay' и присваиваем значение '0'). Это число определяет задержку перед отображением полученных данных.
Вирішив я встановити mplayer, до цьго я користувався тільки XINE.
Встановлення було дуже легким, оскільки я використовую Fedora7 то інсталяція була зроблена так:
yum install mplayer* -y
Після того як було встановлено всі необхіні пакети я вирішив перевірити роботу mplayer-а. Після запуску mplayer-а він вивалився з помилкою:
Sorry, your system does not support the XShape extension.
після деякого повзання по Google я знайшов вирішення пробеми тільки на двох сайтах. Один з них напевно веде людина зі сходу напевно з китаю http://lky137.blogspot.com/2007/07/mplayer.html, а інший був бразильський сайт http://www.fedora.org.br/fortopic6161.html. Це були єдина інформація про то як вирішити проблему з Xshape. Китайський варіант я вирішив не робити, оскільки коментарі були не зрозумілі і тому можливо було допустити помилку. Я вирішив зробити так як було рекомендовано на бразильському сайті, там хоть коментарі можливо було розібрати.
Перед тим як щось робити з /etc/X1/xorg.conf я зробив його копію /etc/X1/xorg.conf.original і почав конфігурувати.
1.Спочатку було підправлено секцію "Module", сюди було добавлено sub-секцію "extmod":
SubSection "extmod"
Option "omit xfree86-dga"
EndSubSection
2.Потім було підправлено секцію "Screen":
Option "AddARGBGLXVisuals" "true"
3. І в самому кінці xorg.conf було дописано секцію "Extensions":
Section "Extensions"
Option "Composite" "enable"
EndSection
Правда після перезапуску іксів моя машина зависла!!! Нічого не залишалось робити як робити жарсткий reboot шляхом натискання відповідної клавіши на системному блоці. Після перезавантаження ікси загрузились без проблем і саме головне MPlayer запрацював!!!
копируем все пакеты rpm с дисков в папку /home/rpms/
устанавливаем createrepo(есть среди скопированных пакетов) (rpm -i createrepo...)
запускаем сreaterepo указываем папку /home/rpms/
createrepo /home/rpms
затем создаем файл /etc/yum.repos.d/msiu.repo следующего содержания
[msiu]name=ASPLinux $releasever - $basearch - MSIU
baseurl=file:////home/rpms
gpgcheck=0
остальные файлы в папке /etc/yum.repos.d изменяем (ставим # во всех строчках)
готово
-------------------------------------------------------------------------------------------
ИСПОЛЬЗОВАНИЕ YUM
yum install PAKET
yum remove PAKET
yum update PAKET
yum provides PAKET
PAKET - название программы
-------------------------------------------------------------------------------------------
Находить новаторские программы в стандартной поставке дистрибутива - это, согласитесь, приятно и неожиданно. Обычно к операционной системе прилагаются лишь те программы, которые успели себя зарекомендовать годами службы. От этого, вероятно, наиболее популярные дистрибутивы остаются такими скучными.
В Ubuntu всё же скрывалось несколько интересных вещичек. Это и Tomboy, о котором я уже писал, и недавно обнаружившийся "анализатор использования дисков". "Анализатор" этот - ничто иное как Baobab - опенсорсный аналог программы SequoiaView.
Но по сравнению с SequoiaView он куда интереснее. Карта диска (пространство, разделённое на секторы, каждый из которых представляет файл и имеет размер соответствуюзщий объёму файла) здесь тоже есть, но это лишь вспомогательный инструмент.
Куда приятнее работать с хитроумной круговой диаграммой, рисующейся по ходу просмотра каталогов. Диаграмма эта изображает использование дискового пространства в текущем каталоге: по часовой стрелке в ней откладываются сектора-подкаталоги или файлы, располагаясь в порядке от меньших к большему; от центра к радиусу идут уровни вложенности. Причём для наглядности отображаются только самые крупные файлы и каталоги. Переместившись в очередной подкаталог, мы получим диаграмму относительно него.
Разбираться "куда же делось всё место" с такой программой - одно удовольствие. Кстати, поддерживаются и сетевые диски, так что порядок можно навести и на FTP. FTPpie для Windows, о котором писал Андрей Крупин с красавцем "Баобабом" не идёт ни в какое сравнение.
Linux
Автор: Андрей Письменный
Опубликовано 28 сентября 2007 года
Miro - это новое название проекта Democracy. В двух словах программу можно описать как агрегатор rss с видео. Главные его преимущества: умение "потрошить" любые rss и находить видео даже в том случае, если в ленте обнаружиться лишь ссылка на страницу с файлом, умение качать "торренты", искать и скачивать ролики YouTube.
Сделан Miro на основе движка XULRunner, используемого в Firefox, а XULRunner хорошо известен своей прожорливостью к ресурсам и способностью выглядеть во всех системах откровенно чуждым. Если первое замечание в полной мере оправдывается, второе верно только для Windows. Для Linux и Mac OS создатели Miro постарались сделать более или менее правдоподобные "родные" интерфейсы.
Автор: Андрей Письменный
Опубликовано 18 сентября 2007 года
Начать рассказывать о программах для Linux я планировал ещё в блоге об операционных системах, но раз у нас появился специальный блог о программах, почему бы временно не перенести разговор сюда, оставив в .sys только темы, касающиеся непосредственно системы.
Далеко ходить за первой темой мне не пришлось. Ещё бы, ведь это программа, в которой я пишу этот постинг. Нет, это не OpenOffice (боже упаси!), не AbiWord и даже не gedit (хотя его в работе я тоже часто использую). В качестве редактора я долго использовал Google Docs, но теперь потихоньку перехожу на Tomboy.
Tomboy - это не текстовый процессор, да и текстовым редактором программу можно назвать лишь с большой натяжкой. В прошлой жизни Tomboy был имитатором "липких бумажек" для рабочего стола, но теперь концепция несколько изменилась.
От липких бумажек остались одни пиктограммы, а доступ к заметкам можно получить, кликнув по значку на панели. Там же есть пункты для создания новой заметки и для вызова встроенного поиска. То есть всё необходимое под рукой в любой момент.
Второй повод любить эту программу - возможность создавать ссылки с одной заметки на другую. Достаточно выделить любое слово и нажать кнопку "связать". Слово тут же станет ссылкой, и появится заметка с таким же названием. Если название сменить, текст всех ссылок изменится. Система позаимствована из вики и идеально подходит для составления планов.
Некоторой функциональности, конечно, не хватает. Подсчёт знаков, проверка орфографии и синхронизация с какой-нибудь настоящей вики сделали бы Tomboy просто бесценной программой. Впрочем, модуль для экспорта записок в TiddlyWiki я всё же нашёл, но во-первых хотелось бы двусторонней синхронизации, во-вторых, даже этот модуль нашёлся только в виде патча к исходным кодам последней версии из CVS.
Автор: Андрей Письменный
Опубликовано 21 сентября 2007 года
Синхронизация - это наказание за жадность. Понаставил разных программ, понабрал полные карманы гаджетов, зарегистрировался в десятке сервисов и... понимаешь, что если всё это не будет работать вместе, толку не выйдет.
Самый простой пример - планировшик. Хранить его данные удобно в каком-нибудь Google Calendar, редактировать - в чём-нибудь вроде Outlook или Evolution, видеть ближайшие записи на рабочем столе - при помощи какого-нибудь хитрого виджета, плюс иметь возможность смотреть и добавлять записи на чём-нибудь карманном вроде КПК или смартфона.
Проблема с планировщиком конечно же решается, но решается сложно. Другие похожие проблемы могут не решиться вообще.
Чтобы прекратить бесконечные мучения и разрешить вопрос синхронизации раз и навсегда по крайней мере в Linux, была придумана программа Conduit. Поставленная сверхзадача пока, увы, не выполнена, зато готова бета-версия, доказывающая жизнеспособность идеи.
Сама программа - это только основа, позволяющая пользователю составить наглядную схему синхронизации. Каждый блок, который можно добавить к схеме - это так называемый провайдер данных - подключаемый модуль, позволяющий работать с тем или иным сервисом, программой или устройством. Каждый из них может работать в одну, другую или обе стороны.
Если Conduit уже более или менее готов к использованию, то провайдеров данных пока маловато. Из всего доступного мне пригодилась только синхронизация папки с Box.net и заметок Tomboy с сервисом Backpack.
И ни тем не другим я не доволен в полной мере: древовидная структура базы Tomboy становится плоской при переносе в Backpack (я уже писал, что предпочёл бы синхронизировать их с нормальной вики); Box.net работает не слишком торопливо, и для синхронизации требуется предварительно входить в него через браузер. Но я пока верю, что скоро станет куда интереснее.
Сборку Conduit для Ubuntu можно найти на getdeb.net
Автор: Андрей Письменный
Опубликовано 25 сентября 2007 года
Казалось бы, найти приличный торрентклиент для Linux должно быть очень просто. Я бы даже, быть может, удовлетворился той программой, что поставлялась с Ubuntu, если бы с её помощью можно было качать два файла одновременно. Но вторую закачку она стартовать не даёт, жалуясь на занятый порт.
Что же выбрать? Ставить всякие развесистые "Азеурусы" и "Битторнадо" с чужеродным оформлением желания не было. Запускать "Мю-торрент" под wine, как некоторые и делают, - это, на мой взгляд, вообще извращение.
Ситуацию спасла довольно новая программа под названием Deluge. Не сказать, что это какой-то очень многофункциональный или наоборот минималистичный клиент. Он так бы и остался серой серединкой, будь у него достойное количество конкурентов. Но никакой конкуренции в гномовской стране не обнаружилось. Из похожего я заприметил только Freeloader, но стабильность его работы оставляет желать много лучшего.
Количество функций Deluge, впрочем, всё же потихоньку прирастает. В основном за счёт плагинов: есть плагины для создания файлов .torrent, для подписки на rss, для задания приоритетов конкретных файлов в потоке и ещё для множества всяческих вещей.
Сборку Deluge для Ubuntu Feisty можно найти на getdeb.net.
От редакции. Вы только что прочитали постинг в блоге "Компьютерры-Онлайн". Между постингами в блоге и статьями есть существенная разница. Подробнее о ней рассказано в блоке "Инструкция по эксплуатации" в левой колонке.
Мови програмування самі не з'являються їх створюють люди але цих людей майже ніхто не знає. Ось фото творців минулого, сьогоднення і майбутньго.
Фото творців мов програмування.
Впевнений що кожний шукав музику в інтернеті, і напевно надзвичайно засмучувався коли вимагали заплатити.
Рятують торренти, домові компьютерні мережі з Dc++, але є ще один цікавий спосіб бескоштовного скачування, пошук в Google.com. Для цього потрібно задати в пошуку таку конструкцію:
-inurl:htm -inurl:html intitle:"index of" mp3 "пошукова фраза"
ось приклад
Оригінальна стаття
Нарешті в мене руки дійшли встановити на свою Fedora драйвери для відео картки. А починалося все з того що я вирішив змінити Fedora Core 6 на Fedora 7.
Спочатку я спробував встановити драйвер з репозитарію rpm.livna.org. Мої спроби встановити драйвер виглядали так:
спочатку я підключив беспосередньо сам репозитарій Livna:
rpm -Uhv http://rpm.livna.org/livna-release-6.rpm
тепер перевіряєм чи є в цьому репозитарії те що нам треба:
yum info kmod-nvidia
оскільки відповідь послідувала що такий пакет існує в репозитарії то я виріши його встановіти.
yum install kmod-nvidia
Попутно пакет kmod-nvidia ще якийсь пакет точно вже не пам'ятаю. Після того як ці два пакета встановились я перезавантажую Хwindow шляхом натискання Ctrl+Alt+Backspace. Пылся перезавантаження я перевіряю запряцював драйвер чи ні
glxinfo | grep direct
і результат повинен був бути такий
direct rendering: Yes
але я отримав:
direct rendering: No
що означає що драйвера не стали.
Щоб впевнитись що спарвді все так погано я вирішив перезвантажити робощу станцію.
Під час перезавантаження я побачив чому rendering не включився. Виявилось, що ці дрова взагалі не стали вилітали помилки якраз на цей драйвер.
Пілся деяких митарств по інету в чому мені допоміг Google (без нього взагалі ніяк) я зрозумів що драйвер який мені встановив rpm.livna.org занадто новий, оскільки в мене відео карта GeForce2 MX400 яка вже напевно раритет:). Діватись небуло куди я поліз на сайт Nvidia і почав там шукати необхідний драйвер. В dmaseg я знайшов на що відругалась система вона конкретно говорила що шановний пане ваша відео карта підтримує тількі драйваре з серії 96.хх, а в мене rpm.livna.org встановила 100.хх. Тому я прийняв рішення про деінсталяцію занадто нового драйвера і встановленню більш старшого. Але тут виявилась невеличка проблема, kmod-nvidia нехотів видалятись він залежив від того пакета який kmod-nvidia поятгнув за собою, а відповідно той пакет не хотів видалятись тому що залежив від kmod-nvidia, я есь мучався хвилин 20-30. Рішення просто було просте і в одночас геніальне за допомогою команди:
rpm -e xorg-x11-drv-nvidia-100.14.19-2.lvn7 kmod-nvidia-100.14.19-1.2.6.22.9_91.fc7
Система сама якось з ними домовляется івидаляє ці пакети.
Але щастя ще не настало коли я спробував встановити драйвера скачені з офіційного сайту Nvidia знову почала ругатись. Логи драйверів я знайшов ось тут:
/var/log/nvidia-installer.log
в логах драйвер мені говорив що потрібно встановити кампілятор!!! Я був у шоці, але я згада таку особливість проекту Fedora. Під час інсталяції операційної системи інсталятор запитує як ви будете користуваться компьютером і дається три варіанти:
1. Сервер
2. Компьютер для розробки програмного забезпечення
3. Робоча станція
так ось я вибрав "Робочу станцію". А це означає що не ставиться копилятор, жодного серверно програмного забезпеченя, дивна особливість, хоча це експерементальна платформа для комерційної Red Het interprize, тому можливо це і є нормальна ситуація:)
За допомогою команди:
yum install gcc
Я встановив компілятор і виріши що я зараз отримаю бажаний результат. Але була ще одна перешкода.
Справа в тому що драйвера nvidia щось там копилюють здається модуль до ядра. Так ось у мене небуло ісходного коду ядра системи навіщо на звичайній робочій станії компілятор, так напевно думали проєктанти Fedora, тому потрібно теж встановити код ядра, а робиться це так:
yum install kernel-devel
так було встановлено що необхідно для поного щастя драйверів. І я нарешті зміг запустити цей триклятий драйвер, для його встановлення треба було перейти на третій рівень режимузагрузки де X server не працює, це робиться командою
init 3
а повернутись до 5 рівня де Х сервер процює робиться відповідно за допомогою
init 5
sh *.run --x-module-path=/usr/lib/xorg/modules
Для того щоб ці драйвера запустились необхідно було змінити один параметр в файлі:
/etc/x11/xorg.conf
Саме в цій секції треба було "nv" замінити на "nvidia"
Section "Device"
Identifier "Videocard0"
Driver "nvidia"
EndSection
Але драйвер це сам зробив, він навіть в мене запитав чи він може сам змінити чи можливо я цьго сам захочу копирсатись я далі не хотів тому я йому дозволив.
Я все понимаю и не понимаю одновременно. Я понимаю, что сисадмин всего лишь обслуживающий персонал, но я не понимаю, почему труд уборщиц ценится выше, чем сисадминский, хотя потери от захватанных пальцами ручек в туалете неизмеримо ниже, чем уничтоженный за день до сдачи годовой баланс.
Я понимаю что бываю резок и даже груб (скорее изредка бываю вежлив и приветлив), но не понимаю почему юзер не может выучить десяток операций, необходимых для ЕГО, ЮЗЕРА, работы. Я понимаю что мой внешний вид не позволяет мне попадаться на глаза руководству, но не понимаю как можно сменить блок питания в костюме и галстуке, не изгваздавшись по уши в пыли и окружающем системный блок мусоре.
Я понимаю что бюджет организации - штука сложная и разноплановая, но не понимаю почему должен выпрашивать деньги на кулер месяцами, молясь чтоб не сдох настольный вентилятор, купленный на свои деньги и обдувающий всю стойку с аппаратурой.
Я понимаю, что интернет на 90% состоит из порносайтов и на 100% из этих сайтов есть вирусы, но не понимаю как юзеры, которые не в состоянии набрать свой пароль, умудряются обоходить фильтрующие прокси-сервера и игнорировать многоступенчатую антивирусную защиту.
Я понимаю, что должен обеспечить бесперебойную работу сети при любых обстоятельствах, включая прямое попадание в сервер метеорита, но не понимаю, когда в ответ на просьбу о приобретении ИБП мне отвечают, что “электросеть здания выдержит любые перепады, вызванные компьютерами”.
Я понимаю, что все, начиная от охранников и заканчивая членами совета директоров, будут таскать мне на ремонт и настройку свою электронику (включающую утюги и газонокосилки), но не понимаю почему меня ненавидят за отказ перевести системное время на 10 минут назад или дать возможность выкачать все фильмы в переводе всех гоблинов.
Я понимаю что мое здоровье - только моя проблема, а моя зарплата не позволяет мне заказывать еду на рабочее место, но не понимаю почему должен корпеть над выполнением очередной прихоти начальства ночью, ведь днем перезагрука сервера приводит к тотальному параличу очередного deathmatch-a среди топ-менеджеров.
Я понимаю, что моей жене неинтересно слушать о проблемах совместимости человека и компьютера, но не понимаю, почему мне не платят отпускные за четыре неиспользованных отпуска.
Я понимаю, что хороший сисадмин должен уметь очень много, но не понимаю почему должен выполнять работу отделов рекламы и дизайна, следить за состоянием электросети, противопожарной сигнализации, телефонных линий и систем видеонаблюдения.
Я понимаю зачем компьютер мне, но не понимаю зачем он юзерам, которые только и делают что вводят тексты и тут же их распечатывают, при этом жалуясь на низкую производительность видеокарты.
Я хочу хотя бы на пару часов отключить свой мобильник, хотя бы ночью, но не хочу, чтобы в это время обрывали телефоны всех моих родственников и друзей.
Я верю, что мой труд все таки оценят, но не верю в то что цена будет достаточной и счета будут оплачены.
Я знаю, что моя работа нужна, но теперь уже не знаю - нужна ли мне такая работа...
Сергей Кононенко
Предисловие
В последнее время Linux все активнее завоевывает рынок desktop-систем, идя в этой области далеко впереди остальных Unix-ов. Все больше программистов пишут приложения, ориентированные на конечного пользователя. Многие фирмы всерьез рассматривают desktop-linux как выгодный коммерческий продукт.
Linux уже неплохо обосновался на рынке офис-систем и стал активно продвигаться на рынок домашних компьютеров. Вообще говоря, Linux и раньше чаще встречался дома, чем в офисе. Поэтому под активным продвижением, я имею в виду развитие мультимедийных программ и игр. Долгое время пользователям Linux приходилось довольствоваться маленькими freeware играми, которые за редкими исключениями, не соответствовали современному уровню (в основном, из-за качества графики и слабо продуманного сценария). Единственной "отрадой" были игры от id Software, которые не уступали версиям для других платформ. С появлением фирмы Loki Software ситуация резко изменилась. Loki уже успешно портировала под Linux некоторые "культовые" игры (например Heroes of Might and Magic III), и похоже, не собирается останавливаться на достигнутом. Возможно, успехи Loki заставят последовать ее примеру другие фирмы, возможно, версии под Linux будут делать сами разработчики. Конкуренция со стороны фирм заставит свободных программистов лучше прорабатывать свои игры. В любом случае, у игровой сферы под Linux-ом хорошие перспективы.
Но среди всех программ для desktop-систем, игры, похоже, наиболее требовательны к системным ресурсам. Поэтому, для реализации игры на конкретной платформе, нужно, чтобы там был мощный графический интерфейс: быстрый, удобный для программиста и позволяющий использовать все возможности железа. Не секрет, что именно появление DirectX способствовало переходу разработчиков игр с уже устаревшего DOS-a на Windows. Для Linux-а существует несколько графических систем, и в этой статье я хочу рассмотреть их возможности и недостатки с точки зрения игр и мультимедийных приложений.
X Window system
X Window является традиционной и основной графической системой для Linux-a и всего Unix-сообщества. Это мощная, профессиональная система, обладающая большим набором возможностей. Большинство пользователей Linux-а работают с системой XFree86, которая является бесплатной реализацией X11 Realise 6 и входит в состав всех известных дистрибутивов. Некоторые предпочитают коммерческие варианты: AcceleratedX и MetroX. Говорить о X Window можно очень долго, но сразу стоит отметить, что эта система создавалась не для desktop-компьютеров. X Window ориентирована на сеть и построена по клиент-серверной технологии. Прикладные программы с помощью библиотек системы по специальному протоколу обмениваются графической и управляющей информацией с X-сервером, который занимается отображением графики и работает с мышью и клавиатурой. Причем связь может осуществляться как через локальный сокет, так и через TCP/IP. То есть существует реальная возможность выполнять программу на одном компьютере, а отображать графику на другом. В свое время на меня большое впечатление произвел Netscape, запущенный подобным образом и работающий с весьма приличной скоростью. Похоже, что в области сетевых распределенных систем X Window до сих пор вне конкуренции.
Но в нашем случае, сетевые возможности X Window превращается в основной недостаток этой системы. Большинство игр и мультимедийных программ активно используют копирование в видеопамять (на это может уходить от 20 до 70 процентов времени, затрачиваемого на обработку одного кадра). Соответственно, эта операция должна быть оптимизирована по максимуму. Поэтому передачу данных через сокет (т.е. по сути двойное копирование) нельзя назвать хорошим решением в данном случае. Это одна из основных причин, по которым X Window в некоторых задачах отстает в скорости по сравнению с GDI Windows.
К счастью X Window не только мощная но и гибкая система (как и сам Linux), она позволяет с помощью расширений добавлять новые функции, не нарушая основных принципов системы. Поэтому появилось расширение, призванное решить описанную выше проблему.
XShm (MIT Shm)
XShm (X Shared Memory) - расширение X Window, позволяющее копировать изображения напрямую в видеопамять (в пределах окна программы). При этом графическая данные хранятся в общей памяти, c которой работает как прикладная программа, так и X сервер. Таким образом удается избежать двойного копирования, не затрагивая основных принципов X Window. Это расширение появилось достаточно давно, оно присутствует в большинстве реализаций X Window, и почти все программы, требующие быстрого отображения графики используют XShm.
XShm - эффективный метод, он дает возможность получить быстродействие, близкое к максимально возможному. Достаточно будет сказать, что Quake2 в софтварном режиме, на сервере с 8-битной глубиной цвета у меня показывает те же fps, что и версия под Windows с наиболее быстрым драйвером, который мне удалось достать для моей S3Trio64.
Чаще всего скорость при использовании XShm падает из-за несовпадения глубины цвета данных и глубины цвета, установленной в X-сервере. В этом случае какое-то время тратится на преобразование, которое, следует отметить, делается "прозрачно" и достаточно быстро. В остальных случаях все в порядке, о чем говорит приведенный выше пример.
XShm достаточно прост с точки зрения разработчика. Фактически в нем реализованы аналоги стандартных PutImage и GetImage, поэтому переделать программу под это расширение несложно. Сложнее работать с X Window без высокоуровневых библиотек, но это уже другой вопрос.
XShm всем хорош например для видеоплейеров, но во многих играх нужен полноэкранный режим, и здесь XShm уже не поможет. Эту проблему призвано решить другое расширение X Window.
DGA
DGA (Direct Graphics Access) является специфическим расширением XFree86, и насколько я знаю, в других системах X Window не существует, или существует в другом виде. DGA позволяет прикладным программам получать прямой доступ к видеопамяти (фреймбуферу) и работать в полноэкранном режиме. Также программа может перехватывать на себя все сообщения от клавиатуры и мыши. Таким образом, этот интерфейс в какой-то мере является аналогом DirectDraw для Windows.
Достоинства этого метода очевидны: он позволяет работать с железом почти на прямую и выжать максимальное быстродействие. Но, пожалуй, этим все и ограничивается.
DGA - хорошая идея, но реализация, к сожалению, имеет много недостатков. Во-первых, это невозможность изменения "на лету" глубины цвета видеорежима (хотя, это скорее недостаток X Window вообще). Во-вторых невозможность вернутся в обычный режим, если программа, работающая с DGA не предоставит такую возможность: переключение между виртуальными консолями в этом случае не работает, а никакого аналога Alt-Enter из Windows не существует. Мне часто после зависания StarCraft-а в Wine, использующего DGA, приходилось ``убивать'' X-сервер, и с помощью хитрых манипуляций вслепую с SysRq и restoretextmode восстанавливать нормальную работу консоли (причем не всегда успешно). В-третьих для использования DGA нужны права root-а, что иногда вызывает проблемы с безопасностью.
С точки зрения программиста DGA тоже далек от идеала. Во первых, это крайне бедный набор функций, по сути сводящихся к установке видеорежима и получению адреса фреймбуфера. В более поздних версиях (например, в XFree 3.3.6) появился интерфейс для функций 2d-ускорителя, реализованных в X Window. В некоторых случаях блиттер (перемещающий прямоугольники в пределах экрана) бывает очень полезен. К сожалению, заставить работать эти функции в DGA мне не удалось, хотя вообще они работают. Во вторых, проблема с отладкой программ, опять из-за невозможности переключать консоли или возвращаться в обычный режим.
К счастью, DGA не стоит на месте. В долгожданной XFree 4.0 появилось расширение DGA2, которое должно исправить недостатки первой версии и предоставить новые возможности. К сожалению, XFree 4.0 не работает с моей видеокартой, поэтому пока о DGA2 ничего сказать не могу.
А пока некоторые проблемы DGA может решить библиотека SDL, о которой пойдет речь ниже.
Svgalib
Второй по распространенности графической системой для Linux-а несомненно является Svgalib. Эта библиотека предоставляет программам интерфейс для консольной полноэкранной графики и никак не зависит от X Window. В отличие от последней, эта система разрабатывалась специально для игр и мультимедийных программ. Она возникла потому, что X Window не устраивала многих разработчиков игр из-за сложности и громоздкости (а также отсутствия в то время DGA). Нужна была маленькая компактная библиотека, которая предоставляла бы разработчикам среду, похожую на Dos-овскую.
Фактически Svgalib представляет собой набор драйверов для различных видеокарт, которые реализуют основные графические примитивы: Line, Rectangle, Circle, PutImage, работу с палитрами, видеопамятью и так далее. Кроме этого в библиотеке есть интерфейс для работы с клавиатурой, мышью и джойстиком. Svgalib работает в полноэкранном режиме, но позволяет переключать консоли. Кроме того, она почти работала в бэкграунде, т. е. программа не останавливалась, когда переключаешься на другую консоль. В последних версиях, к моему удивлению, эта почти работоспособная возможность была убрана.
Из достоинств Svgalib можно назвать уже упомянутый маленький размер и компактность, простоту, высокое быстродействие, полноэкранный режим и т.д. Казалось бы, это идеальное решение, созданное специально для разработчиков игр, но есть и недостатки, которые ограничивают применение этой системы.
Во первых, многие считают Svgalib нестабильной, потому что она не всегда восстанавливает текстовый режим в случае аварийного останова программы (для этого как раз и существует утилита restoretextmode), хотя в последнее время я с этой проблемой не сталкивался. Во-вторых, при работе с видеопамятью Svgalib по умолчанию использует режим с переключением банков, а не линейный доступ к фреймбуферу, что уменьшает производительность. Для примера сравните результаты, которые выдают программы speedtest и linearspeed из комплекта Svgalib. Это объясняется тем, что не все драйвера видеокарт поддерживают линейный фреймбуфер (для S3 мне пришлось писать эту поддержку самому). C 2d-ускорением ситуация еще хуже: есть неплохой интерфейс, но реализован он только в 2-3-х драйверах.
Другим недостатком является необходимость наличия root-овских прав для работы с Svgalib, так как она обращается напрямую к портам железа. Чтобы программы могли запускать обычные пользователи, на них необходимо ставить suid-флаг, что влечет за собой проблемы с безопасностью. За последнее время я не видел эксплоиты к Svgalib-ским программам, тем не менее большинство системных администраторов относятся с большим подозрением к этой библиотеке, потому что, чем меньше в системе программ с suid-флагами, тем спокойнее. Хотя пользователям домашних компьютеров это не важно.
И, наконец, независимость Svgalib от X Window далеко не всегда является достоинством. Эти системы могут конфликтовать при совместной работе, хотя я с этим не сталкивался. Некоторые видеокарты поддерживаются в X-ах, но не в Svgalib, и часто приходится тратить немало сил, чтобы перенести драйвер из одной системы в другую.
Для программистов Svgalib достаточно удобна, особенно для тех, кто писал программы под Dos на Borland C или Watcom С. Помимо стандартных низкоуровневых функций, в состав Svgalib входит библиотека vgagl, предоставляющая удобный абстрактный интерфейс более высокого уровня. Единственный недостаток - проблема с отладкой, так как переключение консолей в режиме трассировки не работает. Но, в отличие от DGA, можно обойтись без второго терминала, переключая консоль с помощью специальной функции в текстовый режим и обратно. Правда тогда прийдеться забыть о DDD и других графических оболочках для gdb.
Несмотря на достоинства и устранимость недостатков, будущее Svgalib туманно. "Серьезные разработчики" (фирмы) стараются не использовать эту "нестандартную" библиотеку, считая X Window единственно возможной графической системой. Поэтому коммерческие игры (кроме разве что id-шных) вряд ли будут использовать этот интерфейс. Но хорошего и полного аналога Svgalib тем не менее нет, поэтому свободные программисты вряд ли откажутся от этой библиотеки.
Не так давно от основной версии Svgalib отделилась нестабильная ветка 1.9.x, которая должна перерасти в 2.0.0. Там появилось много принципиальных изменений, но пока эта версия библиотеки неработоспособна (по крайней мере у меня), поэтому говорить о ней что-то определенное трудно. Надеюсь, в будущем Svgalib порадует нас приятными сюрпризами.
GGI
GGI (General Graphics Interface) - графическая система нового поколения, предоставляющая для прикладных программ абстрактный интерфейс, не зависящий от конкретного "железа" и особенностей операционной системы. GGI предназначена для решения того же класса задач, что и Svgalib, но на более современном и продвинутом уровне.
GGI построена по модульному принципу. Абстрактный уровень и графические примитивы реализуются самой библиотекой, а непосредственная отрисовка осуществляется с помощью загружаемых драйверов, которые используют либо низкоуровневые интерфейсы (framebuffer device), либо другие графические системы: X Window (с DGA и без), Svgalib и т.д. Кроме того, модули могут делать дополнительные функции: отображать виртуальный truecolor экран на реальном дисплее с 8-битной глубиной цвета и наооборот; выводить графику на удаленном сервере и т.д.
В проект GGI входят также библиотеки libgii (General Input Interface) для обработки сообщений от клавиатуры и мыши, libggi2d и libgg3d, которые реализуют интерфейс более высокого уровня для 2D и 3D графики соответственно. Но последние две библиотеки находятся пока в начальной стадии разработки, поэтому говорить о них всерьез пока рано. Все они также построены по модульному принципу.
Основные достоинства GGI - неплохое быстродействие, небольшой размер, модульный принцип, предоставляющий неограниченные возможности для расширения и реализации "экзотических" функций: например, можно сделать модуль, который делает стереокартинку, поддерживает систему виртуальной реальности и т.д. Абстрактный интерфейс позволят программе по собственной инициативе или по вашему желанию работать в окошке, на весь экран (через DGA), в консоли (через Svgalib или fbdev). Кроме это в GGI активно используется линейный фреймбуфер и 2d-ускорение графических примитивов (рисование линий, прямоугольников, пресловутый блиттер), если, конечно, это поддерживает низкоуровневый драйвер.
Основным недостатком можно назвать тот же абстрактный интерфейс, поскольку обычно GGI используется как "обертка" для других систем (X Window, Svgalib), что ведет к небольшой потере производительности. Также, за счет этого, GGI автоматически вбирает в себя недостатки используемых систем (хотя, в случае DGA, сглаживает их). Это не связано с GGI напрямую, так как по задумке он должен работать через низкоуровневый интерфейс KGI, который будет рассмотрен ниже.
Помимо всего, GGI еще достаточно "сырая": есть недостатки в интерфейсе, путаница с модулями и тому подобное.
GGI очень привлекательна для разработчиков, так как имеет элегантный и продуманный программный интерфейс, который, с одной стороны позволяет не заботится о низкоуровневых особенностях, с другой стороны эффективно использовать все возможности системы. Программы под GGI обещают быть легко переносимыми. Планируется реализация GGI не только под Linux и другие Unix-ы, но и под Windows, OS/2 и т.д. Довольно удобен процесс отладки, так как программу можно отлаживать в окне X Window, используя графическую оболочку для gdb, а рабочую версию запускать на весь экран через DGA или Svgalib.
В целом GGI выглядит многообещающе, но его будущее так же не определено. Особого интереса к интерфейсу со стороны разработчиков коммерческого софта не наблюдается. Во многих freeware играх поддержка GGI появилась лишь как дань моде. Я считаю, что все это связано с низкой активностью руководителей проекта, потому что разработка и продвижение GGI идет довольно вяло. GGI - это хорошая идея, и при желании всех заинтересованных сторон этот интерфейс может стать аналогом DirectX.
Интересно заметить, что все рассмотренные графические системы являются программами или библиотеками пользовательского уровня, хотя в desktop-системах (Windows и OS/2) поддержка графики находится в ядре. О том, какие графические возможности предоставляет ядро Linux-а, пойдет речь дальше.
Framebuffer device
В ядре Linux-а начиная с серии 2.1.* появилось устройство framebuffer device (/dev/fb*), которое предоставляет доступ к видеопамяти, позволяет управлять экраном и работать с консолью в графическом режиме. Таким образом, уже сейчас в ядре есть графический интерфейс. Интересно, что он получил широкое распространение на неинтеловских платформах. Появилось множество драйверов для видеосистем, используемых в этих архитектурах. Скорее всего, это объясняется тем, что на этих платформах существуют проблемы с реализацией X Window и Svgalib, поэтому фреймбуфер является единственным путем для использования графики.
На интеловской платформе фреймбуфер развивается достаточно вяло, драйверов для видеокарточек немного. Почти все польщователи ставят драйвер vesafb, который работает через VBE BIOS карточки. К сожалению, vesafb годится только для демонстрации симпатичного пингвина во время загрузки системы или работы с "большой" консолью, поскольку не позволяет менять видеорежимы после загрузки ядра.
Правда фреймбуфер (как и в случае неинтеловких платформ) может помочь тем, чья видеокарта не поддерживается XFree, и кто тем не менее хочет работать в SVGA-режимах. Существует сервер XF86_FBDev, который работает через фреймбуфер, но функции ускорения не поддерживает. Понятно, что этот метод родился не от хорошей жизни, поэтому назвать его оптимальным нельзя. По тем же самым причинам с фреймбуфером не может эффективно работать и GGI.
Существует много мнений о том, в какую сторону должен развиваться графический интерфейс в ядре Linux-а. Я расскажу о некоторых из них.
KGI
KGI (Kernel Graphics Interface) появился, как часть проекта GGI. Представляет собой расширение функций framebuffer devic-a, чтобы на уровне ядра поддерживать GGI. KGI позволяет использовать возможности 2D ускорителей, устанавливать параметры видеорежимов (как modeline в X Window), обращаться к Ramdac-у и ClockChip-у видеокарты, задавать (а может, и автоматически определять) параметры монитора. В KGI уже есть драйвера для многих распространенных видеокарточек, хотя далеко не всех. К сожалению, моя S3Trio64 не поддерживается, а попытки переделать драйвер от родственной карточки пока не увенчались успехом. Поэтому протестировать все возможности KGI мне не удалось, хотя vga-драйвер, которым я пользовался, вполне работоспособен и производит хорошее впечатление.
В целом, KGI выглядит неплохой идеей, поскольку позволяет GGI показать себя во всей красе. Тем не менее будущее KGI под вопросом. Например, пока что не предвидется официальное включение этого интерфейса в ядро, и тому есть немало причин.
Уже давно среди разработчиков Linux-а ведутся споры о том, нужна поддержка графики на уровне ядра, или нет. Аргументы "За" выглядят следующим образом. Во-первых, "идеологически правильно", когда все обращения к портам устройств производятся из области ядра, а не прикладных программ (как в случае X Window и Svgalib). Отпала бы необходимость в suid-флагах, и таким образом решились бы проблемы безопасности. Не возникали бы конфликты между разными системами, которые одновременно и напрямую обращаются к видеокарте (опять X Window и Svgalib). И наконец наличие единого интерфейса избавило бы от "лишней" работы по написанию низкоуровневых драйверов для различных систем. И наконец, поддержка на уровне ядра может дать некоторый выигрыш в производительности.
Тем не менее, есть и аргументы "Против". Чаще всего ссылаются на то, что ядро и так сильно распухло, поэтому включение большого числа драйверов различных видеокарт нежелательно. Во вторых, в случае "внутриядерного" интерфейса, глюки на уровне железа, которые не редко встречаются во многих видеокарточках, могут привести к остановке ядра. А это не вяжется с концепцией стабильности Linux-а. В третьих, возникнут большие трудности (как технические, так и организационные) при переносе драйверов из X Window в ядро, так как XFree ориентируется не только на Linux сообщество. Если же X-ы оставить в покое, тогда идея интерфейса в ядре потеряет смысл.
Однако, я считаю, что развитию KGI мешают не эти причины, а опять таки недостаточная настойчивость и организованность руководителей проекта GGI. Появление фреймбуфера, похоже решило вопрос, быть или не быть графическому интерфейсу в ядре, а изменения, вносимые KGI, не нарушают принципа этой архитектуры.
А пока вопрос о KGI остается открытым, в нестабильной ветке ядра 2.3.* появился интерфейс, имеющий прямое отношение к графическим системам.
DRM
DRM (Direct Rendering Manager) создан, как поддержка внутри ядра интерфейса DRI (Direct Rendering Infrastructure), который был включен в XFree 4.0. DRM не является полноценным графическим интерфейсам, скорее всего, он призван взять на себя функции XFree, наиболее требовательные к производительности, и которые эффективней выполнять на уровне ядра: синхронизация обмена данными с видеокартой, DMA, использования ускорителя и т.п. Пока что в состав DRM входят драйвера только для двух карточек: 3dfx Banshee/Voodoo3 и 3dlabs GMX 2000. Если DRM покажет хорошие результаты в связке с XFree, то поддержка других карт, скорей всего, не заставит себя ждать. Многие фирмы - производители видеокарточек заинтересовались DRM. Но пока сказать о DRI что-либо определенное довольно трудно.
SDL
SDL (Simple DirectMedia Layer). Я не зря пишу о SDL в самом конце. Во-первых, эту библиотеку я увидел, когда большая часть статьи уже была написана, во-вторых SDL это больше чем графическая система. В README написано, что SDL - интерфейс, предоставляющий низкоуровневый доступ к видеопамяти, звуковой карте, клавиатуре и мыши. На самом деле это многофункциональная библиотека для разработчиков игр и мультимедиа программ. Помимо стандартных возможностей в SDL реализованы функции, часто использующиеся в играх: библиотека позволяет загружать графические и звуковые файлы (пока только BMP и WAV), работать с CD-ROM-ом, считать временные задержки. Во многом SDL похожа на GGI, она тоже работает как оболочка для других графических систем: сейчас графика может отображаться в окне X Window (XShm) или на весь экран, используя DGA. Есть возможность работы с framebuffer device (c определенными видеокартами). Должна появится поддержка OpenGL, Svgalib и GGI (интересно представить программу, работ
ающую по цепочке SDL --> GGI --> X Window).
У SDL много достоинств: небольшой размер, компактность (в отличие от GGI библиотека состоит из одного файла и может линковаться статически), неплохое быстродействие. Для ускорения графических операций задействована мини-библиотека Hermes, использующая MMX. Но, главное, SDL умеет "на лету" переходить из оконного режима в полноэкранный, устраняя тем самым основной недостаток DGA. Для этого раньше служила знакомая по Windows комбинация Alt-Enter, но в последних версиях эту возможность убрали, переложив ответственность за переключение на прикладную программу, что по-моему, возвращает все к ситуации с DGA.
Недостатков не так много, но они есть. SDL в X Window не использует аппаратное 2d-ускорение, отсутствие которого сказывается на некоторых играх. Как оболочка, SDL наследует недостатки низкоуровневых графических систем.
Для программиста SDL выглядит очень привлекательно. Простой и удобный интерфейс предоставляет "в одном флаконе" почти все функции, необходимые разработчику игр. Единственно, настораживает малое число поддерживаемых форматов данных (я, например, не хочу хранить графику в BMP), но надеюсь, что это дело поправимое. Удобно отлаживать программы, используя, как и в случае GGI, оконный режим. SDL позволяет нормально работать c DGA. Библиотека поддерживает threads, что дает преимущество на многопроцессорных платформах и зачастую просто удобно для программиста. И, наконец, SDL многоплатформенная библиотека, уже сейчас есть реализации под Windows, BeOS и Solaris, скоро будут под FreeBSD и MacOS. Так что портировать игры будет довольно легко.
Очевидно, что у SDL радужные перспективы на будущее. Похоже, это основной претендент на место аналога DirectX для Linux-а. Единственный конкурент GGI немного отстал. К тому же SDL пользуется любовью коммерческих разработчиков: достаточно сказать, что Loki Software для портирования игр использует именно эту библиотеку (по крайней мере, в Heroes3). Не меньше популярность SDL и среди свободных программистов. Так что у нее есть все шансы победить конкурентов.
3D-графика
Я не буду писать о 3d-интерфейсах, потому что, во-первых, это тема для отдельной статьи, даже большей, чем эта; во-вторых, у меня нет 3d-ускорителя, а пересказывать чужие мнения по этому поводу мне не хочется. Хочу лишь сказать, что в этой области реальной альтернативы OpenGL нет. Уже есть бесплатная библиотека Mesa3D, реализующая этот интерфейс на 3dfx-чипах. Сейчас поддержкой OpenGL в Linux-е занимается SGI и NVidia, уже появились реализации для других 3d-ускорителей. Так что, в этой области Linux-у, скорей всего, не грозит отставание от других платформ.
Заключение
Несмотря на успехи SDL, она вряд ли в ближайшее время станет единым стандартом. Некоторым хватает расширения XShm, некоторые привыкли к Svgalib, многие отдали свое предпочтение GGI. По-моему, это даже неплохо. Я люблю Linux в основном за гибкость и свободу выбора. Для большинства программ можно найти аналоги. Я могу выбрать реализацию X Window или оконный менеджер. Могу выбирать между GTK и Qt, KDE и GNOME. Я считаю это большим преимуществом. Конечно, приходится держать большое число библиотек, делающих по сути одно и тоже. Но рассмотренные графические библиотеки не сильно большие, и врядли существенно повлияют на экономию дискового пространства. Главное, чтобы графические системы не конфликтовали между собой, чтобы конкуренция служила стимулом совершенствования, а не поводом для флейма. Сейчас есть все возможности для написания качественных игр, разработчик может выбрать интерфейс по своим потребностям, не забывая, конечно, о наличии у пользователя необходимой библиотеки.
Оригинальная статься http://www.sdteam.com/?tid=1409
Для входа в некое подобие BIOS-а нужно набрать такую комбинацию клавишь "#."
1.Команда help
2.showsc
3.shownet
4.setc if_network true
5.set netsc_ipaddr IP
6.resetsc
7.console
Большинство новичков обеспокоены один вопросом: "Как я буду зарабатывать с помощью собственного сайта? Как? За что буду получать деньги?" При этом их не волнуют вопросы: "Какая информация будет размещена на сайте? Как она будет представлена на нем? Будет ли она интересна посетителям проекта?"
Новичков волнует вопрос получения прибыли. Происходит ситуация, когда лошадь ставят позади телеги и пытаются двигаться вперед. Бывает и такое в нашей жизни. Жизнь - игра, а мы - актеры! Предположим, что Вы все таки имеете собственный тематический центр с качественным содержанием. Теперь перед Вами стоит действительно важный вопрос: "Как получить прибыль с помощью собственного сайта? Как?"
Рассмотрим основные способы получения прибыли с помощью собственного сайта.
СПОСОБ #1. Продажа собственного продукта.
В большинстве случаев, любой проект в Интернете создается для того, чтобы собрать вокруг себя целевую аудиторию с целью продажи ей какого-либо продукта или же оказания услуги.
Продаваемый продукт со страниц коммерческого проекта может быть как физическим, так и электронным.
Предположим, что Вы имеете собственный сайт посвященный холодильникам. На нем Вы разместили информацию о производителях холодильников, их конструктивные особенности, указали ценной диапазон распространенных моделей, разместили информацию о технологиях размораживания и заморозки продуктов и т.д. и т.п.
Предоставляя качественную информацию по данной теме, Вы можете рекомендовать посетителю сайта приобрести какую-либо модель холодильника для квартиры, дачи, офиса. Таким образом, предоставляя ценный контент, Вы продаете собственный продукт. В данной случае холодильник.
Рассмотрим другой случай. Вы увлекаетесь кошками. Это ваше хобби и Вы не можете жить ни дня без этих пушистых и симпатичных домашних любимцев. Вы создаете тематический центр на эту тему. Размещаете фотографии своих питомцев, публикуете интересные истории о них, информацию по их содержанию и уходу. Имея собственный качественный тематический центр по данной тематике, Вы можете продавать собственный продукт, например, электронную книгу "Как ухаживать за котенком, чтобы он вырос сильным и здоровым! Практическое руководство к действию!"
Как уже говорилось выше, кроме продажи собственных продуктов, можно со страниц коммерческого продукта продавать какие-либо услуги. Например, юрист, разместив на собственном сайте информацию по теме собственной специализации (уголовное право, гражданское право, бракоразводные процессы и т.д.), может предлагать свои услуги в качестве адвоката.
СПОСОБ #2. Продажа партнерских продуктов.
Имея собственный тематический центр, владелец проекта может участвовать в продвижении через его страницы продуктов других предпринимателей в рамках их партнерской программы. При этом он будет получать прибыль с каждой продажи рекламируемого им продукта, совершенной по его ссылке.
Например, тематический сайт посвященный холодильникам может продавать различные средства по уходу за холодильником и за предотвращению неприятных запахов в нем, различную специальную кухонную посуду и другие аксессуары, которые могут пригодится каждой хозяйке на кухне. Сайт посвященный кошкам, может продвигать в рамках партнерской программы продажу корма для кошек, различные аксессуары, ремешки, средства гигиены и лекарства.
СПОСОБ #3. Продажа рекламного места.
Имея раскрученный проект в Интернете можно получать прибыль, продавая рекламное место другим интернет-предпринимателям для рекламирования их продуктов и услуг. Рекламное место можно продавать под размещение рекламных баннеров, текстовых блоков, тематических рекламных статей и т.д. и т.п.
Например, сайт посвященный холодильникам может размещать статьи со скрытой рекламой, в которых описываются достоинства какого-либо холодильника, указываются его преимущества перед другими моделями и т.д. Сайт посвященный кошкам может размещать баннеры, рекламирующие различные аксессуары или же познавательные статьи о лечении различных заболеваний у домашних любимцев с указанием ссылок на ветеринарную клинику.
СПОСОБ #4. Продажа ссылок с главной страницы сайта.
Если Ваш сайт является раскрученным ресурсом в Интернете, Вы можете размещать на главной странице собственного проекта ссылки на другие ресурсы за определенную плату в месяц. Вы получаете деньги, а сайт, который оплатил за размещение ссылки, прямую ссылку на свой ресурс. Выгодно всем! Вам и тому, кто платит деньги!
СПОСОБ #5. Продажа контекстной рекламы.
Имея раскрученный тематический центр в Интернете, можно вступить в одну из рекламных сетей, установить их специальный код на собственном сайте и начать показывать контекстную рекламу. Если посетитель Вашего сайта кликнет по ссылке, размещенной в данном рекламном блоке, Вы заработаете определенную сумму денег, которая будет зачислена на Ваш счет в этой рекламной сети.
На данный момент в Рунете существует три рекламные сети:
1. Рекламная сеть поисковой системы http://yandex.ru - Яндекс.Директ http://direct.yandex.ru/ .
2. Рекламная сеть поисковой системы http://google.com - Adwords Google https://adwords.google.com/ .
3. Рекламная сеть компании "Бегун" http://begun.ru/ .
Мой проект http://bizzon.info "Достоверная информация о бизнесе в реальной жизни и Интернет" зарегистрирован в рекламной сети поисковой сети http://yandex.ru - Яндекс.Директ http://direct.yandex.ru/ . Текстовые рекламные блоки этой рекламной сети показываются на каждой странице проекта http://bizzon.info в левой колонке сайта сразу же под узлом навигации.
Безусловно, в этой статье невозможно описать все способы получения прибыли с помощью собственного сайта. Мной описаны только самые основные, но если Вы предпримете усилия по их реализации - Вы будете получать стабильную и постоянно увеличивающую прибыль. Это факт! И никогда не забывайте о размещении качественного контента на страницах собственного ресурса.
Обсудить эту тему можно на форуме http://bizzon-board.com "Точка опоры Вашего бизнеса в Интернет!" по этой ссылке http://www.bizzon-board.com/forum/viewtopic.php?t=2603
---------
Александр Доценко - руководитель проекта Bizzon.Info: Достоверная информация о бизнесе в реальной жизни и Интернет http://bizzon.info , автор многочисленных публикаций в области электронного бизнеса, в том числе статей, электронных книг и онлайновых курсов обучения.
Перевод статьи Дейкстры "Two views of programming" (EWD540)
Статья 1975 года
В окружающем нас мире мы можем встретить два радикально противоположных взгляда на программирование:
Взгляд А: Программирование в основном весьма просто.
Взгляд В: Программирование – это очень сложно.
Это противоречие можно объяснить тем, что в этих двух взглядах одно и то же слово «программирование» употребляется в двух совершенно различных значениях, и на этом успокоиться. Тем не менее то, какой из взглядов преобладает, А или В, оказывает глубокое влияние не только на кадровую политику организаций, использующих компьютеры, и учебные программы высших учебных заведений, но даже и на направление развития и исследований в самой компьютерной науке. Таким образом, представляется важным исследовать природу различий между этими двумя смыслами и по возможности выявить базовые предположения, которые делают каждый их них применимым. В этом и есть назначение данного документа.
В этом исследовании у меня есть одно препятствие: в этой дискуссии я не являюсь нейтральной стороной. Я – убежденный сторонник взгляда В и рассматриваю взгляд А как основную причину многих печальных заблуждений. С другой стороны, я не считаю, что наличие собственного мнения дисквалифицирует меня как автора, особенно если я заранее предупрежу об этом своих читателей и не буду притворяться нейтральным. В процессе анализа мы раскроем, как эти различные взгляды на программирование (которое является человеческой деятельностью!) связаны с различными мнениями Человека. Это уже само по себе является весьма ценным пониманием, так как объясняет почти религиозное рвение, с которым разворачиваются сражения между сторонниками противоположных взглядов (догм?).
Ранняя история автоматических вычислений делает взгляд А очень понятным. До того, как у нас появились компьютеры, программирование вообще не являлось проблемой. Затем появились первые машины: по сравнению с нашими нынешними машинами они были просто игрушками, и по сравнению с тем, что мы пытаемся делать сейчас, они использовались лишь для «микро-приложений». Если на этом этапе программирование и было проблемой, то весьма незначительной. Добавьте к этому источники трудностей, которые в то время поглощали – или лучше сказать узурпировали? – большую часть нашего внимания:
1. Арифметические устройства были слишком медленные по отношению к тому, что мы хотели делать с их помощью: эти башмаки почти всегда оказывались слишком тесными, и ради эффективности программы допускались все возможные трюки кодирования (и очень немногие из них реально не использовались).
2. Разработка и конструирование арифметических устройств были настолько новой и, следовательно, трудной задачей, что, если очередная аномалия в коде инструкции могла избавить от каких-либо кульбитов, от них обычно избавлялись, – также, разумеется, потому что мы имели так мало опыта в программировании, что мы не могли так уж хорошо распознавать «аномалии в программном коде»; в результате, помимо необходимости использования трюков в коде, также была великолепная возможность их применять.
3. Памяти всегда было слишком мало, и это вместе с ненадежностью первого оборудования препятствовало более разумному использованию машин.
В это время программирование представлялось в первую очередь как битва с ограничениями машины, битва, которую нужно было выиграть хитростью. Это было систематическое использование специфических особенностей каждой машины: это был расцвет виртуозного кодирования.
В течение следующих десяти-пятнадцати лет процессоры стали в тысячи раз быстрее, памяти стало в тысячи раз больше, и языки программирования высокого уровня вошли в обиход. И именно в это время с одной стороны программирование все еще прочно ассоциировалось с тесными башмаками, в то время как с другой – чувствовалось, что башмаки жмут все меньше и меньше, и ожидалось, что еще через пять лет технического прогресса проблемы программирования вовсе исчезнут. Именно в этот период появился взгляд А. Именно в конце этого периода, вдохновленный взглядом А, был разработан COBOL с провозглашенным намерением, что он должен сделать программирование, выполняемое профессиональными программистами, ненужным, позволив «пользователю» (не в это ли время слово «пользователь» стало общеупотребимым?) записывать то, что он хочет, на «простом английском», который любой может прочесть и понять.
Все мы знаем, что эта прекрасная мечта не воплотилась в жизнь. Следующие пять лет принесли нам вместо исчезновения всех проблем, связанных с программированием, кризис программного обеспечения, и COBOL, вместо того чтобы выжить профессиональных программистов, стал грандиозным механизмом программирования для еще большего их числа; и еще десять лет спустя мы все еще имеем машины, в которых ошибки базового программного обеспечения вызывают в среднем час простоя на каждые пятнадцать часов работы. Очевидно, что до сих пор остались серьезные проблемы программирования…
Забавная вещь: несмотря на полную очевидность обратного, взгляд А все еще жив. В объяснение этого странного факта некоторые с укоризной указывают пальцем на большие организации: либо на организации, применяющие компьютеры, которые, привлекая большие трудовые ресурсы, разделяющие взгляд А, тем самым потеряли возможность свободно расстаться с ним, либо на фирмы-производители компьютеров и образовательные институты, которые поддерживают широко распространенный взгляд А, который им полагается представлять как основной для их рынка. Даже если этот палец грозит поделом, тем не менее я не могу принять это как полное объяснение живучести взгляда А, и вынужден предположить, что взгляд А удовлетворяет более глубокие, физиологические потребности.
Откуда взялся взгляд В? Были люди, которые чувствовали, что появление больших и быстрых машин заменит тесные башмаки хотя бы на башмаки по размеру, и что несмотря на это эффективность выполнения программ останется серьезной заботой программиста, заботой, которая станет даже более важной по мере роста машин и приложений, и что более сложные установки поставят более трудные проблемы. Также было замечено, что переключение с машинного кода на языки высокого уровня вовсе не гарантирует тех преимуществ, на которые возлагали столько надежд. В частности, программисты продолжали столь же охотно выдавать большие куски непонятного кода, и единственное различие было в том, что теперь они делали это в более грандиозных масштабах, и что высокоуровневые ошибки пришли на смену низкоуровневым. Они также поняли, что появление языков программирования высокого уровня не уменьшает потребности в тщательности: избыточность языков высокого уровня лишь уменьшает вредный эффект от некоторых видов небрежности. И тогда появился взгляд В. (Взгляд В не является реакцией на кризис программного обеспечения, который всплыл в 1968, так как он на много лет старше. Фактически взгляд В предсказал этот кризис, но даже это подтверждение не убило взгляд А).
После этой интерлюдии по поводу появления взгляда В вернемся к нашему вопросу: как и почему, лицом к лицу с признанными проблемами программного обеспечения, взгляд А (а именно – программирование в основном весьма просто) все еще здравствует. Вот ответ: из-за веры, причем не веры в лучших программистов, а веры в лучшие языки программирования или (диалоговые?) системы программирования, а также веры в лучшие технологии программного менеджмента.
Я придерживаюсь мнения, что программирование – один из наиболее сложных разделов прикладной математики, поскольку оно также является одним из наиболее сложных направлений инженерии, и наоборот. Когда я попытался разъяснить одному из моих коллег-математиков, почему я придерживаюсь этого мнения, он довольно бесцеремонно отказался выслушать мои доводы и вместо этого обвинил меня и моих единомышленников-компьютерщиков в том, что мы до сих пор не создали язык программирования, который сделал бы программирование настолько простым, насколько ему и подобает быть! Возможно, мне стоило бы спросить его, почему математики до сих пор не разработали нотацию, которая позволила бы любому, невзирая на отсутствие профессиональной подготовки, заниматься математикой?
Копнув чуть глубже, выясняется, что сторонники взгляда А не отрицают потенциальной сложности программ и их разработки, но верят, что жизнь программистов будет становиться все легче, поскольку все наиболее сложные части задачи будет брать на себя машина. Они указывают на появление языков программирования высокого уровня, которые уже сделали программирование гораздо легче, чем во времена старых машин, и опрометчиво экстраполируют, что в будущем программирование станет вовсе тривиальным. Но оправдана ли эта экстраполяция? Я много программировал, как в машинных кодах, так и на языках высокого уровня, и последние несомненно более удобны, поскольку в этом случае многие решения, относящиеся к внутренним деталям программы, такие, как распределение памяти, не приходится принимать явно, поскольку ими занимается алгоритм распределения памяти компилятора. Переход к языкам высокого уровня освобождает нас от многих тривиальных забот. Это сделало программирование деятельностью с небольшим количеством нудной работы, с преобладанием изобретательности: именно та часть работы, которая занимала целые дни, исчезла! Вывод, который следует из появления языков программирования высокого уровня, о потребности в программистах большего интеллектуального калибра, полностью подтвердился моими наблюдениями в Западной Европе (где я мог следить за разработками последнее время): в конце 60-х многие крупные организации, использующие компьютеры, испытывали проблемы в подборе подходящей работы для программистов, нанятых 50-е годы, поскольку профессия переросла их интеллектуальные способности.
Однако ни эти наблюдения, ни указания на провал попытки COBOL'а выжить профессиональных программистов не произвели никакого впечатления на правоверных. Они объяснят, что традиционные языки программирования высокого уровня потерпели крах из-за их «процедурности», и что провал COBOL'а очевиден, поскольку ввиду недостаточной интерактивности он на самом деле не является простым английским, но вот через пять или десять лет дальнейший прогресс в области Искусственного Интеллекта (для посвященных – AI, т.е. Artificial Intellect) позволит нам построить «контекстно-зависимые», «основанные на знаниях», «автоматизированные системы для мышления и понимания», такие, что «пользователю достаточно будет только побеседовать с ними».
Должно быть, я неизлечимый скептик, но мне весьма трудно поверить, что подобным надеждам суждено сбыться. Имеются некоторые видимые подтверждения таких ожиданий – я цитирую отрывок из недавно полученного письма: «…в общем, передача более совершенному компьютеру того, что мы сегодня называем человеческими навыками, знанием и разумом». Я не намерен повторять здесь фрагменты горячих дискуссий, которые мы проводили по поводу значимости Искусственного Интеллекта, да здесь это и ни к чему.
Во-первых, оглядываясь назад, приходим к неизбежному заключению: смешивание надежды на будущее AI с завтрашней реальностью было бы безрассудством, и весьма безответственно быть неподготовленными на случай, если мечты по поводу AI останутся мечтами по крайней мере на протяжение нашей жизни. Или, говоря другими словами, глядя на серьезность сегодняшних проблем программирования, обычная осторожность заставляет нас не забывать о взгляде В.
Во-вторых, первоочередной задачей программиста, если он хочет, чтобы его творения заслуживали доверия, будет разрабатывать их настолько понятными, что он сможет нести за них ответственность, и, несмотря на ответ на вопрос, как много из его нынешней деятельности может быть переложено на машину, мы должны всегда помнить, что ни «понимание», ни «ответственность» не могут быть классифицированы как деятельность: это скорее «состояние разума» и в принципе не может быть передано машине.
Я считаю неразумным, в особенности для ученого-компьютерщика, недооценивать влияние психологической школы, которая, считая человеческий разум слишком сложным и трудно поддающимся изучению, занялись вместо этого изучением крыс, и даже ограничивает это изучение – как я слышал недавнюю формулировку – «наиболее механической формой поведения – зачастую настолько механической, что даже крысам не дают проявить свои высшие возможности». Представляя свои грубые, механические модели в качестве допустимого приближения к человеческому разуму, они опасно затуманили различие между человеком и машиной, и мы наблюдаем два взаимно дополняющих друг друга феномена: антропоморфный взгляд на машины и механический взгляд на людей.
Эта неразбериха, вне всякого сомнения, – плод усилий верховных жрецов AI. Преобладание в основном антропоморфной терминологии в компьютерной науке – «память», «интерпретатор», «язык программирования», «рукопожатие», «диалог», и это лишь немногие примеры, – это предупреждение, которое не следует игнорировать. Я не знаю, как думать и разговаривать, обходясь без метафор; я знаю также, что каждая метафора несет в себе опасность скрытого подтекста. В данном случае антропоморфной терминологии в компьютерной науке мы давно уже достигли стадии, когда опасность путаницы перевешивает достоинства аналогии.
Кроме того, кажется, что механический подход к людям среди компьютерных ученых (и их руководителей) распространен шире, чем представляется мне нормальным. Ибо я подозреваю, что именно этот механический подход ограничивает деятельность программистов механическими действиями по написанию кода, и затем измеряет «производительность труда программиста» количеством произведенных им строк кода. (Когда весьма широко известный и очень уважаемый ученый-компьютерщик использовал недавно эту меру производительности труда программиста в своей лекции, от слушателей поступило предложение говорить не о «количестве произведенных строк кода», а о «количестве израсходованных строк кода», и что лектор, следовательно, занес их не в ту графу учета баланса расходов и доходов. Лектор ответил, что он вынужден использовать эту меру производительности, поскольку не располагает никакой альтернативной, которая позволяет вести точный учет!) Это не может больше рассматриваться как безобидное заблуждение, поскольку принятие этой бессмысленной «меры производительности» профессиональными программистами гарантированно стимулирует их к написанию рыхлого кода.
Влияние психологии было рассмотрено здесь, поскольку оно объясняет цепкость, с которой так много людей склонны тяготеть ко взгляду А.
В основном это не вина производителей компьютеров, которые желают вести дела так, будто они продают простейшую продукцию; и не вина руководителей программных проектов, которые предпочитают рассматривать деятельность программистов как простой и предсказуемый процесс; и не вина учебных заведений, которые хотели бы подготовить студентов к достижению гарантированного успеха.
Это – следствие комфортной иллюзии, что Человек – это лишь сложный автомат, которая, подобно наркотику, приносит своим жертвам кажущееся освобождение от бремени ответственности. Признание программирования серьезным вызовом интеллекту вернуло бы полный вес этой ноши обратно на их плечи.
prof. dr. Edsger W. Dijkstra
Burroughs Research Fellow
© Перевод – Alf, 14 августа 2004.
Оригинальная стаття http://club.shelek.com/viewart.php?id=211
Англояычная статтья http://www.cs.utexas.edu/users/EWD/ewd05xx/EWD540.PDF