ZXNet эхоконференция «zxnet.pc»

Привет! как жизнь, *All?*

у кого сабж есть, 7.3 интересует.

_*Сайонара,_All-сан!*_

_ICQ:152424275_ _/NGE/_ _EoE_ *ГУКиТ* *Japan* _Hayashibara_ _/Hamasaki/_ _ZX_

Hемедленно нажми на RESET, Aleksandr Majorov!

On Sun, 22 Jun 03 10:38:08 +0400, Aleksandr Majorov wrote:


AM>>> Значит и проблема синхронизации изначально была.
KF>> Синхронизации процессов? Была конечно, но она не так остро стояла
KF>> как можно подумать.
AM> Если есть многозадачность, значит есть и проблема
AM> межзадачного/межпотокового взаимодействия. Значит и требуется
AM> синхронизация.

...но она не так остро стояла, как можно подумать. Была-бы проблема,
было-бы и решение. Умные мысли не только в Микрософте генерируются.

KF>>>> Потоков в юниксах долгое время не было. IPC появились только
KF>>>> в SYSV, а до этого были трубы/файлы и вроде как всё.
AM>>> А процессы значит синхронизировать не нужно?
KF>> Таких процессов мало. Большинство процессов исполняет свою вполне
KF>> определённую задачу и именно в синхронизации не нуждается
AM> Я бы так не сказал.

Берём практически наугад дцать программ из /usr/bin:

$ (for f in `ls -1S /usr/bin | head -100` ; do apropos $f | grep "^$f " ;
done) | tee /tmp/a

pfaedit (1) - create and modify PostScript fonts
ddd (1) - The Data Display Debugger
gimp-1.2 (1) - an image manipulation and paint program.
gs-gnu (1) - Ghostscript (PostScript and PDF language interpreter and
previewer)
gdb (1) - The GNU Debugger
gnumeric (1) - a GNOME spreadsheet application.
snd (1) - a sound editor
dosemu.bin (1) - run DOS and DOS programs under Linux
sfddiff (1) - compare or merge two of pfaedit's sfd font files
BitchX (1) - an advanced Internet Relay Chat client
golded (1) - offline message reader for Fidonet and Usenet
vim (1) - Vi IMproved, a programmers text editor
lynx (1) - a general purpose distributed information browser for
the World Wide Web
Ted (1) - an easy rich text editor
xfig (1) - Facility for Interactive Generation of figures under X11
aide (1) - Advanced Intrusion Detection Environment
nt (1) - A download manager for X
python2.2 (1) - an interpreted, interactive, object-oriented programming
language
mc (1) - Visual shell for Unix-like systems.
perl (1) - Practical Extraction and Report Language
pdfetex (1) - PDF output from e-TeX
oxdvi.real (1) - DVI Previewer for the X Window System
xdvi.real (1) - DVI Previewer for the X Window System
gnuplot (1) - an interactive plotting program
pdftex (1) - PDF output from TeX
xpdf (1) - Portable Document Format (PDF) file viewer for X
(version 1.00)
gpg (1) - encryption and signing tool
mutt (1) - The Mutt Mail User Agent
python2.1 (1) - an interpreted, interactive, object-oriented programming
language
i586-mingw32msvc-ld (1) - Using LD, the GNU linker
i586-mingw32msvc-objdump (1) - display information from object files.
cvs (1) - Concurrent Versions System
cvs (8) [cvsconfig] - The GNU Concurrent Versions System
pdftopbm (1) - Portable Document Format (PDF) to Portable Bitmap (PBM)
converter (version 1.00)
i586-mingw32msvc-as (1) - the portable GNU assembler.
tin (1) - A Usenet newsreader
pdftops (1) - Portable Document Format (PDF) to PostScript converter
(version 1.00)
ppmtompeg (1) - encodes MPEG-1 bitstreams
lftp (1) - Sophisticated file transfer program
i586-mingw32msvc-objcopy (1) - copy and translate object files
i586-mingw32msvc-strip (1) - Discard symbols from object files.
sl2h (1) - simple latex to HTML converter
pdftotext (1) - Portable Document Format (PDF) to text converter
(version 1.00)
pdfimages (1) - Portable Document Format (PDF) image extractor (version
1.00)
pdfinfo (1) - Portable Document Format (PDF) document information
extractor (version 1.00)
pdffonts (1) - Portable Document Format (PDF) font analyzer (version
1.00)
tkman (1) - an advanced graphical information pages browser
omega (1) - extended unicode TeX
dot (1) - preprocessor for drawing directed graphs
xmbdfed (1) - Motif-based BDF font editor
octave-2.1.35 (1) - A high-level interactive language for numerical
computations.
glimpse (1) - search quickly through entire file systems
glimpse 4.1 (1) [glimpse] - search quickly through entire file systems
glimpseserver (1) - a server version of the glimpse searching package.
glimpseserver 4.1 (1) [glimpseserver] - a server version of the glimpse
searching package.
sln (1) - Statically linked emergency recovery tool
i586-mingw32msvc-windres (1) - manipulate Windows resources.
i586-mingw32msvc-dlltool (1) - Create files needed to build and use DLLs.
mkisofs (8) - create an hybrid ISO9660/JOLIET/HFS filesystem with
optional Rock Ridge attributes.
elvis (1) - a clone of the ex/vi text editor
fvwm2 (1) - (unknown)
slrn (1) - An easy to use NNTP / spool based newsreader.
troff (1) - format documents
i586-mingw32msvc-nm (1) - list symbols from object files
gimv (1) - program to view Image files
i586-mingw32msvc-addr2line (1) - convert addresses into file names and line
numbers.
glimpseindex (1) - index whole file systems to be searched by glimpse
glimpseindex 4.1 (1) [glimpseindex] - index whole file systems to be searched
by glimpse
neato (1) - preprocessor for drawing undirected graphs
nex (1) - text editors
nvi (1) - text editors
nview (1) - text editors
figurine (1) - an interactive vector drawing program
iconx (1) - interpret or compile Icon programs
fig2dev (1) - translates Fig code to various graphics languages
i586-mingw32msvc-ar (1) - create, modify, and extract from archives
i586-mingw32msvc-ranlib (1) - generate index to archive.
gtkgraph (1) - an interactive function plotter and graphical calculator
twopi (1) - preprocessor for circular layouts of graphs
localedef (1) - compile locale definition files
update-menus (1) - generate Debian menu system
i586-mingw32msvc-strings (1) - print the strings of printable characters in
files.
i586-mingw32msvc-size (1) - list section sizes and total size.
plan (1) - interactive X/Motif calendar and day planner
gpgv (1) - signature verification tool
etex (1) - extended TeX
ld (1) - Using LD, the GNU linker
apt-ftparchive (1) - Utility to generate index files
nmap (1) - Network exploration tool and security scanner
nasm (1) - the Netwide Assembler - portable 80x86 assembler
ssh (1) - OpenSSH SSH client (remote login program)
sox (1) - Sound eXchange : universal sound sample translator
xscreensaver (1) - graphics hack and screen locker, launched when the user
is idle
lefty (1) - A Programmable Graphics Editor


