Столяров все-таки закостеневший и самовлюбленный

Сможешь приволочь столярова подебатировать - будет интересно

О чем с ним дебатить? Столяров - препод, его работа объяснять определения, он их и объясняет. К объяснениям определений от Столярова у меня претензий нет. Он объясняет блестяще.

Когда он начал гнать про современные технолгии, я написал достаточно критическое ревью на его философию. Пост окол месяца был на 1 месте в топе на LOR.

Препод хороший, но не разработчик. Всех предупредили.

Столяров разбирается и в программировании и в математики.

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

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

По его коду видно, что у него каша в голове. По книгам, собственно, тоже.

Такого форм фактора по системным вызовам и теории ОС я не встречал.

Само по себе это бесполезно и не позволяет разобраться в вопросе. Даже старта не дает. Это именно что учебное пособие, которое должно идти в комплекте с лектором, который может разжевать и в рот положить. Без этого это всего лишь набор терминов и фактов, непонятно как связанных друг с другом.

Весь путь по всем вышеописанным авторам лучше начинать с методички Столярова.

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

Начинать нужно с хороших книг типа Танненбаума, потому что он и объяснять умеет, и предметом владеет получше столярова.

О чем с ним дебатить? Это препод, его работа объяснять определения, он их и объясняет.

Часть из них при этом он выдумывает.

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

Одно слово - клоун.

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

Да, Столяров замечательный, он написал 200 страниц которые вводят в курс дела. У него получилось удачно.

без которых любые западные книги лучше не начинать. А западные-то авторы и не в курсе.

Можно прекрасно обходиться и без методички Столярова. Но с ней удобней и быстрей.

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

Она не нужна, потому что не дает никаких основ, только термины и общие слова. После нее все равно придется изучать всё перечисленное глубже, поэтому лучше сразу начинать нормальные книги. Надо программировать? Прата. Надо ОС? Танненбаум.

Она не нужна, потому что не дает никаких основ, только термины и общие слова.

Кхм, у меня другое мнение, которое я уже подкреплял цитатами и примерами.

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

Системному программисту придется. Программисту приложений теоретического базиса методички Столярова вполне достаточно.

Надо ОС? Танненбаум.

1031 одна страница, у Столярова 200. Это книги разного типа.

Она не нужна, потому что не дает никаких основ, только термины и общие слова. После нее все равно придется изучать всё перечисленное глубже, поэтому лучше сразу начинать нормальные книги. Надо программировать? Прата. Надо ОС? Танненбаум.

Стоп. Стоп. Стоп. Вообще я методичку Столярова ни кому не противопоставляю. И описываю ее как хорошее начало, которое дает общие представления о всём UNIX.

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

Кхм, у меня другое мнение, которое я уже подкреплял цитатами и примерами.

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

1031 одна страница, у Столярова 200. Это книги разного типа.

Да. Еще раз: столяровский опус не является самостоятельным произведением и предназначен быть конспектом для тех, кто посещает лекции, гед эта же информация подается более подробно (должна, по крайней мере).

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

Поэтому я и говорю: его методичка несамостоятельна, и для нормальных книг избыточна.

И описываю ее как хорошее начало, которое дает общие представления о всём UNIX.

Нет. Но мне уже насрать. Оставайся наедине со своими заблуждениями, если не хочешь вникать в то, что я пишу.

Нет. Но мне уже насрать. Оставайся наедине со своими заблуждениями.

Чем вы от Столярова в своей непримиримой риторике отличаетесь? Точно такая-же однозначная позиция без полутонов.

Вот типичное объяснение редиректов в книгах по Linux, и вот часть краткого объясенения у Столярова.

По моему наглядно показано, что Столяров хорошо объясняет, ухватывает суть.

Ты принес пример про перенаправления, и я вижу, что он плохой и непонятный. В таком виде эта информация носит лишь справочный характер.

Преподнесена часть примера.

В методичке про редиректы 2 страницы, я перепечатал только одну таблицу. В параграфе всё чётко изложено, а если все 200 страниц прочитать, то еще более детализировао, так как там показана схема перенарпавления файловых дескрипторов при наботе с неименоваными каналами (19.1).

