Ответ из семизвездочного отеля... , Заметки дзенствующего "сыча".

Прочел с громадным интерересом статьи BrokenSword'а и marlyn'а на http://www.wasm.ru:
http://www.wasm.ru/print.php?article=asmunixlot
http://www.wasm.ru/print.php?article=asminunix.

Великолепно! На самом деле, слава Богу, что хоть кто-то сделал попытку выйти за пределы Assembler-HOWTO.

Но... :D Вот здесь есть парочка уточнений с моей стороны, если позволите... Спасибо, что разрешили... :D
Народ, не обижайтесь, pls, на мой подчас ерническо-язвительный стиль... Ну... Вот таков я есть и поздновато
уже переделываться. Я язвлю и ерничаю не потому, что имею какие-то личные к кому-то претензии. Извините, Бога
ради, если кого-то "цепляю"... :D Не со зла, поверьте.

Итак, "к телу", господа...
Было и не сомневаюсь что будет разработано еще море языков программирования. Но *NIX -- уникальная система
в том, что она основана на едином языке (своего рода протоязык). Это я о С. На С Вы можете сделать в
*NIX все что угодно, в том числе и написать и полностью объектно-ориентированный язык, отвечающий самым последним
идеям в программировании -- это я уже про Java. :) Все остальное -- от Лукавого. Любые соображения не собираюсь
и выслушивать, т.к. достаточно просто проверить сырцы как ядра, так и подавляющего количества программного кода
для *NIX'ов. И сколько там чего окромя С? :D Все остальное -- маркетинговые заверения тех или иных групп
"по интересам"... :D

Рискую обрадовать народ тем, что между С и асмом все-таки есть порочные связи... :D И кроются они в том, что
именно С создавался и разрабатывался как замена ассемблера для ряда задач. Т.е. на момент разработки С
окромя асма, объектных кодов (в которых, по преданиям, кто-то даже когда-то программировал... 8-/ ), не
существовало языков, занимающих промежуточное положение между асмом и FORTRAN, COBOL, PL/1 и иже с ними...

Задача, IMHO, была решена. Причем, решена с "запасом", т.к. на базе С и *NIX были разработаны
промышленные стандарты, обеспечивающие совместимость на уровне исходных кодов и определяющие
уровни соответствия стандарту, указав который можно в сопроводительной документации отметить что нужно
на конкретной платформе иметь из либ, чтобы код скомпилился, слинковался и заработал в минимально короткие сроки.
Это объясняется тем, что в ряде случаев на ряде платформ могут быть, а могут и не быть доп. либы, специфичные
именно для данной платформы. Причем, эти либы так же должны удовлетворять POSIX (проговорился-таки... :) ).
Ну, всем известно наплевательское отношение ряда "контор" к стандартам и то, что сии "конторы" сами стараются
разработать "промышленные стандарты". Так что, оставим это... "Что выросло, то выросло..."

Да, действительно, окромя Assembler-HOWTO в том же Linux нифигашеньки ничего нет. Но и... не надо! Ведь
все уже есть в man'ах! Это по-первых.

Если посмотреть на ключи gcc, то окажется, что на данном шаге можно получить именно ассемблерное
представление кода на С. Особенно это может пригодиться "чистым ассемблерщикам" при изучении функций и передаваемых
параметров. Вот такой вот подарок от "грязного сишника"... :D Но кто запрещает читать man'ы? Почитаем man gcc.
Хэх! Итак, делаем многострадальный "Hello world" на С:

 
#include <stdio.h>
 
int main( int argc, char *argv[])
{
    printf("Hello, World!\n");
    return 0;
}