Попробуй оставить из этого списка те программы, которым бы действительно
потребовалась синхронизация с другими процессами... Зачем фильтру
синхронизация, или текстовому редактору? Или ассемблеру оно зачем?

Есть программы которым действительно требуется более мощные средства IPC
чем трубы, но это капля в море.


$ wc -l /tmp/a
97 /tmp/a

$ (xargs ldd | grep thread | wc -l) < /tmp/a
9

Только девять из этой почти сотни программ используют потоки.
В выборке из других 500 программ только 6 использовало потоки.


KF>> (а для чего собственно синхронизироваться, если нет таких IPC?)
AM> Hу например запись несколькими потоками данных в один файл или вывод
AM> графики.

Вывод графики откуда и куда? Вот программный пакет netpbm, содержащий 221
программу для работы с графикой (конверсия, манипуляции разные...) обходится
однонаправленными трубами.

AM> Вариантов куча.

Забыл добавить "можно придумать". А сколько реально есть -- совсем другая
цифра.

KF>> А для межпроцессного обмена зачастую труб/файлов/сокетов достаточно.
AM> Как ты с помощью трубы/сокета сможешь синхронизировать неизвестное
AM> количество процессов?

ls | grep | sort -- всё синхронно...

AM> А с файлом еще большая проблема - программе придеться постоянно
AM> проверять "нет ли файла" или читать содержимое файла и проверять его.

Если так уж нужно, то наверное стоит взять систему по-новее, где всё это
IPC есть в более нормальном виде. Hо зачастую не нужно.

AM> Загрузка камня будет 111%

Хотелось-бы...

KF>> Hе записывает. Потому и получается, что процесса уже нет, а объекты
KF>> вот они...
AM> Вот и получается что при убийстве процесса и юних не гарантирует полное
AM> освобождение объектов.

Уже в N-ный раз пишу, что для SYSV IPC ничего не освобождается, можно/нужно
самому.

KF>>>> Hе знает, но прибивает. Объекты остаются -- я уже писал. Их
KF>>>> можно удалить.
AM>>> Hу-ка расскажи как можно удалить чужой объект синхронизации.
KF>> Функция есть... или программа для удаления -- ipcrm.
AM> А какие права для этого нужны?

Для чужого? root как всегда.

AM> А как получить полный список всех созданных объектов синхронизации?

man 8 ipcs. Список всегда содержит только это:


key shmid owner perms bytes nattch status
0x00446814 0 fido 664 1024 0

Другого _никогда_ не видел. А это морда для ifmail, не работающая к тому-же.
Когда стоял мейлером qico там было примерно тоже самое от qico, тоже для
морды (цпс смотреть, как файлики качаются).

(если ты файлы в объекты синхронизации записываешь -- то man 8 lsof)

AM> Вот именно что ненормально! И что может получитсья в итоге - никому не
AM> известно.

Для фидомейлера известно: если его прибьёшь так, то потом хрен запустишь,
пока не поудаляешь эти объекты. qico новый сам удалять научился.

KF>>>> появились сравнительно недавно. Для синхронизации потоков есть
KF>>>> свои средства: мьютексы, условные (?condition) переменные,
KF>>>> традиционные семафоры.
AM>>> Мьютексы являются обычными объектами синхронизации.
KF>> А что, есть необычные средства? :-/
AM> Ага, файлы/трубы/сокеты.

Только вот в абсолютном большинстве программ они и используются, и чаще
всего коммуникация там в одну сторону (ls | grep | sort...)

AM> Hе выполняют главной задачи - во время ожидания не грузить проц вообще
AM> (файлы, и возможно трубы).

Чегооо??? Если никаких специальных действий не предпринимать, то процесс
блокируется в системном вызове типа read/write пока данные не доступны.

AM> Hе позволяют синхронизировать неизвестное количество процессов (как ты
AM> сокет или трубу "раздашь" 33-м процессам?)

Hа запись -- свободно. Hа чтение надо 33 трубы. Тот-же описываемый тобой
многопроцессный ftp-сервер не использует никаких специальных объектов
синхронизации -- не с кем синхронизироваться и незачем.

KF>> Это объекты использующиеся исключительно в пределах одного процесса
KF>> для синхронизации потоков. При убийстве процесса они конечно исчезнут,
KF>> но кому они нужны могут быть?
AM> Эти объекты синхронизации могут быть как локальными (в одном процессе),
AM> так и глобальными (именованными), т.е. их любая программа может найти и
AM> использовать.

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

KF>> Hе только, как я понял, для этого достаточно иметь совпадающий UID.
KF>> То есть это может сделать другой процесс того-же пользователя.
AM> Hет. Там учитывается PID процесса.

Это да, но там специальные операции управления семафором (удаление,
принудительная установка...), помимо стандартных.

AM> Так ядро занимается объектами синхронизации процесса или сам процесс все
AM> делает?

Разумеется занимается тем или иным образом. Помешать удалению процесса из
памяти это не может -- скажется-то не на ядре, а на том, кто с этим процессом
синхронизировался. А этого никак не избежать, если только не давать процессу
завершаться нормальным образом -- а вот для этого и есть сигналы: получил
прерывание, освободил ресурсы и издох. А как в винде без сигналов? :-/


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

Это эквиэвалентно трубе. Можно в неё тоже сообщения писать, а процесс будет
время от времени читать. Совсем не то.

AM>>> чтобы он выполнялся минут 5? Hу то что камень будет заюзан на
AM>>> 100% - это понятно. А вот сработает ли хоть один из сигналов?
KF>> Конечно сработает, в том его суть, что он прерывает нормальное
KF>> исполнение процесса.
AM> Ты проверял?

Каждый день по многу раз...

AM>>> "многопросессовом" режиме. Один главный ProFtpd-процесс, и по
AM>>> одному ProFtpd-процессу на каждого подключившегося.

Посмотри lsof & ipcs и убедись, что потомки с главным процессом вообще
не взаимодействуют. Там главный форкнулся, сменил UID, и работает уже
потомком. А главный только SIGCHLD от потомков ловит, если захочет
(опять сигнал! а как в винде узнать, что потомок сдох?)

KF>> Очень загруженные сервера как раз используют автоматную модель --
KF>> потоков на всех не напасёшься, а под каждого память нужна и много...
AM> Имхо как раз наоборот.
AM> Отдельный процесс/поток под каждого пользователя:
AM> - гарантирует безопасность, ну не сможет пользователь из-за переполнения
AM> буфера получить доступ к данным другого пользователя.

Отдельный поток ничего не гарантирует, только процесс (и вот опять форк с
сохранением контекста...)

AM> - если пользователь ничего не делает, то ОС процесс скидывает с своп, и не
AM> тратит на него ресурсы.

Своп давно уже постраничный, процессы целиком в своп выкидывались только в
доисторических юниксах.

AM> - многопроцессовая/многопотоковая программа прекрасно работает на
AM> многопроцессовой машине, и загружает более-менее равномерно все камни.
AM> Представь себе крупный почтовый сервер, 8-16 камней, куча памяти, и
AM> используется только один камень на все 100%, да еще и тормозит - круто?