Танненбаумовская же книжка по осям заменяет преподавателя и предназначена для самостоятельного изучения, отсюда и объем.

Уникальность методички в ее размере.

Поэтому я и говорю: его методичка несамостоятельна, и для нормальных книг избыточна.

Это не так.

Чем вы от Столярова в своей непримиримой риторике отличаетесь? Точно такая-же однозначная позиция без полутонов.

Тем, что я аргументирую свою позицию.

Вот типичное объяснение редиректов в книгах по Linux

Это не книга, а туториал-памятка.

По моему наглядно показано, что Столяров хорошо объясняет, ухватывает суть.

Нет.

Суть в том, что нужно объяснить, ЗАЧЕМ существуют стандартные потоки. И если с вводом/выводом всё более-менее легко объяснить, то с потоком ошибок у людей созникают возникают вопросы.

Нужно сказать, что стандартный вывод ошибок - это не только про ошибки. Если программа выдает какой-то значимый вывод на экран, сопровождая его комментариями (логом), то первое должно отправляться на stdout, а второе - на stderr, то есть, в stderr падают любые подробности работы программы, не являющиеся данными, которые следует далее обработать в пайплайне. Отличный пример здесь - find /, которая рекурсивно выведет содержимое всего корня, сопроводив это кучей сообщений об ошибках. Дальше можно рассмотреть обработку вывода find по пайплайну и логгирование ошибок.

Это не так.

Это так.

liksys, перепечатаю весь параграф 10.4, отдам на суд читателей нашего спора. Пусть сравнят изложение Столярова, и изложение из книги Osamu Aoki или Shotts W. E..

И так, А. В. Столяров Введение в операционные системы:

10.4 Перенаправления ввода-вывода

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

Осуществляя обмен данными через стандартные потоки, большинство программ не делает предположений о том, с чем на самом деле связан тот или иной поток. Это позволяет использовать одни и те же программы как для работы с терминалом, так и для чтения и/или записи в файл.

Командные интерпретаторы, в том числе классический Bourne Shell, предоставляют возможности для управление вводом-выводом запускаемых программ. Для этого используются символы <, >, >>, >& и | (см. таблицу 2).

Таблица 2: Примеры перенаправлений ввода-вывода:

Обычно в ОС Unix присутствует программа less, позволяющая постранично просматриать содержимое файлов, пользуясь клавишами «Стрелака вверх» «Стрелка Вниз» PgUP, PgDn и др. для прокрутки. Эта же программа позволяет постнанично просматирвать текст, поданный ей на стандартый ввод. Использование программы less полезно в случае, если информация, выдаваемая какой-либо из запускаемых вами программ, не умещается на экран.

Например, комманда.

ls -lR | less

Позволит вам ппосмотреть список всех файлов, находящихся в текущей директории и всех ее поддиректориях.

Пусть читатели форума сами решат, понятно или непонятно объясняет Столяров, и достаточно ли объяснений в методичке.

Нужно сказать, что стандартный вывод ошибок - это не только про ошибки. Если программа выдает какой-то значимый вывод на экран, сопровождая его комментариями (логом), то первое должно отправляться на stdout, а второе - на stderr, то есть, в stderr падают любые подробности работы программы, не являющиеся данными, которые следует далее обработать в пайплайне. Отличный пример здесь - find /, которая рекурсивно выведет содержимое всего корня, сопроводив это кучей сообщений об ошибках. Дальше можно рассмотреть обработку вывода find по пайплайну и логгирование ошибок.

Очень хороший текст. Но вне контекста. Параграф 10.4 не о написании программ, а о их использовании с позиции пользователя.

Параграф 10 начинается со слов.

Попытаемcя дать краткое представление о Unix в надежде, что это
позволит читателю провести самостоятельные эксперементы с какой-либо
Unix подобной операционной системой.

Очень хороший текст. Но вне контекста. Параграф 10.4 не о написании программ, а о их использовании с позиции пользователя.

