> ---
> Ядро Linux является единственным процессом, имеющим непосредственный доступ к
> аппаратуре все остальные процессы обращаются к устройствам только через ядро.
> ---
> Ну офигеть - первое же предложение, и наглая ложь!
> А как же Xorg? А dosemu? А svgalib? А <подставить нужное>

А как насчет того, что ядро процессом вообще не является?

> опус невозможно ни отредактировать

Я уже объяснял почему этот текст будет редактироваться одним человеком.

> ни diff прислать

А толку мне от вашего diff'а, если у ваша версия всегда не соответствует той, над которой я работаю в текущий момент? Кстати текущая версия от того что есть у вас отличается чуть не сотней исправлений.

> А каким раком Вам о них сообщать?

Указания раздела и фразы как правило достаточно.

no-dashi:

> Я так понимаю это R00T вернулся? :-)

:-) LoL!

Посмотри ИПшник!

> А как насчет того, что ядро процессом вообще не является?

И вообще линукс - это простоя ядро, и lvm/md/локали/x11 вообще не линукс, да?

> > Я так понимаю это R00T вернулся? :-)

> Посмотри ИПшник!

Да блин этих анонимусов развелось... Одни с МТС-GPRS, другие из ближнего.. И не очень :-) забугорья

no-dashi:

> Да брось ты - я не отказывался исправлять и признавать семантические ошибки, ...

Да, но ты аргессивно отвечаешь на нападки разных анонимусов, и все это создает несколько нездоровую атмосферу обсуждения. Иногда даже конструктивным критикам достается :-).

> ...а просто категорически отказался использовать TeX.

Опять же, очень агрессивно. Не все ли равно, в чем написана статья? А в результате скатились к обсуждению TeX vs. OO

Кстати, в качестве конструктивной критики:

>> А как насчет того, что ядро процессом вообще не является?

>И вообще линукс - это простоя ядро, и lvm/md/локали/x11 вообще не линукс, да?

А меня тоже это резануло -- первая же фраза какая-то странная... Каким образом ядро является процессом?

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

Насчет MBR -- конечно, мелкими буквами там все как надо написано, но то, что перед этим стоит крупными буквами, может ввести в заблуждение. Уверяю, как минимум половина читателей мелкие буковки пропустит. Я бы посоветовал вставить (в "крупные буквы") фразу типа "Несколько упрощенно процесс загрузки выглядит следующим образом."

> А толку мне от вашего diff'а, если у ваша версия всегда не соответствует
> той, над которой я работаю в текущий момент?

Вы слышали что-нибудь о системах контроля версий? Если нет, советую
ознакомиться. Начать можно с вот этого:

http://monotone.ca/docs/index.html
http://www.kernel.org/pub/software/scm/git/docs/core-tutorial.html

> Я уже объяснял почему этот текст будет редактироваться одним человеком.

Что ж, успехов в нелегком деле.

> Вы слышали что-нибудь о системах контроля версий?

Слышал. Использовал. И что?

> но ты аргессивно отвечаешь на нападки разных анонимусов

Они могут зарегистрироваться, и тогда каждый будет получать в точности свою дозу :-)

> и все это создает несколько нездоровую атмосферу обсуждения

Ну я еще никого не оскорбил кроме как сказав "не нравится - не ешь" :-)

> Не все ли равно, в чем написана статья?

Мне все равно. Я выбираю ODT поскольку это позволяет мне работать не задумываясь о всяких мелочах.

>> А как же Xorg? А dosemu? А svgalib? А <подставить нужное>
> А никак.
> 1. Если им нужен прямой доступ к памяти, они все mmap'ят
> соответствующий кусок. Посмотрите в код :-)
Давайте разговаривать по существу, а не о чём попало. :)
Было написано:
---
Ядро Linux является единственным процессом, имеющим непосредственный доступ к
аппаратуре – все остальные процессы обращаются к устройствам только через ядро.
---
Про память вообще не слова, так что не надо её и приплетать. :)

> 2. Если (как например Xorg) им нужно работать с портами ввода-вывода
Им всем, что я указал, нужны порты (в том числе).

> они это могут делать только с разрешения ядра и после вызова ioperm().
Разрешение разрешением (могут и iopl() воспользоваться), а
обращаются они к портам напрямую. Используя низкоуровневые
команды ввода/вывода (in/out, прямо на асме, если что), а
никак не функции ядра.

> Будем считать инцидент исчерпаным?
Возвращаю этот вопрос вам.

> Не все ли равно, в чем написана статья? А в результате скатились к
> обсуждению TeX vs. OO

Конечно же не все равно. С текстовым файлом работать гораздо удобнее, чем
с [sensored] бинарником (Вам объяснять почему?), особенно если работает
не один человек, а несколько. Ломать глаза об кривой PDF'ник (горячий привет
шрифтам) -- тоже радости немного.