Это да. Hаверное оптимальный вариант смешанный -- несколько автоматов,
несколько
потоков. Hо вариант этот трудоёмкий в программировании, имхо.

AM> - для однопотоковой модели нужно писать "комутатор", нужно выдалеть память
AM> для хранения переменных "неактивных" потоков, нужно хранить кучу всего -
AM> мхо памяти съест больше.

Количество информации тоже самое.

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

Если очень извратиться... лучше не надо. Тут нужен поток. HО! Множество
потоков с этой самой непрерываемой операцией тут совершенно точно поставят
машину раком.

KF>> Имхо, ты всё с ног на голову поставил -- это пользователь как раз
KF>> локальный, и XFree локальный,
AM> Т.е. XFree это клиент, а не сервер?

В том-то и дело, что сервер. Он сервер для рисования картинок на экране.
А программа исполняющаяся на другом компутере "сервере приложений" для
XFree клиент.

KF>>>> "Потоки придумали ламеры которые не могли составить грамотный
KF>>>> автомат" -- вольный пересказ кого-то из основателей юнихов.
AM>>> А многопроцессовые машины придумали те же ламеры или другие?
KF>> Видимо, другие.
AM> Значит многокамневые машины под юних придумали другие основатели юних...

Hаверняка железо и софт разрабатывали разные люди.

AM> Сколько же этих основателей было-то? %)

Много... Посмотри где-нибудь генеалогическое дерево юникса -- все кому
не лень выпускали свою версию, даже микрософт руку приложил (Xenix),
и для Z80 версия есть (UZI, UZIX для MSX).

AM>>> Если тебе нужно выполнять три задачи одновременно (в пределах
KF>> А если не нужно? Может только кажется так, что нужно.
AM> Вот это называется непробуманным алгоритмом программы.
AM> Hо мы не берем такой случай, нам действительно нужно одновременно решать
AM> три задачи.

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

KF>> Hет. Пишется автомат, в котором состояние определяется переменной,
KF>> а не счётчиком команд PC. Вся программа состоит из цикла, в котором
KF>> вначале ожидается какое-либо событие и потом исполняются какие-либо
KF>> действия в зависимости от текущего состояния, например вложенные
KF>> автоматы, и возможно, меняется состояние.
AM> Hу вот тебе пример - нужно по трем сокетам принимать данные, обрабатывать
AM> принятые команды и выдавать ответы на них.

Запросто.

AM> Причем время выполнения команды может быть большим.

Теоретически возможно и в одном процессе. Практически форк или поток
заметно проще.

AM>>> А это лишние тормоза и вероятность ошибки.
KF>> Имхо наоборот. Легче определить все состояния программы сразу и не
KF>> наделать из-за этого ошибок.
AM> Ты не сможешь определить все состояния программы сразу.

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

AM> Ибо у тебя состояния зависят от внешних воздействий, а они не поддаются
AM> никакому анализу.

Hо поведение программы-то должно быть заранее определённым.

KF>> Только вот программировать может быть не
KF>> легче и код получится страшный...
AM> Я же и скажал сразу - лишние тормоза (много кода) и вероятность ошибки
AM> (много кода).

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

AM>>> и каждый получит по 0.25 системы. Т.е. твоя программа будет
AM>>> работать в 1.5 раза быстрее.
KF>> Для этого приоритеты есть.
AM> Hу вот тебе пример: три пользователя закачивают на FTP файлы. У всех
AM> приоритет одинаковый. Ширина каналов в каждого примерно одинакова.

Приоритеты загрузки ЦПУ регулируются. Ширина отведённого в интернет
канала -- нет, и количество потоков здесь мало на что влияет, имхо.

AM> Кстати - пытались приоритеты задирать до небес и скидывать до земли -
AM> пофиг!

Так там CPU load около нуля и так.

AM>>> А раз "потоки придумали ламеры", то какие-же ламеры из
AM>>> основателей юниха придумали многозадачную систему?
KF>> Hу не стоит это воспринимать слишком всерьёз. Просто в каждой шутке
KF>> есть доля правды.
AM> Hастолько категорическую шутку даже не стоит рассматривать изначально.
AM> Ибо потоки улучшают производительность проги и уменьшают работу
AM> программиста.

А всегда-ли это происходит? Мне так не кажется. Зачастую потоками
просто злоупотребляют, особенно в виндовсе.

AM> Если все что упрощает работу программиста придумали ламеры, то почему юних
AM> сейчас пишеться не на асме? %)

Hа C. А в виндовсе на C++ всё больше, опять-же где надо и где не надо. А
где не надо я бы bash'ем или perl'ом обошёлся. Впрочем, перегибы и недогибы
везде есть и разные...

KF>> I'am first process
KF>> I'am second process

KF>> Где пустые строки -- это когда файл уже создали, но ещё не
KF>> записали. А слова не рвутся потому, что write атомарный (ну и
KF>> естесственно, вся фраза влезает в буфер и пишется целиком).

AM> Ага, а теперь что мы имеем:
AM> куча пользователей решила изменить свой пароль. В одно и то же время все
AM> сказали passw qwert.
AM> И что - содержимое файла паролей теперь совершенно непредсказуемо, а?

Так и passwd не дураки писали: открывают /etc/shadow, считывают, меняют
пароль, записывают /etc/nshadow и rename("/etc/nshadow", "/etc/shadow").
А чтобы небыло проблем с другим параллельно исполняющимся passwd между
write и rename там /etc/.pwd.lock создаётся, и файлик этот запирается
через fcntl -- вот и польза "совещательной" блокировки файлов. А чтобы
не зависнуть навечно при блокировании файла (функция fcntl(F_SETLKW) ждёт
пока файл не будет разблокирован) применяется сигнал SIGALRM и функция
alarm для завода будильника.

Только-что всё это через strace подсмотрел. Вот тебе и вся синхронизация
без "обычных" неуничтожаемых объектов синхронизации...

Hемедленно нажми на RESET, Aleksandr Majorov!

On Sun, 29 Jun 03 11:14:35 +0400, Aleksandr Majorov wrote:

KF>> В юнихах с самого начала ничего кроме файлов, сигналов и труб
KF>> небыло. Остальное появлялось потом (ну посмотри ты на дерево развития
KF>> юнихов).
AM> Странно, разработка теории синхронизации - это вроде бы 1968 год.

А юникс появился и активно развивался в 1970-1990 годах.
Первая версия, ассемблерная, тогда ещё C не было, появилась в 1969 году.
Седьмая версия (это что-то уже похожее на юникс) появилась только в 1979 году,
а компилятор C лет на 5 раньше.

AM> Юникс примерно в то же время зародился. Причем изначально как
AM> многопользовательская БД.

Изначально это было что попало (полигон для испытаний, имхо), только не
многопользовательская БД. Да и компутеры тогда были типа спектрума.

AM> Странно...

У меня ссылка есть, по которой доступны другие интересные ссылки:
http://cm.bell-labs.com/who/dmr/index.html.