Это как раз с позиции пользователя. Пользователь должен понимать, что такое stderr.

это позволит читателю провести самостоятельные эксперементы

Прочитай рассказ «Логика» Азимова.

Нужно сказать, что стандартный вывод ошибок - это не только про ошибки. Если программа выдает какой-то значимый вывод на экран, сопровождая его комментариями (логом), то первое должно отправляться на stdout, а второе - на stderr, то есть, в stderr падают любые подробности работы программы, не являющиеся данными, которые следует далее обработать в пайплайне.

Параграф 10.4 не о написании программ, а о их использовании с позиции пользователя.

Это как раз с позиции пользователя. Пользователь должен понимать, что такое stderr.

Вот цитата из книги Shotts W. E. Jr. «The Linux Command Line - A Complete Introduction»

Глава 6 Redirection

Standard Input, Output, and Error

Many of the programs that we have used so far produce output of some kind. This output often consists of two types. First, we have the program’s results; that is, the data the program is designed to produce. Second, we have status and error messages that tell us how the program is getting along. If we look at a command like ls, we can see that it displays its results and its error messages on the screen.

Keeping with the Unix theme of “everything is a file,” programs such as ls actually send their results to a special file called standard output (often expressed as stdout) and their status messages to another file called standard error (stderr). By default, both standard output and standard error are linked to the screen and not saved into a disk file.

In addition, many programs take input from a facility called standard input (stdin), which is, by default, attached to the keyboard.

I/O redirection allows us to change where output goes and where input comes from. Normally, output goes to the screen and input comes from the keyboard, but with I/O redirection we can change that.

Вот подобный текст с примерами с 50 по 54 страницу.

[me@linuxbox ~]$ ls -l /usr/bin > ls-output.txt
[me@linuxbox ~]$ ls -l ls-output.txt
-rw-rw-r-- 1 me me 167878 2012-02-01 15:07 ls-output.txt
#...
[me@linuxbox ~]$ ls -l /usr/bin >> ls-output.txt
#...
[me@linuxbox ~]$ ls -l /bin/usr 2> ls-error.txt
[me@linuxbox ~]$ ls -l /bin/usr > ls-output.txt 2>&1
#...
[me@linuxbox ~]$ ls -l /bin/usr &> ls-output.txt
#...
[me@linuxbox ~]$ ls -l /bin/usr 2> /dev/null
#...
[me@linuxbox ~]$ cat ls-output.txt
[me@linuxbox ~]$ cat movie.mpeg.0* > movie.mpeg
# ... cat with no arguments?
[me@linuxbox ~]$ cat

Отличная книга, тоже всем рекомендую.

В ней примеры Bash Brace Expansions:

[me@linuxbox ~]$ mkdir -p playground/dir-{00{1..9},0{10..99},100}
[me@linuxbox ~]$ touch playground/dir-{00{1..9},0{10..99},100}/file-{A..Z}

Отличные!

Это как раз с позиции пользователя. Пользователь должен понимать, что такое stderr.

☕️🍰

Справедливое замечание, в книге William Shotts упоминается, что stderr используется для логирования и диагностики.

Second, we have status and error messages that tell us how the program is getting along.

На RubyOnRails аналог Thalassa пишется за пол дня.

А кто будет создавать «RubyOnRails-ы» тогда?! И вы гарантируете, что в RubyOnRails где-то когда-то не было такого же «угара» и «содомии», что в изделии Столярова?

Программист не тот, кто умеет создавать GUI на GTK, Qt или Tk, а кто может, но не делает того без крайней необходимости, создать xlib, на основе которой создать условный xTkLib, на основе которого уже создавать GUI.

И все-таки я повторю свой вопрос из удаленных

относительно магнитофона Полковника: похож ли Кроко на Полковника (из ЗС) и пойдет ли он на парад, где будет салют в его честь?

Судя по поведению и прическам, очень похож)

А это ЛОРовские обсуждения.

https://www.youtube.com/watch?v=o6Y9t-Mu9mA