> Там есть приписочка мелким текстом, что это делает процессор и MMU.
> Может вы просто невнимаетльно прочли?
Я читаю PDF версию и приписочку в упор не вижу.
Она там есть, или я должен с odt геморроиться?

> А как насчет того, что ядро процессом вообще не является?
Да трудно сказать. Какая-то часть конечно не является
(не может же быть процессом, например, планировщик),
но вот сейчас смотрю ps, и вижу всякие migration/0,
ksoftirqd/0, watchdog/0, events/0, khelper, kthread
и ещё десятка два аналогичных процессов. Так шта...

> А толку мне от вашего diff'а, если у ваша версия всегда не соответствует
> той, над которой я работаю в текущий момент?

> > Вы слышали что-нибудь о системах контроля версий?

> Слышал. Использовал. И что?

mount /dev/brain

> Ворд не знает НИЧЕГО про полиграфию

Довожу до сведения маленьких неразумных детей, что ворд прекрасно знает и про мягкие переносы, и про неразрывные дефисы, и про пробелы разной величины, и про способы убийства orphan/widow-строк и про многое-многое другое. При желании и умении, а также большом запасе нервов в ворде вполне можно делать пристойно выглядящие документы. Другое дело, что в индизах, кварках и прочем софте такого класса это делается гораздо проще.

За песочком, родной, шагоооом марш! :)))

>> Это давно уже не так. Оверкоммит запретили сто лет в обед.
> Нет - overcommit _отключаем_ но не запрещен.
Запрещён по умолчанию, во всех дистрах.
Он именно запрещён, а не отключён (но это - словистика),
хотя возможность его разрешить, безспорно, есть.
Это сути дела не меняет. Вы пишете: "возможны два возможных
варианта...", а реально эти варианты во всех современных
дистрах как раз таки и не возможны, а возможен тот, который
у вас и не описан. Зачем так делать то? Так можно и про
ipchains или ipfw написать, а про iptables забыть...

> Да трудно сказать. Какая-то часть конечно не является
> (не может же быть процессом, например, планировщик),
> но вот сейчас смотрю ps, и вижу всякие migration/0,
> ksoftirqd/0, watchdog/0, events/0, khelper, kthread
> и ещё десятка два аналогичных процессов. Так шта...

Это не процессы -- это [ядерные] потоки.

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

Да, точно как и зубы рвать через задний проход...

Ну так я и не говорю, что тексты в ворде писать очень клёво. Будь моя воля, я бы всю компанию пересадил, скажем, на LyX :) Но поскольку это нереально, приходится делать лимонад из лимона :)

> Это не процессы -- это [ядерные] потоки.
Скажите это ps'у, который показывает их именно
как процессы.
С точки зрения ядра - это триды (все в одном mm-context
сидят), но с точки зрения юзерспейса - у каждого свой
pid, как я понимаю.

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

"Запас нервов" - ключевое слово :) На самом деле самая большая проблема всех современных wysiwyg-редакторов(не считая того, что глупо текстовый редактор в такой мере завязывать на работу с мышью) - они не принуждают пользователя вкусности, в них имеющиеся, использовать, одновременно позволяя всё. В результате имеем обычные творения, глядя на которые сразу восклицаешь "ба, да это же ворд!" :)

В man iptables этого нет - нужно дать человеку понимание того, для чего и какие нужны инструменты, а уж маны дадут понятие, что и как можно сделать этими инструментами.

Академические изыскания (пусть и завязанные на какие-то конкретные понятия) без привязки к инженерной практике - не лучший способ изучения операционной системы.

Да мышь тут вообще ни при чём (как раз таки мышь в ворде бывает очень полезна). Основная проблема ворда состоит в том, что он позволяет неопытному пользователю, фигурально выражаясь, отстрелить себе ногу. Разгребать мешанину стилей в присланном документе за два часа до подачи заявки на тендер -- врагу не пожелаешь :)

Эти "триды" -- различные процессы, выполняющиеся целиком в контексте ядра. Теоретически их могло и не быть. А когда мой процесс выполняет сисколл и уходит в ядро, он что, ядром становится?

Ну, спор терминологический, но называть ядро процессом ИМХО некорректно.

> А когда мой процесс выполняет сисколл и уходит в ядро, он что,
> ядром становится?
Ващет да, пример убедительный. :)

> Ну, спор терминологический, но называть ядро процессом ИМХО
> некорректно.
Согласен, уболтал. :)

Не согласен. Я вот в помощи от OO writer так и не нашёл шортката для смены начертания шрифта. В 10 раз снимая руку с клавиатуры и ползя к мыши ради такой мелочи, волком взвоешь. :)

> На нижнем уровне прикладные процессы могут обратиться к функциям ядра
> посредством системных вызовов (syscall). Фактически syscall это вызов
> прерывания 80h с установленными параметрами, описывающими параметры для
> этого системного вызова.