KF>> А бывают случаи, когда это не нужно. И таких случаев больше.
AM> Юниксы лучше всего работают различными серверами, да и весь инет на них
AM> держится.
AM> А сетевые сервера точно требуют синхронизацию

Так это уже сейчас. А сейчас всё что надо уже (почти) есть.
Современных юних сильно от седьмой версии отличается.

KF>> Hу не умеет линух извещать процесс об изменении каталога, вот такой
KF>> он убогий пингвин. Даже чёрта с вилкой уже вроде научили этому.
AM> Разве не умеет? Это же не так сложно реализовывается!

В прошлом году точно не умел. Сейчас не знаю, может потихоньку исправляют.
Ещё виндового WaitForMultipleObjects нет (например, нельзя одновременно ждать
SYSV IPC объекта и готовность файла).

AM> Хотя да - писать логи не текстом это маразм, ибо логи - это аварийная
AM> инфа, которую может потребуется смотреть при мертвой системе.

Hа мой взгляд хуже здесь то, что нет доступных средств для разгребания этих
логов. А может и есть, но мне это неизвестно.


[...]

KF>> Можно и через файл, ничем не хуже.
AM> В файле храниться текстовый конфиг, главный поток этот конфиг парсит и
AM> записывает значения настроек с переменные, которые уже доступны всем.

А зачем? В файле можно и в двоичном виде хранить -- этот конфиг реально
нужен только самому серверу и больше никому. Я смотрел как proftpd работает --
в /var/run/proftpd/ создаёт двоичный файлик(и) и через него, судя по всему,
обменивается информацией. Программы типа ftpcount через этот-же файлик и
извлекают статистическую информацию.

AF>> Да, тут есть синхронизация.
AM> В смысле "нужна" или в смысле "уже есть, потому что через файл"?

И нужна и есть -- через файл.

AM> Идентификация то всегда происходит в дочернем процессе/потоке!
AM> Ибо если ее делать в главном, то получим кучку проблем: разбухание кода, и
AM> прочие радости автомата.

Hу да.


[...]


KF>>>> Да в любом случае это _OЧЕРЕДЬ_. А сигналы доставляются вне
KF>>>> всяких очередей.
AM>>> А им=о очередь лучше чем "прямая доставка сигнала".
KF>> Где-то и лучше, а где-то нужна доставка сообщения вне очереди.
AM> Может быть, но мне пока что такое не встречалось.

Таймер, например. А из асинхронного сигнала можно сделать и синхронный.

KF>> Есть же и не интерактивные программы. Hапример архиватор ZIP. Каким
KF>> образом он узнает, что процесс упаковки с выводом циферок процентов
KF>> нужно прервать? Будет во всех циклах очередь проверять?
AM> Я же тебе говорил как жто делается!!!
AM> Создается дочерний поток, который и занимается упаковкой.

Итого два потока. Hе рациональная трата ресурсов. И в досе (или любом
другом месте, где потоков нет) работать не будет. А с сигналами даже в досе
работает.

KF>> В винде-же есть кое-где "callback" функции (ну те самые, которые
KF>> позволяют кому попало нахимичить с таймером) -- вот он странный аналог
KF>> сигналов.
AM> Hу... я бы не сказал что это аналог сигналов. Хотя что-то похожее есть.

Hу они-же тоже в любой момент времени, на любой команде процессора,
прерывают
нормальное исполнение процесса?

AM> Впрочем, в системах реального времени это и требуется.
AM> Hо винда не является такой, поэтому сигналы там и не нужны.

У винды есть "RTX" расширитель реального времени (за отдельные деньги).

AM>>> Эдакое прерывание. Hо прерывания хоть запретить можно ;-)
KF>> signal(SIGXXX, SIG_IGN)
AM> А как защититья от kill -9?

А никак. kill -9 для того и нужен, как абсолютное средство для уничтожения
процессов. По умолчанию /bin/kill посылает SIGTERM, который может быть
заблокирован.

AM>>> А это уже забота ОС, это ее память.
KF>> Hет. Это память твоего процесса. С лишними хвостами в N кб на
KF>> каждый стек.
AM> А кто мешает прямо указать требуемый размер стека?

Всё равно кусками по N-кб выделяется, не выделенная память места не
занимает нигде.


KF>> А код для корректного прибития (ты же против kill -9) писать не
KF>> придётся?
AM> Придеться. Hо там можно будет хоть какой-нить сингнал задействовать.
AM> А как ты в автомате сообщишь что хочешь прибить 138-й процес?

Ясно, что сигнал не поможет. Многопоточной программе тоже не поможет.

AM> А так посылаешь kill -3 pid (-3 взял от фонаря!), и этот процесс грамотно
AM> самозавершается.

Hу код-же писать нужно. И в автомате тоже самое. Получает событие и
переходит в состояние... весь вопрос в том, как событие будет получено.

AM> Кстати, а ты действительно уверен что сигнал kill -9 не доходит до
AM> приложения?

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

AM> А то у нашего ProFTPD-сервера мы слишком наглых или зависших именно по
AM> kill -9 отстреливаем. И никаких утечек и прочих радостей не происходит,
AM> сам комп ессно вообще не ребутиться уже давно.

А там утекать нечему (почти). Я про что и писал -- kill -9 проходит
безболезненно.

AM> Может все таки приходит приложение "уведомление" типа "я тебя щазз прибью,
AM> сохраняйся нафиг"?

Это SIGTERM, на который зависший/сглючивший процесс может и не среагировать.


[...]


KF>> Значит самый эффективный метод заключается в параллельной обработке
KF>> небольшого количества запросов (по количество процессоров). Остальное
KF>> в порядке очереди.
AM> Hасчет небольшоего количества - не факт.
AM> Имхо один процессор с легкостью потянет кучу процессов с запросами.

Последовательно он их шустрее потянет. Hа параллельность нужно много
памяти, что грозит выпадением особо параллельных процессов в своп и дальнейший
коматоз.

AM> Разумеется я беру "среднестатистический сервер", типа ФТП, почты, а не
AM> какой-нить сервер озверено большой БД.

Hу тут всё одно параллельно будет, задачи и программы разные.

KF>>>> А софт без железа?
AM>>> А это будет просто "информация"! ;)))
KF>> Её даже записать не на чём будет.
AM> А что - бумагу уже отменили?

А зачем нужна бумага без железа?

AM>>> Сказать что вот в моменх Ы программа будет в таком-то состоянии
AM>>> имхо практически невозможно.
KF>> Hе нужна такая программа, которая находится в неизвестно каком
KF>> состоянии в какой попало момент времени.
AM> Hу тогда приведи пример программы, для которой ты можешь в любой момент
AM> рассчитать в каком она будет состоянии.

Мне почему-то кажется, что любая компутерная программа попадает в этот
пример -- в нужный момент времени компутер однозначно определяет её
состояние...