Далее. При компиляции не пишем (нам оно не надобно) gcc test.c -o test.
Напишем-ка вот так: gcc -S test.c (получим результат #1 -- test.s).
Собственно говоря, это эквивалентно вызову gcc -S -masm=att test.c.
Или вот так: gcc -S -masm=intel test.c (результат 2).

 
    .file   "test.c"
    .section    .rodata
.LC0:
    .string "Hello, World!\n"
    .text
.globl main
    .type   main,@function
main:
    pushl   %ebp
    movl    %esp, %ebp
    subl    $8, %esp
    andl    $-16, %esp
    movl    $0, %eax
    subl    %eax, %esp
    subl    $12, %esp
    pushl   $.LC0
    call    printf
    addl    $16, %esp
    movl    $0, %eax
    leave
    ret
.Lfe1:
    .size   main,.Lfe1-main
    .ident  "GCC: (GNU) 3.2.2"

 
    .file   "test.c"
    .intel_syntax
    .section    .rodata
.LC0:
    .string "Hello, World!\n"
    .text
.globl main
    .type   main,@function
main:
    push    %ebp
    mov %ebp, %esp
    sub %esp, 8
    and %esp, -16
    mov %eax, 0
    sub %esp, %eax
    sub %esp, 12
    push    OFFSET FLAT:.LC0
    call    printf
    add %esp, 16
    mov %eax, 0
    leave
    ret
.Lfe1:
    .size   main,.Lfe1-main
    .ident  "GCC: (GNU) 3.2.2"

Господа ассемблерщики, никто не замечает интересных особенностей в коде #2? :D

Во-вторых. А, собственно, сам процесс написания кода на "чистом асме"... Что с ним?
Вот marlyn в конце статьи приводит прогу "Hello world" на асме и отказывается писать ее с применением
libc, мотивируя отказ "не дзенскостью" сего способа. Согласен. Это не "чистый" асм.

Но вот вопрос :D -- тогда чем занят макрос invoke под виндой? И с какого это перепуга вдруг применение
стандартных для системы библиотек перестало соответствовать Дзен? :D И, если не секрет, как написать прогу под
M$, без использования стандартных функций Win32 API?

Когда мне пришлось писать, скажем так, "перехватчики" для COMM-порта, для Ir и для USB (ну надобно снимать
протоколы обмена M$-прог и девайсов -- все проще чем реверсить), то мне пришлось отказаться от LCC+NASM
в пользу MASM, т.к. сроки поджимали, а вот делать псевдодрайвера для перехвата на NASM -- убиться можно.

Теперь вот передо мной документ на 66 страниц в формате pdf, описывающий некий бинарный протокол хранения
данных о состояниях системы. По сути дела, бинарные логи некой системы. Вот сижу и думаю что со мной будет, если
я сделаю релиз на асме и, самое главное, когда я его сделаю. Особливо, если я откажусь от примения стандартных
функций... :D Да, чуть было не забыл! Описываемая система нелинейна! Т.е. нет такого, чтобы произошло какое-то
событие, записалось в лог и завершилось, опять-таки записавшись в лог. На самом деле, событие произошло, а потом
еще событие (как такого же, так и другого типа) и еще и еще... А только потом завершилось первое.

Вырисоввывается только одна картина -- изрядно поседевший и полысевший Ваш покорный слуга, завершив последнюю
отладку успехом, узнает, что сие оборудование уже списано. :( Мда... по заднице с треском проскакал мороз...
Зима, однако... :D

Далее. Опять-таки по исходникам к прорабатываемому алгоритму. По идее, эта прога сможет исполняться на Linux,
*BSD, Solaris (причем, на последней с вероятностью 80%, т.к. эта система сама по себе на "соляре" и основана,
причем в исполнении SPARC). Что со мной будет, если я внезапно вздумаю, как и BrokenSword, объявить
некоторые переменные в hex-представлении? Особенно, учитывая споры между "тупоконечниками" и "остроконечниками"
относительно порядка следования байт в слове? IMHO, ничего хорошего, т.к. в дополнение ко всем проблемам я еще
и проблемы с редактированием файлецов заполучу. Оно мне это надо? :D

Итак. Когда же все-таки, ассемблер нужен и нужен бесспорно? IMHO, когда Вы жить не можете без тотальной
оптимизации своего кода, когда Вы готовы пожертвовать своим временем и выдрать-таки у безмозглой системы
пару-тройку циклов машинного времени. :D

Или, если серьезно, когда число итераций какого-либо алгоритма довольно велико и сильно грузит процессор.
К такого рода задачам я отнес бы все вычислительные алгоритмы, применяемые в технике (решение СЛАУ,
задачи оптимизации, геоинформационные системы, расчеты распространения радиоволн и интерференции ряда источников
излучения, решение систем дифференциальных уравнений различного порядка, статистический анализ каких-то
абсолтно бешеных объемов, ...). Да. Здесь без асма не обойтись, точнее, обойтись-то можно, но вот цена очень
велика. И никто не мешает Вам написать конкретную процедуру, реализующую именно такой алгоритм на асме, а
потом в цикле прогнать ее по всему объему обсчитываемых данных, предварительно загрузив максимально возможный
объем в память, т.к. если Вы будете читать файл "построчно", то ничего хорошего из такой "оптимизации" не
выйдет.

Запуск pice...
В полет. :D В статье BrokenSword'а есть ссылка на проект pice. И упоминание о том, что
ни какими заклинаниями это безобразие не запускалось... Мда. За такое плохое поведение, эта прога должна
быть запущена. Правда, насторожило то, что она требует поддержку SMP в ядре. Вот что нам точно понадобтся, так
это NASM. Если у кого-то нет, то загрузите и поставьте. У меня, к счастью, в дистрибутиве сразу идет, не пришлось
по ИНету шнырять лишний раз.

Рискнем обойтись без SMP и запустить-таки этого "уродца". Черт меня возьми, господа! Я это сделал, потратив на
этот shit целый вечер! Ни фига себе... "свидание"... Сейчас все объясню.

Во-первых, этот код писал программист на С под Windows. Об этом красноречиво свидетельствует файл
pICE.dsp для M$ Dev. Stud. 6, расположенный в каталоге /module проекта. Нет, я не против С в
Windows, но... Гмммм... Какие-то пределы, все-таки должны быть! Я не знаю что у автора сего "дебуггера" за
хост-среда, но автор -- как минимум неряха, это F?CKt, т.к. нельзя писать грязный код а, тем более, выдавать
его "в свет". Или, если код грязный, то хоть шаркни ножкой... для близиру... Дескать, сорри, пиплы...
Засада... :(

Во-вторых, наименования функций. Меня всегда бесил код, в котором ИмеетМестоБыть_вот_ТакоеВОТshit.
Почтите вслух с первого раза... :D

В-третьих. ДО того, как Вы начнете компилить код, все-таки стоит пройтись по сырцам и добавить в концы
файлов символ возврата каретки (тем самым вы уберете все сообщения от gcc относительно конца файла, печальное
наследие M$ Dev...), поправить определения многострочных констант (чтобы убрать все сообщения от gcc). Это,
скажем так, "косметика", т.к. сообщения имеют статус предупреждений и, вообщем-то ни на что реально не влияют.
Вообще, между нами говоря, самый лучший стиль, это когда нет ни одного предупреждения, т.к.
"предупреждение" это тот самый "стук", который всегда где-нибудь, да вылезет. :( Знаю по себе.

В четвертых. "Недетская" правка. Так, в каталоге /module двигаем в Makefile и правим
строку #16 (MODCFLAGS). Там нужно поменять -m486 на -mcpu=какой у Вас проц. В моем
случае это i686. Посмотрите как у Вас собрался gcc. Этим Вы уберете еще кучу всякого shit'a со
своего терминала при компиляции. Да, и поправьте Makefile для loader'а...

Дальше. Компиляция у меня рушилась на файле smp.c в /module. Конкретнее. Строка #127.
Не находила переменную ulCmdForThisCPU[......]. Вот до чего доводит неряшливость в коде,
господа! Явное нарушение пространства имен! И это проблема не сишников, а их отдельных представителей ("в семье
...", сами знаете... :D ), т.к. нормально прописанный код будет работать и будет переносим. Но если до
компиляции кода нужно разгонять тараканов лопатой, то причем здесь С? И чем это, интересно, в руках автора
занимаются мыши? :D

Разбираться долго не стал, код явно отдает shit'ом, поэтому в строке #43 означенного файла закомментировал
объявление переменной, перенеся оную в файл smp.h --
static volatile ULONG ulCmdForThisCPU[PICE_MAX_CPUS] = {0, };.

Да, я понимаю -- обтесано топором, т.к. глобальные переменные это не здорово, но больше вечера я на
этот shit тратить просто не хотел. Все. С парочкой предупреждений, на которые меня уже просто не хватило,
скомпилилось. Простестил, стер, т.к. такой код, как мне подсказывает моя интуиция и... некоторая практика,
долго не живет.
В чем компилилось -- Slackware 9.0, gcc 3.2.2.

Good luck и милости просим в наш отель... :D

PS Кто не читал статьи -- прочтите. Это действительно отличнейший материал!

загляни еще на linuxassembly.org

Уважаемый Тень,

я перестану смотреть на Ц свысока только тогда, когда все тулзы ГНУ, окроме
эмакса разве, вместятся на самое большее двух флопарях 1,44. Ерунду о том,
что это невозможно, даже не буду слушать -- тов. Аллен Голуб, которого где-то
здесь рекомендовали почитать, утверждает, что работал за полноценным юниксом
на 64к оперативки. Кроме того, он утверждает (а я с ним полностью соглашаюсь),
что требования "оперативки не меньше 16/32/64/128/256/ad infinitum" объясняются
исключительно неряшеством в программировании. Почему ради какого-то выигрыша
в размере обязательно надо жертвовать функциональностью?

Так что разгильдяев мочить надо, батенька. При сем я не говорю о коде, за который
платят деньги (в частности, именно за используемый язык и конвенции типа вотТакогоВотДерьма)
-- сам грешен сим, да и чужое трогать до такой степени чревато. Но
коли пишешь от себя (и free), когда заказчик не стоит за спиной -- здесь нет
прощения.

Кстати, в новых версиях софтов появилась опция configure, цель которой -- задать
максимальную оптимизацию по размеру (по скорости меня не колышет). При сем
предупреждалось, что компиляция жрет памяти немеряно и вообще все такое.
Пробовал кто-нить сие и каков выигрыш?

1. Не злись, ладно? А то и я, грешным делом, начинаю... А кому это надо?

2. "На двух флопарях, на двух флопарях". Сам лично начинал с ИНМОС и ДЕМОС на двух СМ-ках (кто-нибудь помнит что это за пробкотроны?). На одной было 128k, на второй -- 256k, "винты" были сменные на 3МБ. Да. Начинал в армейской структуре, по этой причине и памяти на этих тачках было много. На каждой было по 10 терминалов. С тех пор все "здорово усовершенствовалось" (с) А. Голуб.

Да! Все это было здорово! Но только почему-то память тогда стоила... Ну явно не столько, сколько сегодня. Про граф. оболочки типа GNOME, KDE... да чего там, про те же Motif с OpenLook'ом никто и не слыхивал. А сколько они вкушают памяти? А какие стандартные либы (какого размера)? И сколько времени потрачено было бы на разработку такого же софта (с таким же качеством) на асме?

В конце-то концов, начни проект в "Наших проектах" по созданию UNIX-like ОС в "Наших Проектах", там, по-моему, парочка таких уже есть...

IMHO, стоит не забивать голову чем-то типа утаптывания всего, чего только возможно на полтора флопаря, а разбору существующего кода и создания на его базе более качественного и безопасного кода. Но уже своего. Причем, все-таки, стоит проанализировать что было сделано не так, и избежать грабель, на которых уже кто-то набил шишки. Гляньте в любой, подвернувшийся под руку bugtraq. Ничего странного не заметно? А ведь это, господа, ошибки программеров в части проектирования и реализации. Или, по-русски говоря, "кривые руки" и отказ от следования стандартам!

Зачем все доводить до абсурда? Или сравнение громадного хостинга и встраиваемой системы (той же Embedded Linux или QNX) правомерно? Или задачи у них на 100% аналогичные? Тогда, мой добрый друг, какого хрена каждый, кто приходит в *NIX, начинает оптимизять все что только в голову взбредет? Начинается с того, что при открытости системы должно понять как же, мать его, все это работает? Почему так, а не иначе? Что было до тебя, на каких стандартах замешано?

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

3. Далее. Вот в чем, ASMProgrammer, я с тобой согласен на все сто, так это с тем, что, к сожалению, большая часть кода прописана левой пяткой правой ноги. Пример -- выше. pice. Я решал проблему, а не разбирался с чьими-то комплексами. Мне они сугубо монопениссуальны. Проблема решена? По-моему, да...

Кстати, здесь же. Проблема была обозначена, я постарался ее решить бесплатно и, по возможности, быстро. И это мое убеждение -- я считаю, что мы можем хотя бы попробовать помочь друг другу. В этом, IMHO, суть Open community и Open Source, в конце-то концов. Или... ну, тогда, получается, что в России все это ложь, 3.14zDеж и провокация. Заметно по реакции.

4. Теперь по деньгам. Ну да, согласен, не только программеры могут быть кривыми, есть и менеджеры кривые и их большинство, согласен. Но система не столько самоцель всего, что мы делаем. Мы, пардон, за столь низкие рассуждения, все дружно зарабатываем себе на прожитье. По этой причине я не работаю в коммерческих ОС, где за мои деньги... А, в принципе, прочтите внимательно любое Лицензионное Соглашение от M$...
И я стараюсь заработать как можно больше, работая в максимально удобной для меня среде/системе. Это нормально? Тогда, пардон, я замечу что я -- всеяден, т.к. я -- "наемник". Да. Я даже на Java пишу... Но только... тссссс... никому об этом не говори... Это -- совсем не Дзен.

Успеха, и, если можно, то извини, кажется, я несколько... разозлился...
И дело не в тебе, ни во мне, ни в ком-то, кто прочтет или даже не прочтет эти топики, а в том, что происходит вокруг. Я местами с тобой согласен. Но смотреть на что либо свысока... Да, в принципе, а кого это беспокоит? Хрен бы с ним...
Хотя, я не думаю и даже не пытался смотреть на кого-либо (что-либо) свысока в своем постинге. Я имел глупость попытаться помочь... См. выше.

Добавлено в 22.01.04, 11:43:
По опции configure. Работает. Конфигурит проекты -- только шум стоит. Причем, прописываются условия компиляции для практически всего, подо что можно на gcc скомпилиться.
См. маны.
На размер/скорость не влияет, т.к. работает с опциями позорного gcc.
ДНК урода, пишущего кривой софт, не меняется.

Уважаемый Тень,

gcc -- довольно громоздкий продукт. То же и либц. Поэтому, если я прослыхиваю,
что кой-какой код на первом компилируется из рук вон неправильно (если таков стандарт --
ну его на хрен), а в другой какая-то функция является черной дырой, через которую
крякеры заходят, угадай, что я буду делать, заместо patch&recompile (о ужас!).

Правильно. Заменяю кривой код куском на инлайн асме, который уж точно не подбросит мне
сюрприза.

Цитата

В конце-то концов, начни проект в "Наших проектах" по созданию UNIX-like ОС в "Наших Проектах", там, по-моему, парочка таких уже есть...

Начну, как только смогу жить на проценты. Только доживу ли я до этого, и доживет ли Форум?

Цитата

По опции configure. Работает. Конфигурит проекты -- только шум стоит. Причем, прописываются условия компиляции для практически всего, подо что можно на gcc скомпилиться.
См. маны.
На размер/скорость не влияет, т.к. работает с опциями позорного gcc.
ДНК урода, пишущего кривой софт, не меняется.

Не слишком ли ты здесь разозлился?

Кажется, ты не совсем "въехал" в мой вопрос. А я -- в твой ответ.

А что система вообще хреновая, на все сто согласен. Честно, если б не кривые к этому руки,
зарабатывал бы садоводом/пчеловодом/ваш вариант, а программил ради дзэна

Добавлено в 22.01.04, 12:17:

Цитата

И я стараюсь заработать как можно больше, работая в максимально удобной для меня среде/системе. Это нормально? Тогда, пардон, я замечу что я -- всеяден, т.к. я -- "наемник". Да. Я даже на Java пишу... Но только... тссссс... никому об этом не говори... Это -- совсем не Дзен.

Да ладно тебе... Покажи мне истинного дзэнствующего программера, пребывающего в нирване... Менеджеры никогда не дадут достичь гармонии и постичь Тао программирования.

В том-то все и дело что слишком... :( Не прав я здесь. Признаю. :(
Однако, прикинь, денек... За полчаса до того, как я выполз в Инет, приволокся ко мне один дятел и стал рассказывать, захлебываясь слюнями и соплями про то, что telnet это круто, и как он взломал почту своей "тетки". Этому кретину -- 30 лет и он -- менеджер!!!
:-[.

Я сдержался... Потом завалилась отладка. Я то же сдержался. Ну а тут ты... С "высокомерным взглядом". :) Здесь у меня уже клыки стали подозрительно видоизменяться... :) Извини за резкость.

Да! Согласен я во многом с тобой. Мир, черт его дери, полон несовершенства... :( И мне до нирваны --
как до Пекина клином. Что поделать -- общение с демонами не улучшает характер вообще и мой в частности. Но дело-то не в том...

Я точно так же как и ты довольно много (при оптимизации) переписываю на асме. И к черту все, если это работает лучше. Сто пудов с тобой согласен.

Но вот сам посуди, что было бы со всеми нами, еслиб не существовало громоздких книжек по имени "стандарт". Кстати, глянь в Форуме, была ссылка на POSIX где-то... Может, сгодится.

Мы бы так и путались бы в четырех соснах, заново каждый божий день переписывая все и вся. И я согласен с тем, что gcc не оптимален, но... что лучше? Альтернатив для создания за приемлемые сроки (более-менее оптимального) продукта просто нет. :( И к черту все, если я не могу заработать себе денег для не унижающего меня житья-бытья. Правда, не все я для этого буду делать и не на всем писать... Но это уже вопрос моего выбора и того, что определенные вещи я не буду делать (хоть озолоти). Хотя, если честно, то я о себе говорю, что "у меня нет ни родины, ни флага", но все-таки определенные границы есть (inside)...

Еще раз извини. И не обижайся, pls. Ок? :)
Кстати, в понедельник планирую опубликовать F?CK по программированию на gcc в Форуме. Тебе, как и Микелянджело особое приглашение. Хочется, чтобы зубастые, умные парни все это дело прочли и (пусть даже местами флеймовато) обсудили. Флейм и оффтопик местами идет на пользу дела, т.к. позволяет максимально точно выразить свою позицию по данному вопросу. Да и не роботы мы. "Консенсус поищем?". :D Буду рад.

Между прочим, делал аналогичный эксперимент по генерации асмкода на гцц.
Есть там фичка -- не упомню, вроде -OS либо -Os, но ни фига лишнего она
в прогу не вставила. Код, в общем, получился куда менее хайратый, чем твой --
да нет, совсем лысый, т. к. я бы лучше при всем желании не написал.

Далее. POSIX -- это круто, и я б распял мокрый софт только за то, что они
ему не следуют -- черт возьми, на работе Cygwin, и все равно криво! (Кстати,
в каком форуме больше всего по нему экспертов?)

Между прочим -- надо бы вывалить один линк -- офигеннейший ресурс для
проектировщиков ОС и дзенствующих вообще, где собраны сведения об инструкциях
наиболее популярных процессоров (жаль, ARM не попался)...

А вот и похожий линк: мануалы здесь. Правда, немного не тот...

А тот чегой-то не находится. Ладно, не мой день.

Добавлено в 22.01.04, 13:30:
Кстати, the_Shadow, буду рад сверстать твои письмена, обкусанные флэймерами и
причесанные впоследствии тобой и другими мозговатыми парнями (девушками тоже),
в какую-то "более книжную" форму с последующим выкладыванием где-либо пдф
и постскрипта. Катит?

Цитата

вот и похожий линк: мануалы здесь. Правда, немного не тот...

Подобное тут
http://ulita.ms.mff.cuni.cz/pub/techdoc/
И много интересного у них на ftp.

glibc - это не единственная libc в мире. например busybox собранный с uclibc влазит на полдискеты

Прошу извинить за некоторую задержку. Дал документы почитать одному "парню". Он выдвинул парочку весьма интересных дополнений. В своем, Woland'овском стиле... Приходится доделывать...

Думаю как сделать лучше.
По ARMам у меня есть куча док, выкушенных из ARM Developer Suite (это такая среда разработки на базе Metrowers CodeWarrior 4 Win). Там есть интересные решения (в части отладчика и эмулятора), но во-первых, все работает под M$ (что не здорово, но решаемо), а, во-вторых, этот софт в полном релизе стоит $6800, по-моему. У меня тестовая версия (сидюк). Работает определенный срок.
Ламать не стал, причем, уже по принципиальным соображениям. Надоело. То одно, то другое... Да я что -- Иванупуло, что ли? Кто знает о ком я, тот поймет... Да и не интересно мне это уже -- ломать.

Теперь, по поводу моих постингов. Ну... Знаешь, если честно, то я не знаю и не ведаю что в данном случае лучше/хуже, т.к. все, что я говорю/пишу/делаю -- сугубо относительно. Это всего лишь мое частное мнение. Если оно кому-то интересно, то... Бога ради. Если нет, то... ну и не надо.

Цитата

Знаешь, если честно, то я не знаю и не ведаю что в данном случае лучше/хуже, т.к. все, что я говорю/пишу/делаю -- сугубо относительно.

А что в этом мире есть абсолютного?

Я хотел вот сказать -- если "с Форума по нитке", могла бы выйти довольно-таки приличная
сборная солянка с различными советами по поводу конфигурации тех или иных вещей, что
делать, если чего-то не получается, вообще, всего понемногу, но чтоб полезно... и просто.

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

Тем более -- в свободном доступе. Многим юзерам это было бы неоценимой помощью.

Как знаешь. Хочешь делать -- делай. Согласуй с vot'ом или Song'ом, быть может, эта идея и им понравится...