Верно только для древних x86 процессоров (<= Pentium I) и старых (<= 2.2.X ?)
ядер. Более новые ядра на более новом железе используют SYSENTER/SYSEXIT.
Более подробное описание см. в "Intel 64 and IA-32 Architectures Software
Developers Manual", а также linux-2.6.20/arch/i386/kernel/entry.S:282

И ещё чего сказать забыл: написано, что сисколы
через int80h делаются, однако ж это опять таки,
сто лет уже не так (sysenter/sysreturn)

> Я вот в помощи от OO writer так и не нашёл шортката для смены начертания шрифта

Ctrl + I, Ctrl + B? И зачем вам менять начертания? У вас вроде же все на стилях построено?

Тьфу, опередили... :(

> но с точки зрения юзерспейса - у каждого свой pid, как я понимаю.

Это просто хак/историческая несуразность (что у ядерных потоков вообще
есть pid). Была в свое время и другая несуразность того же рода.
В linuxthreads у каждого _нормального_ потока был свой pid, и ps показывал
потоки одного процесса как разные процессы...

> Скажите это ps'у, который показывает их именно как процессы.

Точка зрения "есть pid, значит, процесс" -- немножко глуповатая, ну а
с другой стороны -- а что ему остается делать?

> Будь моя воля, я бы всю компанию пересадил, скажем, на LyX :)
> Но поскольку это нереально,

Да уж, тут одного упрямца (к тому же "не идиота") попробуй заставить
освоить TeX, а если их 1000 -- это ж караул :(

А не надо заставлять. Насилие не рулит :)

>Ctrl + I, Ctrl + B

O!

>И зачем вам менять начертания? У вас вроде же все на стилях построено?

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

Символьные стили в ОО.о вроде не отменяли ;-)

Просто в OO документация очень хорошая - искать шорткаты легко и приятно :)

респект!!!Хочу к вам пойти учиться,вы же препод насколько я понял?

> Более новые ядра на более новом железе используют SYSENTER/SYSEXIT.

Ок, попытаюсь учесть.

> Она там есть, или я должен с odt геморроиться?

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

> попробуй заставить освоить TeX

Заставлять не имеет смысла. Я работал с техом в свое время, еще в 1997-м году. И выбрал вполне себе OOO осознано.

Смотри поставят тебе вместо оценки пункт 4.2, например =)

Точно. Убери 2 восьмерки и можешь ставить линукс.

> Будь моя воля, я бы всю компанию пересадил, скажем, на LyX :)

Оооо, либо я чего-то не так понял ранее, либо чего-то я пропустил, но такое ощущение, что кое-кто стал приглядываться к LaTeX? Гхмм, и как впечатление?

> Не согласен. Я вот в помощи от OO writer так и не нашёл шортката для смены начертания шрифта. В 10 раз снимая руку с клавиатуры и ползя к мыши ради такой мелочи, волком взвоешь. :)

Гхмм, а сделать его самому религия не позволяет?

> И выбрал вполне себе OOO осознано.

Собственно говоря, всегда можно выбрать обратно. Могу помочь более-менее быстро перегнать.

P.S. Текст _пока_ не читал.

> Позволь угадаю... KPDF? Поскольку вот в Evince работает, могу посоветовать только сменить среду... Ну или смотрелку

"Болит голова? Позволь угада... вчера пил? Советую отрубить ее и заменить на что-нибудь простое и без мозгов, чтобы не болели, на что-то вроде Гнома."

>а "геека" буду отрывать йайца вне зависимости от звёздности и анонимности :)

Правда глаза колит? ;)

Про осознанный выбор

> Я работал с техом в свое время, еще в 1997-м году. И выбрал вполне себе
> OOO осознано.

http://aftergrogblog.blogs.com/agb/images/Cat_Hat.jpg

> Наиболее часто используются сетевые файловые системы NCPFS (для доступа
> к серверам Novell NetWare),

Наиболее часто используемая? Шухер! Некрофилы в городе!

> SMBFS (для доступа к серверам Windows)

"сервер Windows" -- спасибо за 5 минут здорового смеха.

> и NFS (для доступа к файловым системам других UNIX-систем).

> для NFS мы указываем таймаут, по истечении которого операция ввода/вывода
> считается неудавшейся.

Сразу две ошибки.

1. Параметра "timeout" не существует.

$ apt-get source nfs-utils
[apt честно скачивает исходники]
$ grep -nr nfs-utils-1.0.10 -e '\"timeout\"'

[пусто, то есть нет такого параметра]

Есть параметр "timeo", который показывает, через сколько _десятых_ долей
секунды следует повторить RPC после истечения RPC timeout.

2. Операция ввода-вывода в NFS завершается ошибкой (-EIO), если
а) ФС смонтирована с параметром "soft"
б) RPC был повторен "retrans" раз, но ответ сервера так и не пришел.

Если ФС смонтирована с параметром "hard", то клиент будет повторять
попытки до просветления, или пока не убьют процесс (что возможно, только
если ФС смонтирована с параметром "intr")