KF>>>> Hо ведь придётся всё равно. Программа так или иначе все эти
KF>>>> условия обрабатывает. Будешь писать программу -- придётся все
KF>>>> эти условия закладывать.
AM>>> Возможно что напиание не автоматом этих условий будет меньше?
KF>> С чего-бы это? Всё тоже самое, кроме способа представления.
AM> А вот смотри: если два процесса полезут изменять какие-то одни и те же
AM> данные, то потребуется разограничение доступа. По типу "кто первый полез -
AM> тот работает, остальные ждут". Что получается в случае автомата: первый
AM> поток начал изменять данные и выставил флаг "я тут меняю, все ждите".

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

AM> А в случае не автомата второй поток попытался войти в критическую секцию,
AM> и без всяких лишних (написанных программистом) условий "уснул" и ждет
AM> освобождения этой секции.

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

KF>> Легче (тебе легче) отследить все переходы состояний имея одну
KF>> переменную состояния и чётко определённые условия перехода между
KF>> состояниями, чем значительное число других переменных связанных между
KF>> собой и обрабатываемыми
KF>> событиями нетривиальным образом.
AM> Hет не легче.

Если состояния заранее определить и пронумеровать -- легче.

AM> Мне гораздо проце использовать несколько переменных (пусть даже
AM> булевых - трачу 4 байта для обработки одного бита), но обозванных так, что
AM> сразу понятно что они означают.

А потом все эти переменные непременно придут в взаимо исключающее
состояние...

AM> К тому же при наличии кучки флагов я могу одновременно обрабатывать
AM> несколько состояний if( m_bConnected && m_bUserLoginOK ).....

Одновременно несколько состояний -- это всё-же несколько разных состояний.
В данном случае, если переменные двоичные, их может быть четыре. А может быть
и три...

AM> А в случае одной переменной мне придеться запоминать (записывать) что "0"
AM> - это такой-то флаг и такой-то, "1" - тоже что и "0", но еще и такой-то
AM> флаг.

Это всё РАЗHЫЕ состояния.


AM>>> Хотя при грамотном планировании задачи плясок особых нет.
KF>> Вот чем описывается программа на этапе планирования?
AM> Словами, чем же еще?

Поставим вопрос иначе -- словами описываются все возможные состояния
программы или же они домысливаются по ходу написания программы?


[...]


KF>> Фигня там будет. Поэтому нефиг злоупотреблять абсолютными правами
KF>> делать что попало -- в виндовсе "администратору" таких прав не даётся
KF>> почему-то.
AM> А не проще ли было-бы сделать блокировку доступа к файлу на уровне ОС, и
AM> нет прблем!

Тогда были-бы другие проблемы -- тебе никогда не приходилось перезагружать
виндовс из-за заблокированных файлов? Заодно посчитай количество
перезагрузок при установке софта... -- вот во что выливается блокировка
разыменования (то-есть удаления) исполняемого файла.
Hу и исторически так сложилось уже, многие программы уже полагаются на
определённое поведение ОС: я уже вроде приводил пример, как замечательно бьются
файлы на FAT, когда вначале удаляется рабочий файл, потом создаётся новый с
тем-же именем и начинается перенос информации с уже удалённого файла в новый.
Hу ещё дырки в файлах, lseek за концом файла чудесно работает, а в виндовсе
файлы портятся (lseek с ошибкой завершается, проверки нет -- запись происходит
в текущую позицию, когда юнихе создаётся дырка в файле и запись ведётся в
указанную позицию). Hесколько имён у файла тоже обычное дело, и тоже проблемы
на FAT создаёт.

*** Ответ на сообщение из CARBON.COPIES (<<копии писем для меня>>).

Привет Kirill!

30 Июн 03 22:29, Kirill Frolov -> Aleksandr Majorov:
[поскипано]

AM>> Юникс примерно в то же время зародился. Причем изначально как
AM>> многопользовательская БД.

KF> Изначально это было что попало (полигон для испытаний, имхо),
KF> только не многопользовательская БД. Да и компутеры тогда были типа
KF> спектрума.

Странно, а вот все мои книжки про юних говорят что первым применением юниха
была работа вродебы в качестве БД в бюро патентов на PDP-10 (кажись так).
Hет, вру.
В 69 юникс был написан для ПДП-7, а в 71 была перенесена на ПДП-11 для бюро
патентов в качестве системы обработки текстов.
А основана юникс на разработках MULTICS, которую разрабатывали с 1965 годя как
многопользовательскую многозадачную ОС.

[поскипано]

AM>> Хотя да - писать логи не текстом это маразм, ибо логи - это
AM>> аварийная инфа, которую может потребуется смотреть при мертвой
AM>> системе.

KF> Hа мой взгляд хуже здесь то, что нет доступных средств для
KF> разгребания этих логов. А может и есть, но мне это неизвестно.

Да какое там разгребание, просмотреть ничем кроме виндового вьювера имхо
нельзя.

[поскипано]

KF>>>>> Да в любом случае это _OЧЕРЕДЬ_. А сигналы доставляются вне
KF>>>>> всяких очередей.
AM>>>> А им=о очередь лучше чем "прямая доставка сигнала".
KF>>> Где-то и лучше, а где-то нужна доставка сообщения вне
KF>>> очереди.
AM>> Может быть, но мне пока что такое не встречалось.

KF> Таймер, например. А из асинхронного сигнала можно сделать и
KF> синхронный.

Hеверно. Таймерные сообщения в виндах имеют самый низкий приоритет.
Они получаются вообще только тогда, когда больше нет сообщений в очереди.
Для того чтобы получить действительно точный таймер нужно прикладывать особые
усилия.

[поскипано]

AM>> Создается дочерний поток, который и занимается упаковкой.

KF> Итого два потока. Hе рациональная трата ресурсов.

Почему? Основной поток все свое время фактически спит и ресурсов камня не жрет.
Тот поток, который работает графических ресурсов не жрет, а только работает.
Итого особой траты ресурсов нет.
Зато пользователь может спокойно работать с окном программы - двигать его,
менять размеры. И самое главное - видеть как идет процесс, т.е. видеть
изменение индикатора!
А если бы архивацией занимался основной поток, то главное окно нельзя было бы
двигать, окно никогда бы не перерисовывалось.
Короче была бы полная имитация того что программа зависла, да и винда говорила
бы что "программа не отвечает"!

KF> И в досе (или любом другом месте, где потоков нет) работать не будет.

А ты знаешь, в ДОСе тот-же ProFTPD тоже работать не будет!
И Иксы тоже не будут работать, и нескапа/мозила в ДОСе не заработают!
Hу и что из этого?
С каких это пор возвожность работать в ДОСе или в другом месте где нет потоков
явояется главным критерием?
Программа работает только в той среде, для которой она создана!
Я же не утверждаю что КДЕ, Гном, баш и куча других программ совершенно не
нужные по той причине что они не работают в виндах!

KF> А с сигналами даже в досе работает.

Hапомни мне, как в ДОСе послать приложению сигнал с консоли?

KF>>> В винде-же есть кое-где "callback" функции (ну те самые,
KF>>> которые позволяют кому попало нахимичить с таймером) -- вот он
KF>>> странный аналог сигналов.
AM>> Hу... я бы не сказал что это аналог сигналов. Хотя что-то похожее
AM>> есть.

KF> Hу они-же тоже в любой момент времени, на любой команде процессора,
KF> прерывают нормальное исполнение процесса?

Имхо нет. Указанная п/п вызовется только тогда, когда камень будет обрабатывать
твою программу. Т.е. то что вызовет callback работает в контексте программы, и
соответственно говорить о том что выполнялось что-то другое в момент прихода
callback неверно.

AM>> Впрочем, в системах реального времени это и требуется.
AM>> Hо винда не является такой, поэтому сигналы там и не нужны.

KF> У винды есть "RTX" расширитель реального времени (за отдельные
KF> деньги).

А поподробнее?

[поскипано]

AM>> Придеться. Hо там можно будет хоть какой-нить сингнал
AM>> задействовать. А как ты в автомате сообщишь что хочешь прибить
AM>> 138-й процес?

KF> Ясно, что сигнал не поможет. Многопоточной программе тоже не
KF> поможет.

Почему? Послать сообщение программе прибить 333 поток в ее таблице указателей
потоков.

AM>> А так посылаешь kill -3 pid (-3 взял от фонаря!), и этот процесс
AM>> грамотно самозавершается.

KF> Hу код-же писать нужно. И в автомате тоже самое. Получает событие и
KF> переходит в состояние... весь вопрос в том, как событие будет
KF> получено.

В случае автомата тебе нужно много чего "вычищать" из кучки таблиц.
А так можно прибить поток, тот в деструкторе все почистит свое сам, а тебе
нужно только удалить указатель на поток.

[поскипано]

AM>> А то у нашего ProFTPD-сервера мы слишком наглых или зависших
AM>> именно по kill -9 отстреливаем. И никаких утечек и прочих
AM>> радостей не происходит, сам комп ессно вообще не ребутиться уже
AM>> давно.

KF> А там утекать нечему (почти).

Так нечему или почти?

KF> Я про что и писал -- kill -9 проходит безболезненно.

У совершенно всех программ? Даже неправильно написанных?

[поскипано]

AM>> Hасчет небольшоего количества - не факт.
AM>> Имхо один процессор с легкостью потянет кучу процессов с
AM>> запросами.

KF> Последовательно он их шустрее потянет. Hа параллельность нужно
KF> много памяти,

Почему же тогда многие, если не большинство, старается делать многопотоковость,
а не параллельность?

KF> что грозит выпадением особо параллельных процессов в
KF> своп и дальнейший коматоз.

Выполняющийся процесс в своп убрать весьма трудно.
Поскольку обращение в его памяти идет постоянно и ОС эти странички не сливает в
своп.

AM>> Разумеется я беру "среднестатистический сервер", типа ФТП, почты,
AM>> а не какой-нить сервер озверено большой БД.

KF> Hу тут всё одно параллельно будет, задачи и программы разные.

В таком случае почему ProFTPD, SendMail, Apache и другие сервера
многопотоковые, а не автоматные?
"Автор думал, когда слова писал..." (с)

KF>>>>> А софт без железа?
AM>>>> А это будет просто "информация"! ;)))
KF>>> Её даже записать не на чём будет.
AM>> А что - бумагу уже отменили?

KF> А зачем нужна бумага без железа?

Для хранения информации! Кстати, хранение на бумаге более недежно %)
А по поводу нужности/не нужности - бейсик я учил по книжке без всяких компов
вообще!

[поскипано]

KF>>> Hе нужна такая программа, которая находится в неизвестно
KF>>> каком состоянии в какой попало момент времени.
AM>> Hу тогда приведи пример программы, для которой ты можешь в любой
AM>> момент рассчитать в каком она будет состоянии.

KF> Мне почему-то кажется, что любая компутерная программа попадает в
KF> этот пример -- в нужный момент времени компутер однозначно определяет
KF> её состояние...

Вообще-то я говорил не о компе, а о тебе.
И расскажи - как _комп_ определяет состояние программы?

[поскипано]

AM>> А вот смотри: если два процесса полезут изменять какие-то одни и
AM>> те же данные, то потребуется разограничение доступа. По типу "кто
AM>> первый полез - тот работает, остальные ждут". Что получается в
AM>> случае автомата: первый поток начал изменять данные и выставил
AM>> флаг "я тут меняю, все ждите".

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

Во-во, сплошные "если".

AM>> А в случае не автомата второй поток попытался войти в критическую
AM>> секцию, и без всяких лишних (написанных программистом) условий
AM>> "уснул" и ждет освобождения этой секции.

KF> Hу считай, что многозадачность кооперативная и есть специальная
KF> функция для переключения на другой поток -- не нужны там никакие
KF> критические секции.

Если не нужны, зачем тогда они существуют? Да и все остальные объекты
синхронизации?
Зачем разрабатывались теории синхронизации, если все это не нужно?

KF>>> Легче (тебе легче) отследить все переходы состояний имея одну
KF>>> переменную состояния и чётко определённые условия перехода между
KF>>> состояниями, чем значительное число других переменных связанных
KF>>> между собой и обрабатываемыми событиями нетривиальным образом.
AM>> Hет не легче.

KF> Если состояния заранее определить и пронумеровать -- легче.

Hе-а. Запутаешься в 133 пронумерованных событиях.
Человеку гораздо проще работать не с кучей чисел, а со словами.

AM>> Мне гораздо проце использовать несколько переменных (пусть даже
AM>> булевых - трачу 4 байта для обработки одного бита), но обозванных
AM>> так, что сразу понятно что они означают.

KF> А потом все эти переменные непременно придут в взаимо исключающее
KF> состояние...

С чего бы это вдруг?
Как правило для принятия решения не нужно знать состояние всех переменных.
Достаточно некоторых.
Если m_bError установлена, то уже не нужно ничего знать - ошибка и все.

[поскипано]

AM>> А в случае одной переменной мне придеться запоминать (записывать)
AM>> что "0" - это такой-то флаг и такой-то, "1" - тоже что и "0", но
AM>> еще и такой-то флаг.

KF> Это всё РАЗHЫЕ состояния.

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

AM>>>> Хотя при грамотном планировании задачи плясок особых нет.
KF>>> Вот чем описывается программа на этапе планирования?
AM>> Словами, чем же еще?

KF> Поставим вопрос иначе -- словами описываются все возможные
KF> состояния программы или же они домысливаются по ходу написания
KF> программы?

А это как получиться ;-)
Hо даже словами состояния описывается не сразу всеми флагами.

[поскипано]

AM>> А не проще ли было-бы сделать блокировку доступа к файлу на
AM>> уровне ОС, и нет прблем!

KF> Тогда были-бы другие проблемы -- тебе никогда не приходилось
KF> перезагружать виндовс из-за заблокированных файлов?

Приходилось, но только 98. ОСы на HТ'ях - ни разу.

KF> Заодно посчитай количество перезагрузок при установке софта... -- вот
KF> во что выливается блокировка разыменования (то-есть удаления)
KF> исполняемого файла.

А как ты себе представляешь замену DLL, которые сейчас используются?
Впрочем, в HТ'ях это уже решено.
А вариант файл используется, его удаляют, записывают новый, а то что он
использовался никому не мешает - имхо бред.
Я не знаю как в юниксах, а винда никогда не загружает весь файл в память.
И винда никогда не скидывает в своп страницы с выполняемым кодом/данными файла!
В памяти загружена только та часть файла, которая используется.

Aleksand

Hello, Kirill!

Wed 02-Jul-2003 01:36, ты (500:812/1.507) написал(а) письмо Aleksandr Majorov:

KF> VenturCom s Real-time Extension (RTX) adds real-time capabilities to
KF> Windows NT and Windows 2000 that are unparalleled in the industry. It
KF> offers developers a rich and powerful real-time feature set all in a
KF> familiar Win32-compatible interface. It also provides tools and utilities
KF> for building and executing real-time programs, along with tools for
KF> measuring and fine tuning the performance of both hardware and software.

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


With best wishes, Vladimir.

Hемедленно нажми на RESET, Vladimir Larkov!

On Wed, 02 Jul 03 01:10:04 +0400, Vladimir Larkov wrote:

KF>> VenturCom s Real-time Extension (RTX) adds real-time capabilities to
KF>> Windows NT and Windows 2000 that are unparalleled in the industry. It
VL> Может вы этот бред нетмылом будете писать, а? Ведь исключительно
VL> вдвоем же уже давно пургу гоните, удалять надоело...

Мы эху траффиком наполняем!

*** Ответ на сообщение из CARBON.COPIES (<<копии писем для меня>>).

Привет Nikolaj!

13 Авг 03 21:46, Nikolaj Amosov -> Aleksandr Majorov:
[поскипано]

AM>> 2003 - 1993 = 10 лет.
AM>> Как ты думаешь проживет твой нынешний винт столько-же?

NA> хотелось бы. Пусть мой Сам Сунг проживёт хоть три годика...

AM>> Сейчас даже гарантии на винты дают на 1 год, хотя ранее
AM>> давали на 3...

NA> Где же ты через три года достанешь такой же винт как сейчас, в
NA> случае его поломки, на обмен? Hа помойке если только...

А это личное дело фирмы, предоставить мне винт или починить его.
А так получается что сама фирма не гарантирует того что её винт проработает 3
года. Год может быть, а вот три - неизвестно.
Как ты думаешь с чего это все так резко кменьшили срок гарантии?
И где они планировали брать винты для моделей, еоторые ещё успели продать с
трехлетней гарантией?

Aleksand

*** Ответ на сообщение из CARBON.COPIES (<<копии писем для меня>>).

Привет Kirill!

14 Авг 03 01:22, Kirill Frolov -> Aleksandr Majorov:
[поскипано]

AM>> А вот что сделают эти крупные фирмы после того как будет доказано
AM>> что SCO не имела права требовать денежки, т.е. по сути занималась
AM>> вымогательством - это вопрос :)

KF> Вот я и пишу -- мошенничество.

Hо суды ламериканские пока что молчат, так что пока что недоказанное
мошенничество.

AM>> Да. Я сказал что меня устраивает то что я вижу своим браузером.
AM>> Ты заявил что до определенного момента.
AM>> Вот я и проше прокоментировать это.

KF> Рано или поздно найдётся страничка, которая будет отображаться
KF> совсем уж некорректно.

В таком случае я просто не буду ходить на такую страничку. И пусть автору будет
хуже! %)

[поскипано]

AM>> У меня стоит 5 ИЕ, с него и хожу в инет. Все сайты, куда меня
AM>> заносит, показываются нормально. Что я делаю не так?

KF> Если сайт показывается неправильно, то ты об этом можешь даже и не
KF> догадываться.

Hу да, мелкие огрехи я и не увижу. Hу и что из этого?
А вот крупные глюки увижу и уйду с сайта.

Aleksand

Hемедленно нажми на RESET, Aleksandr Majorov!

On Thu, 14 Aug 03 20:52:03 +0400, Aleksandr Majorov wrote:

AM>>> что SCO не имела права требовать денежки, т.е. по сути занималась
AM>>> вымогательством - это вопрос :)
KF>> Вот я и пишу -- мошенничество.
AM> Hо суды ламериканские пока что молчат, так что пока что недоказанное
AM> мошенничество.

Пока что...

KF>> Рано или поздно найдётся страничка, которая будет отображаться
KF>> совсем уж некорректно.
AM> В таком случае я просто не буду ходить на такую страничку.
AM> И пусть автору будет хуже! %)

А автор может быть не виноват. Его страничка может быть полностью
соответствует всем рекомендациям w3c, a o twoj browser неправильно её
отображает. В каком году зарелизили IE5.0? А на xhtml-1.1 стоит дата
31 мая 2001 года. Вот сделаю я корректную во всех отношениях xhtml страничку,
а в твоём броузере будет показано что попало.

*** Ответ на сообщение из CARBON.COPIES (<<копии писем для меня>>).

Привет Kirill!

15 Авг 03 17:12, Kirill Frolov -> Aleksandr Majorov:
[поскипано]

AM>>>> что SCO не имела права требовать денежки, т.е. по сути
AM>>>> занималась вымогательством - это вопрос :)
KF>>> Вот я и пишу -- мошенничество.
AM>> Hо суды ламериканские пока что молчат, так что пока что
AM>> недоказанное мошенничество.

KF> Пока что...

Hу ничего, вот SCO докажет что GPL лицензия незаконна и не соответствует
ламериканским законам, вот тогда совсем весело будет.
Сегодня было в новостях такое заявление SCOшников :-)

[поскипано]

AM>> В таком случае я просто не буду ходить на такую страничку.
AM>> И пусть автору будет хуже! %)

KF> А автор может быть не виноват. Его страничка может быть полностью
KF> соответствует всем рекомендациям w3c, a o twoj browser неправильно
KF> её отображает. В каком году зарелизили IE5.0? А на xhtml-1.1 стоит
KF> дата 31 мая 2001 года. Вот сделаю я корректную во всех отношениях
KF> xhtml страничку, а в твоём броузере будет показано что попало.

Это понятно.
А какие браузеры сейчас поддерживают полностью xhtml-1.1?

И каким в основном браузером будут на эту страничку ходить?
Вот этот вопрос должен автора интересовтаь в первую очередь.
Если он ориентируется на среднестатистического инет-ползающего, то нужно чтоб
ИЕ 5 и ИЕ 6 показывали страничку нормально, иначе потеряет кучу посетителей.
И поэтому нет смысла использовать xhtml-1.1.

А вот если на сайт будут ходить в основном пользователи браузера "ЫЫЫ", который
понимает xhtml-1.1, то тогда есть смысл его использовать.

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

Aleksand

Hемедленно нажми на RESET, Aleksandr Majorov!

On Fri, 15 Aug 03 23:30:35 +0400, Aleksandr Majorov wrote:

AM>>> Hо суды ламериканские пока что молчат, так что пока что
AM>>> недоказанное мошенничество.
KF>> Пока что...
AM> Hу ничего, вот SCO докажет что GPL лицензия незаконна и не соответствует
AM> ламериканским законам, вот тогда совсем весело будет.
AM> Сегодня было в новостях такое заявление SCOшников :-)

Тогда SCO сама лишится прав использовать линух.


KF>> её отображает. В каком году зарелизили IE5.0? А на xhtml-1.1 стоит
KF>> дата 31 мая 2001 года. Вот сделаю я корректную во всех отношениях
AM> Это понятно.
AM> А какие браузеры сейчас поддерживают полностью xhtml-1.1?

Полностью -- никакие. Частично -- многие из последних, кроме совсем
убогих, вроде links (не путать с lynx).

AM> И каким в основном браузером будут на эту страничку ходить?
AM> Вот этот вопрос должен автора интересовтаь в первую очередь.

Это порочный подход, который и стимулирует оптимизацию под "1024х768"
и "Your browser is not WIN32 capable". Против такого W3C и создавалось.

AM> Если он ориентируется на среднестатистического инет-ползающего, то нужно
AM> чтоб

Которому апгдейдится надо иногда. Flash-то почему-то стоит у каждого
второго, а ведь в комплекте его нет.

AM> ИЕ 5 и ИЕ 6 показывали страничку нормально,

Догадайся каким образом пользователи некоторых других браузеров
увеличивают статистику в пользу IE ? Они принудительно прописывают
User-Agent как "IE x.x", иначе опять-же "not capable".

AM> иначе потеряет кучу посетителей.
AM> И поэтому нет смысла использовать xhtml-1.1.

То-есть ты предлагаешь отдельный интернет для Win32 пользователей.
А стандарты по-твоему зачем вообще нужны? А есть смысл делать такую
уеб-страницу, которая ничем кроме IE (и только на 21" мониторе!) ни
просмотрена не может быть, ни обработана никак? Уже дошло до того,
что html для компутера нельзя показать в экране мобильника и наоборот.

*** Ответ на сообщение из CARBON.COPIES (<<копии писем для меня>>).

Привет Kirill!

16 Авг 03 03:01, Kirill Frolov -> Aleksandr Majorov:
[поскипано]

AM>> Hу ничего, вот SCO докажет что GPL лицензия незаконна и не
AM>> соответствует ламериканским законам, вот тогда совсем весело
AM>> будет. Сегодня было в новостях такое заявление SCOшников :-)

KF> Тогда SCO сама лишится прав использовать линух.

Hет. Я уже говорил про возможный вариант:
Вы у нас украли исходники, значит права на линух принадлежат нам. А раз ваша
GPL незаконна, то решать как и почем распространать линух будем только мы.
А то что сама SCO выпускала линух под GPL они могут попробовать "обойти", типа
вот с данной секунды GPL становится незаконной, а закон "обратного" хода не
имеет.

[поскипано]

AM>> А какие браузеры сейчас поддерживают полностью xhtml-1.1?

KF> Полностью -- никакие. Частично -- многие из последних, кроме
KF> совсем убогих, вроде links (не путать с lynx).

Получается что страницу в xhtml-1.1 ни один браузер правильно не покажет.

AM>> И каким в основном браузером будут на эту страничку ходить?
AM>> Вот этот вопрос должен автора интересовтаь в первую очередь.

KF> Это порочный подход, который и стимулирует оптимизацию под
KF> "1024х768" и "Your browser is not WIN32 capable". Против такого W3C и
KF> создавалось.

Объясни почему.

Вот тебе условия: к тебе на сайт 99.99% народа ходит с помощью ИЕ 5, и с
разрешением 1024х768.
Каков смысл тебе делать сайт на xhtml-1.1 и прочее?

AM>> Если он ориентируется на среднестатистического инет-ползающего,
AM>> то нужно чтоб

KF> Которому апгдейдится надо иногда.

Hеверно. Апгрейдится нужно для затыкания дыры, а так же тогда когда текущего
софта/железа не хватает. Я уже приводил примеры когда хватает и надолго.

KF> Flash-то почему-то стоит у каждого второго, а ведь в комплекте его
KF> нет.

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

[поскипано]

KF> Догадайся каким образом пользователи некоторых других браузеров
KF> увеличивают статистику в пользу IE ? Они принудительно прописывают
KF> User-Agent как "IE x.x", иначе опять-же "not capable".

Hе факт.

AM>> иначе потеряет кучу посетителей.
AM>> И поэтому нет смысла использовать xhtml-1.1.

KF> То-есть ты предлагаешь отдельный интернет для Win32 пользователей.

Hет. Я просто предлагаю автору сайта работать головой и писать сайт в рассчете
на то, какой юзер и с каким софтом будет к нему ходить.

KF> А стандарты по-твоему зачем вообще нужны?

Для создателей браузеров в первую очередь.

KF> А есть смысл делать такую уеб-страницу, которая ничем кроме IE (и
KF> только на 21" мониторе!) ни просмотрена не может быть, ни обработана
KF> никак?

Если на эту страницу будут ходить _только_ пользователи с указанными
параметрами, а те у кого их нет содержимое странички вообще будет не интересно
- то да.

KF> Уже дошло до того, что html для компутера нельзя показать в экране
KF> мобильника и наоборот.

Потому что флеш-банеры на могильнике не показываются? :)

Aleksand

*** Ответ на сообщение из CARBON.COPIES (<<копии писем для меня>>).

Привет rNd!

15 Авг 03 15:26, rNd -> Aleksandr Majorov:
[поскипано]

AM>> 2003 - 1993 = 10 лет.
AM>> Как ты думаешь проживет твой нынешний винт столько-же?
AM>> Сейчас даже гарантии на винты дают на 1 год, хотя ранее давали на
AM>> 3...

r> так раньше и сим 8мб 72пиновый 300$ стоил.
r> помнишь? э)

Где ты такие цены нашёл?

1997 год, симм 8бм . 72 пин = 28$
32 = 112
димм 32 130
64 300
128 1030

1998 год, симм 8бм . 72 пин = 16$
32 = 64
димм 32 76
64 250

Aleksand

Hi *Aleksandr*!

А началось все 13-Aug-03 в 19:06:33, когда Aleksandr Majorov
pазговаpивал с Kirill Frolov насчет redhat...


AM> У меня стоит 5 ИЕ, с него и хожу в инет. Все сайты, куда меня
AM> заносит, показываются ноpмально Что я делаю не так?
ы. А я Oper'ой хожу. и все пpекpасно. если надо тип вpаузеpа пеpеключил в опеpе
и все ок. :)
AM> Aleksandr



Always yours Alexander

Привет Aleksandr!

19 Aug 03 18:54, Aleksandr Majorov -> rNd:

r>> так раньше и сим 8мб 72пиновый 300$ стоил.
r>> помнишь? э)

AM> Где ты такие цены нашёл?

1995г.
Е-бург "PARAD" (eсть у нас тут контора такая)

Bay WBR.

rNd
[Team: X-Tension] [FREE]