Архив гостевой книги с 04.07.2019 по 03.11.2020Эта страница гостевой книги является архивной. Новые комментарии просьба оставлять в действующей гостевой книге. Ответы на старые комментарии здесь по-прежнему возможны. Учтите, что комментарии на этом сайте премодерируются. 
|
пояснениеВы находитесь на официальном сайте Андрея Викторовича Столярова, автора учебных пособий по программированию и информационным технологиям. Если вы искали сайт замечательного писателя-фантаста Андрея Михайловича Столярова, то вам, к сожалению, не сюда. Андрей Михайлович Столяров в библиотеке Мошковаваш сеанс |
☞ From Anonymous (unverified) Wed Nov 4 16:33:00 2020 UTC
В той задаче
В той задаче про кубики. Немного изменим входные параметры, кубиков пусть будет 5., башня у Димана имеет высоту от 1 до 5 кубиков. сколько башен можно построить из имеющихся кубиков по одной за раз.
а) Строим 5-этажные башни: 1 этаж башни можно построить 5 способами, 2 этаж - 4 способами, 3 этаж - соответственно 3-мя, 2-ой - двумя, 1-ый этаж тем что осталось от каждого способа - одним. В итоге 5! = 5*4*3*2*1 = 120;
б) Строим 4-этажные башни: тоже самое 5!, т.к. построив 120-ю способами 5-этажную башню и сняв один кубик, ничего не меняется.
в) Строим 3-этажные башни: первый этаж строим 5-ю способами, второй 4-мя способами, 3 этаж строим 3-мя способами;
7) Строим 2-этажную башню: Первый этаж строим 5-ю способами, второй 4-мя;
8) 1 этажная башня строиться 5-ю способами.
В итоге получается (5*4*3*2*1)+(5*4*3*2*1)+(5*4*3)+(5*4)+5=120+120+60+20+5=325
Вопросы:
1. Правильно ли я решил задачу?
2. Верное ли рассуждение?
3. При постройке 3-х этажных башен, хотел понять, получиться ли и тут схитрить, сняв с 5-этажной башни вместо одного - 2 кубика, прорисовав комбинации, понял что будут совпадения. Как другим способом понять что сняв 2 кубика с 5 этажной башни - решение будет не правильным?
С Уважением, Александр
ответить
Ну да, всё
Ну да, всё верно. Там же в тексте ответ есть, у вас он сошёлся.
Вот только я совершенно не понимаю, что такое "сняв 2 кубика с 5 этажной башни - решение будет неправильным". Смотря как снимать. Два кубика (какие бы они ни были) -- это две комбинации (один на другом, или наоборот). Следовательно, когда сначала было сколько-то башен из пяти кубиков, а потом мы два сняли -- каждые две башни (до этого момента разные) станут одинаковыми. То есть нужно то, что было, поделить на два. Что мы и имеем: если 120 пополам поделить, то получится 60, и это верно -- действительно башен из трёх кубиков 60.
P.S. Ну вот зачем в архивную страницу-то оставлять комментарий? Тут их и так 500 с лишним, зря я, что-ли, гостевую очистил
ответить
☞ From Anonymous (unverified) Thu Oct 29 04:46:00 2020 UTC
Насчёт машины Тьюринга
Есть такой язык brainfuck. Там всего восемь операций: ,.+-<>[] и некоторое количество ячеек памяти с числами от 0 до 255, закольцованными по модулю 256.
Вот мне интересно, а является ли эта штука частным случаем машины Тьюринга? Вроде как и простая для понимания система и при этом достаточно компактная.
>> Известны довольно компактные реализации УМТ, но их достаточно тяжело понять; сложность там вытеснена в нотацию: чтобы воспользоваться компактной реализацией УМТ <<
ответить
является ли эта
является ли эта штука частным случаем машины Тьюринга?
С таким же успехом можно спросить, является ли лопата частным случаем бинокля.
ответить
BF полон по
BF полон по Тьюрингу; более того, относится к т.н. "тьюринговским трясинам", которые, несмотря на полноту, синтаксически скудны настолько, что ничего реально полезного на них сотворить практически невозможно. Больше этот язык с фамилией Тьюринга ничего не связывает.
ответить
А зачем на
А зачем на машине Тьюринга "творить полезное"? Она ведь изначально не для этого, машина Тьюринга — это математический объект, строго с математической точки зрения определённый, он и предназначен для использования в математике — при доказательстве всяких теорем в теориях вычислимости и алгоритмов. Такой формализм просто-таки обязан быть крайне примитивным, если он будет сложнее — доказать ничего не получится, все доказательства станут такими, что их человек не сможет проследить. Но при этом делать формализм ещё примитивнее не получается уже по другой причине: будет непонятно, как на этом сделать не то что "что-то полезное", а вообще хоть что-то. Известно, что rule_110 алгоритмически полон, это доказано, но КАК на нём хотя бы двоичное число на единицу увеличить?! На МТ мы хоть что-то можем сделать, убедить себя, что это возможно, а на rule_110 фигушки. То есть МТ — это компромисс между сложностью записи и сложностью доказательств.
Так или иначе, МТ — вообще не про программирование, это про математику.
ответить
Речь была не о
Речь была не о МТ, а о Brainfuck - языке программирования. Синтаксически он крайне беден, поэтому "творить полезное", т.е. программировать что-то осмысленное на нем, крайне сложно.
ответить
Тогда ладно
Меня несколько смутили эти ваши "тьюринговские трясины".
ответить
Ясно-понятно,
Ясно-понятно, как говаривал наш преподаватель по вышмату. Оставлю это здесь, вдруг кому-то будет интересно.
ответить
☞ From Anonymous (unverified) Wed Oct 28 07:33:00 2020 UTC
Прочитал в
Прочитал в четвёртом томе вот такую фразу:
Символьные литералы вроде ’a’ или ’7’ в Си++ считаются константами типа char, тогда как в чистом Си они считались константами типа int.
Захотел проверить на практике, написал код типа такого:
Исходник сохранил в кодировке KOI8-R, чтобы между ' ' был один байт и скомпилировал с помощью gcc и g++. В обоих случаях у меня получилось -39.
Если же сохранять в UTF-8, то всё вообще довольно странно и вылезает Warning. Но это и понятно, так как между '' не предполагается наличие более чем одного байта, если нет префикса типа L, u или U.
Так почему -39 мне не понятно. Если 'ы' имеет тип int и переменная a имеет тот же тип, то вроде как 217 должно было получиться, так как int как минимум 16 бит, а 217 меньше, чем 32768, значит переполнение знакового типа вызвать не может и печататься должно в виде положительного числа даже через %d.
Так что, мне не понятно, в чём тут разница, если в любом случае молча происходит преобразование из signed char (число от -128 до 127) в тот тип, который объявлен у переменной a и вывод обоих программ одинаковый.
ответить
Во-первых, и
Во-первых, и в-главных, никакие символы, не входящие в ASCII, не должны появляться в тексте программы — никакие, никогда, ни при каких условиях, даже в комментариях, а уж в литералах — тем более. Комментировать вашу околокодировочную ахинею я смысла не вижу,там всё довольно очевидно, но если для вас не очевидно — то какого чёрта вы пытаетесь изучать Си++? Ах да, на всякий случай: в gcc тип char по умолчанию знаковый. Если всё ещё неясно, почему получилось -39, то, видимо, вам вообще не стоит программировать.
Что касается типа константы, то разница демонстрируется вот таким кодом (естественно, это Си++, в чистом Си нет перегрузки функций):
#include <stdio.h> void pr(char c) { printf("CHAR %d\n", c); } void pr(int i) { printf("INT %d\n", i); } int main() { pr('1'); pr(49); return 0; }Эта штука печатает
Между прочим, вы, случайно, не тот же персонаж, который, например, вот этот коммент http://www.stolyarov.info/guestbook#comment-2855 оставлял? Если вдруг да (а по стилю похоже), что что было непонятно в моём ответе?
ответить
К делу не
К делу не относится, просто вспомнил. Как-то лектор (лекция по Си++) спросил у потока, что такое перегрузка функций, весь поток молчал (а мне говорить не хотелось). Затем он сказал: как это вы не знаете, в Си тоже есть перегрузка, как же вы Си изучали в прошлом семестре? Ну, я парировал ему, что в Си нет перегрузки функций. А лектор мне ответил: в Си11 есть. Я аж в шок впал от такого ответа
ответить
Вообще-то нету.
Вообще-то нету. Там есть некое странное слово _Generic, с помощью которого можно что-то вроде этого сотворить (вот тут, например: https://stackoverflow.com/questions/479207/how-to-achieve-function-overloading-in-c см. второй ответ, не первый), но это явно не такая техника, которую часто применяют (если вообще применяют), и уж точно не такая, которую рассказывают студентам. Подозреваю, что лектор не был знаком с предметом, просто слышал об этом что-то там.
ответить
☞ From Anonymous (unverified) Tue Oct 27 13:40:00 2020 UTC
Свой почтовый сервер
АВ, добрый день.
Могли бы посоветовать по вопросу организации своего личного почтового сервера? А именно:
1)Что выбрать: VDS/VPS/свое железо с белым ip?
2)Какой софт порекомендуете, чтобы не слишком сложно в настройках и было бы безопасно? Есть ли по рекомендуемому вами продукту подробные описания, чтобы все грамотно настроить?
3)У какого регистратора лучше купить домен (отечественный, зарубежный)? Если доверяете кому-то из зарубежных назовите.
Спасибо.
ответить
Именно для почты?
1) однозначно VPS, причём самого-самого начального, слабенького, еле живого уровня -- оно дешевле, а для почты никакие практически ресурсы не нужны, она не жрёт ничего; и без всяких plesk'ов и прочих "пультов управления", справитесь командной строкой. Из примочек разве что backup взять, если он в базовую стоимость не входит.
2) я всегда использую postfix, он прост как валенок и надёжен как шар из чугуна
3) от доменов .su и .ru держитесь подальше, ну а .рф вообще не стоит рассматривать, почта на такие не ходила, не ходит и ходить не будет; что до регистраторов (естественно, тоже исключительно зарубежных, про российских даже и не думайте) -- я в последнее время много их перебрал, и у всех свои "приколы", приличных среди них нет вообще, либо у них сайт макаки писали, либо спамят, либо дорогие слишком, ну в общем все какие-то мерзкие. Нормальных я не видел. Точнее, когда-то видел, но они скурвились давно. Но, к счастью, с этими козлами дела иметь приходится не так уж часто.
ответить
Хоть не я
Хоть не я спрашивал, тем не менее, спасибо за ответ! Тоже задумался о своей почте
ответить
А что насчёт
А что насчёт VPS-провайдеров: каким стоит доверять (зарубежным, российским), каким -- нет?
Возможно, всё же ответ очевидный -- никаким, ведь в теории (и, скорее всего, на практике)
они могут слить любую информацию, в том числе и переписку, хранящуюся на сервере.
ответить
А не надо
А не надо хранить переписку на сервере.
Российские провайдеры все как один оверпрайснутые, причём они даже в этом не виноваты, виновата российская действительность: здесь объективно невозможно предоставлять дешёвый VPS-сервис. Плюс к тому здесь дяди в погонах совершенно охреневшие от собственной вседозволенности. "Там", конечно, дяди в погонах тоже есть, но вопрос, которых из них вот лично вы интересуете больше — "тех" или "наших" (последнее в очень жирных кавычках), можно считать риторическим.
А доверять — ну да, никаким нельзя. Строго говоря. Вопрос в балансе между ущербом от возможного "слива" и вероятностью оного слива, каковую стоит прикидывать с учётом технических сложностей. Если на сервере будет только почтовая очередь и никакого хранения (получил — стёр), то технически довольно трудно это всё писать в архив, то есть можно, но делать это для всех имеющихся VPS'ок проще сразу застрелиться. Следовательно, всё, конечно, сольют, но только если "тамошние" дяди в погонах заинтересуются лично вами.
В любом случае "бесплатные почты", которыми сейчас пользуется каждый первый, не просто не гарантируют приватности, они, я бы сказал, гарантируют её отсутствие.
ответить
"Там", конечно,
"Там", конечно, дяди в погонах тоже есть, но вопрос, которых из них вот лично вы интересуете больше — "тех" или "наших" (последнее в очень жирных кавычках), можно считать риторическим.
Как мне кажется, американских дядей в погонах интересуют все и везде, ведь в этом и есть суть массовой слежки: шпионить не конкретным человеком, а за всеми сразу, так, на всякий случай, даже если конкретный человек на данный момент никакого интереса не представляет.
Вообще, как показывает действительность, Google, Facebook и прочие заинтересованы в получении персональной информации не меньше, чем спецслужбы.
ответить
американских
американских дядей в погонах интересуют все и везде
Ну, это, как мы понимаем, не только американских. Проблема в том, что в случае VPS "хранить всё" сопряжено с объективными техническими трудностями, это же нужно то и дело снимать копию всего дискового пространства VPSки (ну, пусть даже инкрементально) и куда-то складывать. А VPS'ок этих у крупных хостеров — десятки тысяч по меньшей мере.
Поэтому в случае VPS нужно (чтобы что-то начали с неё тянуть) именно что персонально заинтересовать собой "кого надо".
Google, Facebook и прочие заинтересованы в получении персональной информации не меньше, чем спецслужбы.
А вы думаете, что их корректно сравнивать со спецслужбами? Точнее, даже не так: их, по-вашему, нужно рассматривать отдельно от спецслужб? :-)
ответить
DeGoogle
их, по-вашему, нужно рассматривать отдельно от спецслужб? :-)
Разумеется, нет, их нельзя рассматривать отдельно от спецслужб, но всё-таки у них есть и свои сугубо коммерческие интересы. Им же нужно как-то показывать таргетированную рекламу, чтобы продолжать существовать.
ответить
☞ From Anonymous (unverified) Tue Oct 27 02:24:00 2020 UTC
>> Только
>> Только по-моему это пример, когда придумали какую-то фигню.
> Вообще-то это скорее про весь Юникод. И вообще про любое комитетское поделье.
А что насчёт ASCII? Тоже ведь результат работы комитета по унификации разных кодировок используемых зоопарком существовавших на тот момент телетайпов. Тоже фигня?
---
А вообще, Unicode как таковой — это всего лишь таблица, ставящая в соответствие каждому когда-либо придуманному графическому символу в соответствие некоторое число, плюс набор стандартов по тому, как эти числа закодировать в двоичном коде.
По сути ASCII — то же самое: таблица 128 кодов и соответствующих им знаков или управляющих действий.
Просто в Unicode больше кодов и больше знаков и действий.
Проблема в том, что в итоге они скатились в какую-то фигню. Ладно бы они индексировали все возможные знаки, используемые в письменности. Но они зачем-то полезли в область "забавных картинок", которых, очевидно, бесконечное количество, а значит задача проиндексировать их все заведомо невыполнимая. В то же время, если бы они ограничились только письменностями, то в миллион кодпоинтов вполне бы вписались.
ответить
Прежде чем турнуть очередного флеймера...
Вообще обычно я комментарии такого рода не открываю, жизнь коротка, чтобы писать ответ каждому любителю пофлеймить. Но тут тот редкий случай, когда ответ написать даже прикольно. Итак,
А что насчёт ASCII? [...] Тоже фигня?
Ёлки-палки, да это даже не фигня, это намного хуже. Это сейчас мы набор символов ASCII воспринимаем как некую данность, потому что привыкли. А теперь мысленно перенесёмся в 1963 год. Компьютеры в те времена были большие и вообще их почти не было, вопросами компьютерных кодировок люди всерьёз начали интересоваться намного позже. Так что только телетайпы. Опять же, до всеобщей победы восьмибитного байта над другими вариантами разрядности — ещё лет двадцать. Большинство языков программирования, которые мы изучаем сегодня, ещё не появились даже в виде замысла в глубинах мозга их создателей. Чистый лист.
И вот смотрим, что такое представляет собой ASCII, если рассматривать его с чистого листа. Ну хорошо, алфавит заглавных и алфавит строчных — допустим, понятно. Плюс циферки. Уже 62 символа. Нужно явно больше. И нужна, похоже, степень двойки, это люди уже поняли, цифровая электроника (пусть пока и не компьютеры в нынешнем понимании этого слова) уже используется, да даже если бы и не, то дырка в перфоленте может быть либо пробита, либо нет, вот вам ноль с единицей. В 64 не уложились, следующая степень 128. Логично получаем семь бит. С этим понятно.
Ноль (ни одной дырки не пробито) и RUBOUT (пробиты все, код 127 -- в те времена так "выбивали" неправильно пробитые символы) имеют специальный смысл, с этим тоже всё логично. Вот только логика на этом, если подумать, заканчивается.
Ещё раз, ну буквы (те и другие), цифры — понятно. Знаки препинания: точка, запятая, двоеточие, точка с запятой, вопросительный и восклицательный знак, круглые скобки. Тоже можно согласиться. Апостроф — ну, куда ж в английском без апострофа. Двойная кавычка (не два парных символа кавычек, а одна двойная кавычка, позже ставшая "программистской") — странно, но можно перетерпеть. Арифметика: плюс, минус, дробная черта, больше, меньше, равно. Знаки доллара и процента — допустим, ладно. Ну хорошо, квадратные скобки, хотя это уже ОЧЕНЬ странно.
Но вот дальше начинается просто какой-то угар. Третья пара скобок (фигурные), но так и нет парных кавычек. Решётка и звёздочка (нет, никто не собирался звёздочку делать знаком умножения; но как раз знака умножения — точки, располагающейся в середине по высоте строки — комитет не предусмотрел). Амперсанд (?!). Тильда (?!!). Крышка, которая grave ^ — боже, что они курили. Обратный апостроф (?!!!!!). Обратный слэш (уже рука устала восклицательные знаки рисовать). Вертикальная черта. Знак подчёркивания (это сейчас мы к нему привыкли, а тогда?) "Коммерческое а" (@). Ёшкин кот, это всё вообще о чём?
Дальше управляющие символы. Ну, пробел понятно, он и не совсем управляющий. А вот из кодов 0--31 осмысленных раз два и обчёлся: ну с нулём понятно, CR и LF тоже понятно (мы же телетайпом управляем), BS (backspace), TAB... э.... ну ладно, допустим. Можно ещё понять BEL (звонок; ну да, на телетайпах был звонок). И даже, пожалуй, FF (form feed, в просторечии "выплюнуть лист бумаги"). В своё время я на матричных принтерах этот код сам использовал. Ну и ESC. Итого восемь кодов из 32. Остальные ну вот то есть просто нахрен не нужны, только место в таблице занимают. А места-то явный дефицит, между прочим. Ладно что нет никакого "длинного тире", хотя могло бы быть даже в моноширинной ситуации (например, дефису/минусу урезать по боками пиксели, а длинное тире сделать во всю ширину знакоместа). Нету, как я уже несколько раз повторял, парных кавычек. Диакритических знаков нет, хотя уж это можно бы было догадаться, что вообще-то нужно, и для телетайпов реализуется элементарно: буква, возврат назад на знакоместо, печать диакритики. Но нет.
Реальную степень вреда, который всему человечеству в своё время нанёс этот комитет, ещё только предстоит осознать, но уже сейчас понятно, что ASCII — одно из самых вредоносных комитетских поделий в истории. Только сейчас уже его не искоренить, формальные языки (все) на ASCII завязаны намертво. Роковая ошибка из тех, которые исправлению не подлежат.
Но они зачем-то полезли в область "забавных картинок"
А что, непонятно, зачем конкретно они туда "полезли"? Письменности все уже там, всё, готов реестр символов, надо бы на этом остановиться и комитет распустить. Но члены комитета явно не хотят, чтобы их распускали, ведь клёво же ничего не делать и деньги получать. Не волнуйтесь, они ещё и не такое придумают. Если их не перестрелять, но нынче этот метод утратил свой общепризнанный статус. А жаль.
P.S. в интернете есть много других сайтов, этот не единственный. Идите там пофлеймите, что вы сюда-то припёрлись?
ответить
Вот, на самом
Вот, на самом деле, очень хороший пример того, что "старое" - не всегда "доброе", просто когда-то что-то, как говорится, "пошло не так", и никто не обратил на это внимания. А потом, вроде, и к костылю привыкли (а если его к ноге изолентой примотать, то вообще красота, всегда под рукой, не потеряется), и одним глазом можно смотреть, если второй шарфом завязать, и все заверте...
Есть, правда, у меня одна мысль в порядке общего бреда (не застал больших компьютеров и телетайпов, поэтому только догадка): возможно, в изобилии вот этих вот косых и прямых черт и прочих подчеркиваний предполагалось наличие смысла, ведь до картинок с котиками было еще далеко, и на компьютерах, внезапно, считали, о чем и говорит название. Результаты нужно было как-то интерпретировать, ведь они могли предназначаться не только для спецов, работающих с техникой. Предположу, что такие символы могли использоваться (или такое использование предполагалось "стандартизаторами") в качестве псевдографики для оформления, например, таблиц (как в расширениях Markdown) или "отрисовки" чего-нибудь типа закорючек интегралов (может, и знак доллара в таком разрезе для убийства двух зайцев?). Хотя, возможно, путаю причину и следствие, и все это появилось позже вместе с ASCII-артом. Вот что абсолютно за гранью понимания, так это 0-31, на место большинства из которых та же диакритика вписалась бы с комфортом. Короче, "кушаем на здоровье" и благодарим добрых дяденек, as usual.
ответить
☞ From Anonymous (unverified) Mon Oct 26 09:45:00 2020 UTC
Здравствуйте,
Здравствуйте, Андрей Викторович. Как-то вот в процессе чтения некоторых записей в гостевой возник вопрос: вы никогда не думали о возможности написания чего-либо по программированию микроконтроллеров? В среде правят бал адепты секты Arduino с их вечным тупняком в цикле, смущающие незрелые умы. Думается, "глас разума" в вашем исполнении был бы весьма полезен миру (не лести ради, а токмо интереса для). Использование Си в условиях bare metal - крайне интересная тема (раз уж тут любители "стандартных" библиотек набежали), да и работа с прерываниями представляет интерес в плане эффективного расходования аппаратного времени и ресурсов.
ответить
Увы
Эта область находится за пределами моей уверенной компетентности. То есть я с микроконтроллерами работал, но только с ATMega'ми, и фактически только одну задачу на них решил. Маловато, чтобы за книгу садиться.
ответить
☞ From Александр (unverified) Fri Oct 23 23:33:00 2020 UTC
Проверка пожертвований
Есть ли какой-то способ узнать, что пожертвование до Вас дошло? Отправил пожертвование с сопроводительным письмом и опасаюсь, что деньги до вас могли не дойти. Не знаю, как часто вы их проверяете, но если что-то случилось, то время на разрешение проблемы может оказаться ограниченным со стороны банка.
Просто хотелось бы убедиться, что деньги до вас до шли, а там куда они пошли - уже не важно.
С уважением, Александр.
ответить
Подозреваю, что
Подозреваю, что до меня тупо не дошло Ваше письмо. Просто на все дошедшие сообщения о пожертвованиях я отвечаю по почте, подтверждая факт получения пожертвования, так что вопросы о проверке не возникают.
Вы не могли бы продублировать своё письмо? Можно ещё тут в комментах (вот прямо ответом на этот мой комментарий) сообщить, когда/сколько переводили, как Вас упомянуть в списке пожертвований и -- желательно -- на какой адрес Вам послать подтверждение (ибо комментарий я, естественно, оставлю скрытым, публично обсуждать конкретику одного пожертвования было бы странно). Ну, или можно будет рассматривать в качестве подтверждения появление пожертвования в списке.
UPD: Всё в порядке, Ваше пожертвование получено, в списке отражено, я Вам на почту написал, но не знаю, дойдёт или нет (мало ли).
ответить
☞ From Ilia (unverified) Thu Oct 22 18:33:00 2020 UTC
Интересные случаи информационного насилия
Андрей Викторович, возник довольно любопытный вопрос по части информационного насилия.
Первый случай: информационное насилие по глупости или незнанию. К примеру, приходит человек к нотариусу и, узнав цену за услуги или какие бумажки нужно привести, наваливает оскорбления( "вы бюрократы и наживаетесь на нас", хотя цена экономически обоснована и бумаги требует закон, а не мы ). Это относится к неизбежному насилию в адрес нотариуса или это даже насилием назвать нельзя, потому что представители этой профессии знают, что такие люди будут попадатся, а если знаешь и не нравится, то вали с этой профессии?
Второй случай: болезнь близкого человека. Например, у человека болезнь Альцгеймера и он своих близких будет доводить до сумасшествия, и тут практически нереально( по крайней мере в наше время, хотя кто знает, когда смогут победить это заболевание ) бороться с больным. Это тоже неизбежное?
ответить
Простите, вы вообще о чём?
> приходит человек к нотариусу
Я что-то в упор не вижу, где здесь неизбежность насилия. Пришёл (сам!), увидел ценник (тебе его никто не навязывал, ты его сам пришёл смотреть), ценник тебя не устроил, никто не неволит, вон дверь открыта. Где здесь хоть какой-то элемент неизбежности?
> у человека болезнь Альцгеймера
Говоря о свободе и насилии, я всё-таки рассматриваю дееспособных людей. Человек с альцгеймером -- это уже не совсем человек, для меня его правосубъектность сомнительна. Как с такими людьми быть — вопрос крайне сложный, но он вообще не из этой области, а ту область, к которой он относится, я не исследовал и обсуждать не готов.
ответить
☞ From Anonymous (unverified) Thu Oct 22 15:36:00 2020 UTC
Вопрос про STL
Учусь на ВМК, учился программировать в том числе и по вашим книгам.
Мне понятен, ваш аргумент о том, что C++ в связке с STL допускает макакокодинг.
В особенности, если не знать о том, что такое указатели и как с ними работать.
(И да, на занятиях по практикуму нам рассказывали про STL довольно много и
подробно: Андрей Алексеевич с Александром Владимировичем почему-то очень
любят STL)
Но что плохого в том, чтобы использовать шаблоны из STL с пониманием, уже имея
опыт работы с указателями и динамической памятью на plain C?
С пониманием их реализации, сложности работы, и т.д.
Допустим, для решения моей задачи мне нужно бинарное дерево поиска.
Вы предлагаете реализовать шаблонный класс самостоятельно в своей программе,
вместо того чтобы воспользоваться
std::map?Гораздо чаще приходится работать с динамическими массивами. Допутим, я выделил
память на 10 элементов и тут мне нужно добавить 11-й. Мне ручками удвоить размер
выделенной памяти?
Или лучше реализовать класс
template DynamicArray<class T>с методомadd()?ответить
Здесь слишком
Здесь слишком много вопросов (причём из структуры заданных вопросов не очевидно, что их тут на самом деле намного больше), и ответов на них требуется тоже до фига. «Почему нельзя использовать STL» — это на самом деле:
Если кратко — да, все структуры данных только руками. Никаких контейнерных классов, никаких контейнеров, даже если это не классы, никаких шаблонов (точнее, никаких шаблонов для создания контейнеров, так-то шаблоны штука хорошая), и НИКАКИХ вообще средств из std::, никогда, ни для чего, даже если это всего лишь iostream, — коготок увяз, всей птичке пропасть. А вот "почему" -- это в формат коммента не уложится.
ответить
*почему нельзя
*почему нельзя использовать контейнерные классы, даже если они свои собственные
*почему нельзя использовать шаблоны для построения "обобщённых" структур данных (шаблоны сами по себе использовать в программах можно, но не для этого)
*почему нельзя — категорически! — иметь никаких реализаций "массива вообще", "списка вообще", "стека вообще", "очереди вообще", "дерева вообще" и тому подобного, даже если для этого не используются ни шаблоны, ни классы
А вот на эти вопросы мне тоже было бы интересно получить ответы. Вы уже упоминали об этом на сайте, и я думал, что в четвёртом томе будет ответ, но такового не оказалось.
Потому что аргументы сторонников контейнерных классов довольно очевидны, а вот известные мне аргументы противников, на мой взгляд, неубедительны, и это даёт основание думать, что мне они известны не все.
ответить
А в число
А в число "известных вам аргументов" входит такой, что STL, позволяя сэкономить пять минут на кодировании, приводит к потерям недель (а то и месяцев) на отладке и сопровождении? Или это тоже неубедительно?
P.S. Судя по всему, на этот сайт вы зашли напрасно, мне тут stl-фаги не нужны. Ваша простыня дифирамбов контейнерам раскрыта не будет, и вообще ваши комментарии здесь больше раскрываться не будут, у меня есть более интересные занятия, нежели дискутировать с подобными вам людьми.
ответить
Так всё-таки почему?
нельзя использовать контейнерные классы, даже если они свои собственные
Тот же самый SparseArray из "Введения в C++" - это разве не контейнер? Тогда что такое контейнер?
шаблоны сами по себе использовать в программах можно, но не для этого
А для чего же?
Проблема в том, что после прочтения "Введения в C++" у меня сложилось
впечатление, что STL - это плохо и использовать в своих программах не стоит,
но вот понимания почему - нет. Если конкретно, то непонятно, почему нельзя
использовать "обобщённые" структуры данных, даже если бы они не были "стандартными".
ответить
Краткий ответ
SparseArray -- это, несомненно, контейнер. И да, использовать его не следует. Почему не следует вообще никогда использовать контейнеры — см. выше пример.
Сложнее вопрос о том, почему нельзя делать "универсальные" ("обобщённые") реализации структур данных. Краткий ответ — потому что структуры данных не бывают универсальными.
Вот вам пример: у меня в InteLib'е (http://www.intelib.org) есть класс, реализующий трёхстековую виртуальную машину. Каждый из стеков реализован как массив, различаются вроде бы только типами элементов. Кажется, ну вот чего бы тут не сделать одну общую реализацию стека.
Так вот, я, естественно, такую общую реализацию делать не стал, а в итоге получилось, что те три приватных метода, которые вызываются, когда надо изменить размер массива, вышли друг на друга совершенно не похожими. Потому что разные вещи надо делать. Вот так вот, внезапно.
Ну вот просто осознайте простой факт: не бывает "массива вообще" или "списка вообще". И тем более "дерева вообще". Структуры данных должны проектироваться под конкретную предметную область, а обобщения нас тупо уводят от сути.
ответить
Стандартная библиотека
> почему вообще не должно быть никакой "стандартной" библиотеки, т.е. никакие библиотеки не должны иметь особого статуса в сравнении с другими
То есть, стандартная библиотека языка C — это плохо?
Но ведь без неё не работает большая часть UNIX-подобной системы и даже программисты на ассемблере, эту библиотеку используют часто. Да и вроде бы, библиотеки других ЯП тоже обёртки над libc.
Если это так, то как предлагаете обходиться без этой либы? Без неё ведь даже hello world не обходится — printf, puts из неё.
ответить
Что, трещит шаблон? :-)
Стандартная библиотека Си — это не просто плохо, это ужасно. Слишком часто её воспринимают как часть языка, а между тем Си только тем и интересен, что позволяет без неё обходиться — как это, собственно, и делается в ядрах систем и прошивках микроконтроллеров. Кроме того, вы мейнстримовую реализацию glibc видели? Я — видел. Кто бы мне теперь это развидел. А вот заменить этого монстра, к счастью, можно и даже есть на что (например, на тот же musl), но только целиком, по частям не получается. А у musl'а тоже свои приколы, хоть в целом он, несомненно, лучше.
Заметим, я не утверждаю, что libc "вообще не должно быть". Она вполне может "быть", но не в виде того монстра, которым является сейчас, а в виде кучки отдельных библиотечек, имеющих свои названия и свои предметные области, и, что важно, не имеющих никакого особого статуса — хочешь, используй эти, хочешь — используй другие, комбинируй их как хочешь. Единственным "общим местом" мог бы быть набор обёрток для системных вызовов, но он должен идти в комплекте не с компилятором, а с ядром.
Но вот что забавно — так это ваше заявление про программистов на ассемблере. Во-первых, программистов на ассемблере не бывает. Во-вторых, если допустить, что они бывают, то, конечно, они никогда не используют libc, это сделало бы работу на асме окончательно бессмысленной. А курс Падаряна, практикум к которому построен этаким вот образом, забудьте как страшный сон — там, насколько я помню, ассемблерные подпрограммы "функциями" называют, дальше можно не смотреть.
ответить
> Слишком часто
> Слишком часто её воспринимают как часть языка
Тогда можно сравнить Tcl и Lua. В Tcl многие возможности доступны сразу после установки. В Lua — нет, даже просто обработка строки в UTF-8 требует вручную ковырять байты или импортировать библиотеку.
Думаете в этом плане Lua лучше? Но зато в Tcl мне не нужно думать о том, что у запускающего мою программу не окажется каких-то либ, реализующих базовую функциональность. Если установлен любой дистрибутив Tcl, то и все команды, описанные на странице документации tcl.tk, будут на месте и все программы, где нет package require будут работать. А в Lua нужно ещё найти и доустановить все недостающие модули даже для самых простейших вещей или усложнять код, реализуя их самостоятельно.
По-моему, если есть возможность набрать одну команду пакетного менеджера и сразу получить какую-то базовую функциональность в рамках какого-то языка — это полезно. Хотя это не обязательно должно называться стандартной библиотекой.
ответить
"Строки в UTF-8"
"Строки в UTF-8" — это просто один из многих форматов данных, не более того. Поддержка UTF-8 в языке — это образец крайней степени падения создателей языка. Так что, несомненно, в ЭТОМ Луа лучше, нежели "современные" версии Tcl (там вообще, начиная с 8.4, началось скольжение по наклонной в пропасть), хотя вообще изначально как язык мне Tcl несомненно нравится, а Луа столь же несомненно вызывает отвращение.
Кстати, "набрать одну команду пакетного менеджера" — это весьма сомнительно, ибо внешние зависимости есть абсолютное вселенское зло, так что все используемые библиотеки должны находиться в дереве исходников основной программы, иное представляет собой откровенное хамство в отношении пользователей и мейнтейнеров. Впрочем, писать на скриптовых языках программы общего назначения, передаваемые другим людям (пользователям) — это хамство само по себе, а если программка пишется исключительно для личного употребления, то какие там будут зависимости — сугубо личное дело её автора и пользователя в одном лице.
ответить
Впрочем, писать
Впрочем, писать на скриптовых языках программы общего назначения, передаваемые другим людям (пользователям) — это хамство само по себе, а если программка пишется исключительно для личного употребления, то какие там будут зависимости — сугубо личное дело её автора и пользователя в одном лице.
Тут возникает вопрос из области, наверное, этики.
Что, если автор написал программку общего назначения исключительно для личного употребления, а потом подумал и выложил её в интернет, с вполне доброжелательной мыслью, что может быть ещё кому-нибудь пригодится? Считать ли эту программу "передаваемой другим людям (пользователям)"? Считать ли действия автора "хамством", если эта программка написана на скриптовом языке? Должен ли автор взять на себя ответственность за возможных пользователей своей программы и не выкладывать её в общий доступ либо пока не перепишет её на компилируемом языке с минимумом зависимостей, либо, что более вероятно, никогда?
ответить
Этика - штука субъективная
Этика - штука субъективная, поэтому я здесь не могу претендовать на истину в последней инстанции. Но лично я для себя не считаю возможным выкладывать подобный шлак. Если уж решил выложить — то либо переписывай так, чтобы этим можно было пользоваться, либо жди, пока кто-нибудь другой перепишет. А то ведь тут есть ещё один хитрый момент: кто-то другой может даже собраться что-то подобное написать, но потом заметит, что некое "решение" уже вроде бы есть, и передумает. А решения-то по факту и нет, вместо него куча дерьма.
ответить
обратный эффект тоже возможен
А то ведь тут есть ещё один хитрый момент: кто-то другой может даже собраться что-то подобное написать, но потом заметит, что некое "решение" уже вроде бы есть, и передумает.
Но может случиться и наоборот: кто-то другой увидит, что есть такое "решение", заглянет в код и подумает "боже, какое дерьмо, но программа нужная и пара годных идей в реализации есть, дай-ка перепишу её на чём поприличнее".
Если уж решил выложить — то либо переписывай так, чтобы этим можно было пользоваться, либо жди, пока кто-нибудь другой перепишет.
Ведь чтобы кто-нибудь другой переписал, этот другой должен сначала увидеть то, что он будет переписывать. А специального отдельного интернета для выкладывания плохо написанных программ для дальнейшего переписывания у нас нет.
Ну и ещё отдельная мысль у меня мелькает, что я скорее доверюсь кривоватой программе на скриптовом языке, которую написал человек для личного пользования, чем профессионально написанной компилируемой программе, которую написал человек с целью получить зарплату у гугла или интела.
ответить
Короче, сложный вопрос
Лично я такое не выкладываю и стараюсь таким не пользоваться (последнее не всегда получается, потому что ниша занята какими-нибудь питономакаками, как, например, с единственной кое-как работающей программой проектирования печатных плат по имени kicad -- таки да, на питоне написана). Другим запретить это делать я в любом случае не могу, как и убедить всю мировую публику, что программа на скриптовом языке -- это хамство. Но сам остаюсь при этом мнении.
ответить
Ну да. Тут вон
Ну да. Тут вон на гитхабе все репы youtube-dl заблокировали на днях, копирасты кляузу написали.
Так вот, что касается youtube-dl, с одной стороны, его писатели, конечно, питономакаки, которым надо бы руки поотрывать. А с другой стороны, я им глубоко благодарен за возможность без помощи браузера, не говоря уже о джаваскрипте, смотреть и скачивать видео с ютуба и с ещё нескольких сотен видео и аудио хостингов.
Ну и такой момент есть, что в последнее время я опенсорсный софт воспринимаю не как некий халявный конечный "продукт". А скорее как набор каких-то идей, выраженных в коде, которыми автор со мной поделился. И с этой точки зрения, конечно, выкладывать свой код лучше, чем не выкладывать, независимо от языка.
Да, если что, я вас не пытаюсь в чём-то убедить, просто делюсь своим мнением.
ответить
Гыгыгы,
Гыгыгы, побольше гитхаб юзайте, побольше.
ответить
Ну зачем же так
Ну зачем же так явственно злорадствовать, Андрей? ;)
Ну да, идиоты. Ну да, умным людям с самого начала было понятно, что не нужно завязываться в разработке на чужого "дядю". Поражает только, что умных людей гораздо меньше, чем кажется.
Я надеюсь, что эта история с гитхабом хотя бы некоторых чему-нибудь научит. Сейчас самое время ходить по форумам и тыкать любителей гитхаба носом в это дерьмо.
ответить
Честно говоря,
Честно говоря, мне с самого момента появления подобных сервисов -- всевозможных sourceforge и иже с ними, не только до покупки гитхаба малкомягкими, но и до собственно появления гитхаба, было понятно, что пользоваться этим нельзя категорически. Когда гитхаб таки достался мелкомягким, мне казалось, что всем уже всё должно стать очевидно. Но нет.
Ей-богу, ну вот достали. Не могу я теперь не позлорадствовать.
ответить
Вопрос этики
Считать ли действия автора "хамством", если эта программка написана на скриптовом языке?
Написание программы на скриптовом языке - это костыль изначально. Не надо писать софт на скриптовых языках. Скриптовые языки - это вспомогательные инструменты и они ни при каком раскладе не тянут на таковые для создания софта.
Огромная проблема скриптовых языков - хреновая обратная совместимость, но тех же питоняш это почему-то совсем не смущает.
Другой аргумент против скриптовых языков - они примитивные. Следовательно, их ниша - скрипты на несколько десятков строк. Вряд ли они кому-то будут полезны, кроме самого автора. Всё, что сложнее - должно писаться на нормальных компилируемых языках.
Весь практически полезный софт "почему-то" написан на компилируемых языках. А скриптовые поделки не востребованы, потому что неюзабельны. А неюзабельны они по причине частой неработоспособности из-за отсутствия обратной совместимости между разными версиями интерпретатора.
Если же принять во внимание жирность рантайма, необходимого для работы простенькой программы на скриптовом языке, то тут уже и хамство по отношению к пользователю явно проявится. Да и не только оно - в ряде случаев ещё и профнепрегодность (например когда питоноподелка сожрёт весь доступный объём памяти).
А ещё можно ответить на вопрос "Почему писать софт на скриптовых языках плохо?" так: потому что js. Жиэснутые макаки дискредитировали скриптовые языки окончательно и бесповоротно (а также превратили веб в огромную помойку).
ответить
Вопрос был не
Вопрос был не совсем в этом -- тут не так чтобы надо или не надо, с этим вроде и не спорит никто, а вот типа если уже написали, то выложить -- хамство или не хамство?
ответить
Конечно же хамство
Однозначно хамство. Потому что пользователю под видом софта выдаётся кустарное поделие.
Недостатки очевидны:
Скриптовые поделки необходимы ровно для одного - поднятия ЧСВ очередной питоняши, начитавшейся статеек в стиле "Пайтон подходит для всего".
ответить
для меня это не очевидно
Однозначно хамство. Потому что пользователю под видом софта выдаётся кустарное поделие.
А пользователю ничего не "выдаётся". Пользователь сам пришёл на сайт / в репозиторий. Не нравится -- может уйти. Показалось, что ему тут нахамили? Ну так можно никогда больше сюда не ходить, чтобы в ситуацию хамства больше не попадать. Это же не общественный транспорт, вроде трамвая, а личный сайт или репозиторий автора софта.
Заметьте, я не защищаю скриптовые языки. Я защищаю человека, который в своём личном пространстве выложил свой код, от того, чтобы это его действие называли хамством.
Тут, кстати, интерсный вопрос возникает. Вот, предположим, я где-нибудь в своём блоге допустил некое хамское высказывание в адрес, ну допустим, уважаемого хозяина этого сайта, Андрея Викторовича Столярова. Вопрос: можно ли считать, что я нахамил Андрею, если он про мой блог ничего не знает, никогда его не читал и, соответственно, этого хамского высказывания в глаза не видел?
ответить
Хамство
А пользователю ничего не "выдаётся". Пользователь сам пришёл на сайт / в репозиторий.
Пришёл чтобы получить в распоряжение интересующий его софт (по заявлению его создателей), а по итогу получил кое-как работающую поделку. Ну да, совсем не хамство.
Заметьте, я не защищаю скриптовые языки. Я защищаю человека, который в своём личном пространстве выложил свой код, от того, чтобы это его действие называли хамством.
Но ведь это провоцирует появление скриптовых поделок под видом софта - дурной пример заразителен.
Тут, кстати, интересный вопрос возникает. Вот, предположим, я где-нибудь в своём блоге допустил некое хамское высказывание в адрес, ну допустим, уважаемого хозяина этого сайта, Андрея Викторовича Столярова. Вопрос: можно ли считать, что я нахамил Андрею, если он про мой блог ничего не знает, никогда его не читал и, соответственно, этого хамского высказывания в глаза не видел?
С технической точки зрения - можно.
ответить
Так-с, вот тут я,
Так-с, вот тут я, пожалуй, влезу. Я категорически не согласен, что можно текст, размещённый "где-то там", пусть даже меня там называют земляным червяком, рассматривать как хамство мне. Это весьма принципиально. Достали уже все эти "защитники чувств" (верующих, трансгендеров, ниггеров и прочих обиженных) — а их требования как раз базируются на предположении, что оскорбить кого угодно можно простой публикацией чего-то такого, что кому-то неприятно.
В мире, насквозь состоящем из ванили, жить невозможно, просто потому что он фальшивый. Весь.
ответить
То есть, видимо,
То есть, видимо, акт хамства подразумевает обязательное наличие двух сторон: нахамившей и обхамлённой. И определять факт и степень хамства может только сама обхамлённая сторона, а не кто-то посторонний за неё и без её согласия.
Получается, что вы можете считать публикацию программы на скриптовом языке хамством по отношению к вам, но никак не можете считать это хамством по отношению ко мне или кому-то ещё?
ответить
Сложный вопрос.
Сложный вопрос. Вот, например, я вижу двух людей, один другому говорит: ты мудак. Я этому первому, судя по всему, имею все основания сказать, что сие есть хамство. Хотя, конечно, если второй скажет, что ни фига это не хамство, ну, скажем, что он вообще очень любит, когда его мудаком обзывают — наверное, мне придётся от своей оценки отказаться.
С публикацией софта ситуация ещё интереснее, тут аналогия скорее другая, поскольку здесь нет отношений между двумя конкретными людьми, а есть отношение одного человека и широкой публики. Вот, скажем, есть магазин (гипотетически), в котором клиентам, принимая с них деньги, сдачу швыряют на пол — типа, подбирай. Опять же, даже если я в этот магазин идти не собираюсь, мне это не помешает заявить, что творящееся там — хамство. И, пожалуй, здесь я от своей позиции не откажусь, даже если сразу два десятка покупателей того магазина заявят, что не считают себя "обхамлёнными".
Ну то есть понятно, куда вы клоните, но по-моему путь рассуждений тупиковый.
ответить
Защитники чувств
Достали уже все эти "защитники чувств" (верующих, трансгендеров, ниггеров и прочих обиженных) — а их требования как раз базируются на предположении, что оскорбить кого угодно можно простой публикацией чего-то такого, что кому-то неприятно.
Ну это вообще из другой оперы ) Это больше про юридический аспект и использование факта хамства в корыстных целях.
ответить
Вот ни фига. Ко
Вот ни фига. Ко всем этим результатам приводит исходная посылка, что можно кого-то оскорбить иначе как адресуя слова лично ему. Эта посылка ложная и вредоносная, она противоречит свободе слова.
Вообще о допустимом и недопустимом в коммуникациях я, как известно, развил целую теорию и диссер защитил, так что предпочту, наверное, воспользоваться своим понятийным аппаратом. Информация сама по себе не может быть ни законной, ни незаконной, законным или незаконным может быть только акт коммуникации, причём незаконным он может быть лишь в двух случаях: если кто-то из его участников не согласен в нём участвовать (т.е. имеет место информационное насилие) и если кто-то из его участников связан ранее взятыми на себя обязательствами, противоречащими этой коммуникации (т.е. имеет место несоблюдение собственных обязательств). Всё.
Публикация информации в интернете сама по себе насилием быть не может, поскольку публикующий демонстрирует своё согласие на коммуникацию фактом публикации, а читающие — фактом захода на соответствующий сайт. Если есть какие-то сомнения, достаточно добавить при входе на сайт "принятие условий" (например, "здесь вы можете столкнуться с информацией, которая вам будет неприятна — не хотите, не заходите") и всё окончательно встанет на свои места.
Ну а заведомо допустимую коммуникацию я бы не стал назвать "хамством"; с моей точки зрения "хамство" — это нечто такое, что вообще-то недопустимо.
ответить
Публикация
Публикация информации в интернете сама по себе насилием быть не может, поскольку публикующий демонстрирует своё согласие на коммуникацию фактом публикации, а читающие — фактом захода на соответствующий сайт. Если есть какие-то сомнения, достаточно добавить при входе на сайт "принятие условий" (например, "здесь вы можете столкнуться с информацией, которая вам будет неприятна — не хотите, не заходите") и всё окончательно встанет на свои места.
Ну а заведомо допустимую коммуникацию я бы не стал назвать "хамством"; с моей точки зрения "хамство" — это нечто такое, что вообще-то недопустимо.
Так, погодите. Что если в первом абзаце заменить широкий термин "информация" на более узкий "код компьютерной программы" (ну ещё "читающих" на "скачивающих" можно). Из этого, вроде бы, должно следовать, что публикация программы на скриптовом языке является заведомо допустимым действием, которое вы бы не стали называть "хамством".
Где я вас неправильно понимаю?
ответить
Ага, демагогия пошла
Ну так там будет рядом с программой написано, что это на самом деле не программа, а кусок дерьма, написанный на дерьмовом языке безрукими обезьянами? Если нет, то о каком согласии получателя идёт речь? Согласие должно быть информированным, а в данном случае одна из сторон сделки заведомо утаивает известные и существенные с точки зрения сделки обстоятельства.
Кстати, по-моему, вам уже пора на выход, конструктива в этой дискуссии было бы ждать несколько странно.
ответить
Свобода слова
Ко всем этим результатам приводит исходная посылка, что можно кого-то оскорбить иначе как адресуя слова лично ему. Эта посылка ложная и вредоносная, она противоречит свободе слова.
Свобода слова ограничивается всё же существованием ответсвенности за якобы "оскорбление", а не фактом его (оскорбления) существования. Факт признания или непризнания какой-то информации хамством никак не ограничивает свободу слова, её ограничивает именно ответственность за создание информации, которая может быть расценена как хамство.
Т.е., например, я могу охарактеризовать какую-то информацию как хамство, для вас же это хамством являться не будет, но при этом никакого ограничения свободы слова наблюдаться не будет, при условия отсутствия ответственности за создание информации. Хотя, конечно, факт наличия возможности признания хамством информации, потенциально способствует возникновению ограничения свободы слова.
ответить
Не распарсил
Вообще что-то мы уже совсем в дебри залезли.
ответить
Пришёл чтобы
Пришёл чтобы получить в распоряжение интересующий его софт (по заявлению его создателей), а по итогу получил кое-как работающую поделку.
А если в заявлении создателей чётко написано: "Мы, создатели этой программы, написали её для себя. Мы пользуемся ею и нас она устраивает, но никаких гарантий того, что она будет устраивать вас, пришедшего сюда пользователя, мы не даём. Решайте сами."
В таком случае вы не будете называть это хамством?
Но ведь это провоцирует появление скриптовых поделок под видом софта - дурной пример заразителен.
Возможно. Но это уже к вопросу о хамстве никакого отношения не имеет.
ответить
Лично я
Лично я открытую публикацию софтины на скриптовом языке буду считать хамством в любом случае. Ни от кого не требую того же самого, но моя позиция на эту тему не изменится. См. в параллельном треде пример с магазином, где сдачу на пол швыряют (и таки нет, даже если на дверях магазина написано, что, мол, тут сдачу кидают на пол, чтобы дать вам возможность лишний раз дать нагрузку на брюшной пресс, а то гиподинамия и всё такое — я всё равно не перестану считать это хамством).
ответить
Факт хамства
А если в заявлении создателей чётко написано: "Мы, создатели этой программы, написали её для себя. Мы пользуемся ею и нас она устраивает, но никаких гарантий того, что она будет устраивать вас, пришедшего сюда пользователя, мы не даём. Решайте сами."
В таком случае вы не будете называть это хамством?
Я думаю, что факт хамства не будет иметь места быть в случае такого описания программы, в котором будут подробно описаны все возможные проблемы, с которыми сможет столкнуться пользователь при её эксплуатации. Т.е. пользователь должен чётко понимать из описания, что он получает заведомо некачественный образец софта.
ответить
Скриптовые языки и обратная совместимость
Впрочем, писать на скриптовых языках программы общего назначения, передаваемые другим людям (пользователям) — это хамство само по себе, а если программка пишется исключительно для личного употребления, то какие там будут зависимости — сугубо личное дело её автора и пользователя в одном лице.
А если ещё учесть факт того, с какой лёгкостью создатели скриптовых язычков ломают обратную совместимость, то желание использовать любые скриптовые языки пропадает начисто.
ответить
Очень трудно отлаживать
Как действующий программист, который по большей части пишет на С++ и bash, хочу заявить, что это не нужно использовать, потому что код с STL очень трудно отлаживать.
Расскажу такой реальный случай: при реализации определенного функционала решено было( не мною, а архитектором ) использовать boost::optional. Но спустя два дня после тестировния вылез баг, который правили дня 3. А почему? Потому что обнаружили такое удивительное свойство у этого опшинола, который не смог ответить ни гугл, никто либо ещё. А именно: нельзя присваивать переменной опшинал через memset. Потерянные три дня - очень много. Иными словами, все эти эстээли - один сплошной чёрный ящик, который можно познавать годами. Намного проще с нуля это всё создать аккуратно, и в случаи необходимости добавлять дополнительные возможности. Тем самым вы не только время сэкономите, но и свои нервы. Причём ни то, ни другое не вернёт никто и ничто.
ответить
У меня был
У меня был случай ещё хлеще. Есть событийно-ориентированная программа, в ней есть список неких запросов к внешним серверам, которые сейчас вот прямо активны -- начались, но ещё не закончились. «Список запросов», естественно, закатан в класс, но, к счастью, это был не класс "список", а класс "список запросов к серверам", отражающий конкретную предметную область, а в нём внутри был обычный список, построенный из структурок ручками.
В том месте, где реализован протокол, от сервера приходит ответ, становится понятно, что запрос удовлетворён, о чём реализация протокола сообщает "списку запросов", мол, вот по этому запросу вот такой результат, делай с ним что там надо делать. И — бабах, происходит какая-то хрень.
Оказалось в итоге, что метод "списка запросов" идёт по списку, находит нужный запрос, в котором сказано, кого надо оповестить, то есть кто интересант данного конкретного запроса. Оповещает интересанта (дёргает его метод), после чего запрос исключает из списка.
Вот только интересант попался хитрый -- ему сначала нужен был один запрос, а потом, по его итогам -- второй. И он, получив результаты первого запроса, обращается к тому же "списку запросов", чтобы в него включить новый запрос. А ещё там бывал запрос, который не прошёл, ну то есть ошибка получилась, и были интересанты, которые при этом отменяли ещё и некий запрос, который ранее сделали, но который ещё не завершился. В итоге у вышеупомянутого метода списка запросов внутренний список прямо "под руками" меняется.
К чему я это. В отладчике тот факт, что список прямо под руками "поплыл", всё-таки раза с пятого заметили. И сделали очевидный фикс: сначала запрос из списка исключить, а потом уж оповещать интересанта. А вот если бы это был не обычный список на указателях, а контейнер -- я, честно говоря, не знаю, возможно ли было бы вообще этот баг выловить и сколько времени бы на это ушло.
Между прочим, вот с этим я согласен:
Иными словами, все эти эстээли - один сплошной чёрный ящик, который можно познавать годами.
но с выводом, что надо "всё это сделать с нуля" — категорически нет. Не надо это делать ни с нуля, ни как-либо ещё. В программе, над которой работает пять-шесть человек (а это ещё не много), самописные контейнеры будут таким же точно чёрным ящиком для всех участников, кроме одного, который их писал. Да даже и для их автора — не так чтобы совсем чёрным, но ящиком: вон в вышеописанном случае был бы у меня самописный контейнер вместо того списка, сколько бы времени я ещё потратил, чтобы заметить, что происходит?
Как говорится, "просто скажи нет".
ответить
Ну, это не
Ну, это не убедительный пример.
Во-первых, сама идея вызывать memset на класс -- идея несколько странная, я бы сказал, даже безумная. За такое нужно бить по рукам. Большинство классов придёт в негодность, если на них вызвать memset, ожидать обратного -- странно. Мало ли, что делает его конструктор? Например, это произойдёт, если в классе (или в классе, прямо или косвенно являющемся его полем) есть хотя бы одна виртуальная функция. Так что ж теперь -- виртуальные функции тоже не использовать?
Во-вторых, я не могу понять, что вы там отлаживали столько времени. Часа четыре ещё можно потратить, да и то это много -- при наличии опыта работы с STL всё это отлавливается довольно быстро.
ответить
Какие ещё
Какие ещё виртуальные функции, откуда в STL виртуальные функции :-) Но в целом да, соглашусь: объект типа класс, имеющий конструктор — это совершенно точно не такая штука, на которую стоит применять memset. Он из другой сказки.
ответить
Да, безумие, но разбираться пришлось мне.
Согласен, что это безумие, но человек, который это писал, до моих дней на работе недожил, причину не знаю. Но если пройтись отладчиком, то как раз всё в порядке: через memset присвоить boost::optional и в нём действительно будет занесено это число. Коварство заключалось в том, что если этот класс проверить через иф, то всё - значение переменной не поменялось, поэтому иф будет всегда давать false. Получается, что первое поле класса хранит значение переменной, но наверника есть ещё и какой-нибудь bool, который меняется при вызове присваивания.
По поводу 3 дней: вы бы знали какой там стэк вызовов - очень большой.
ответить
Не, ну тут уж
Не, ну тут уж пардон. Какая разница, кому пришлось разбираться? Если память объектов типа класс, имеющих закрытые поля, переезжать memset'ом, то уж точно проблема будет не в классах, а в мозгу того, кто так сделал.
Ну то есть тут, во-первых, да, полный бред получился, но boost в этом не виноват и это никак не аргумент против boost'а. С другой стороны, конечно же, boost нельзя использовать, но уж точно не потому, что, видите ли, в нём всё ломается, когда по нему memset'ом.
ответить
☞ From Anonymous (unverified) Wed Oct 21 17:20:00 2020 UTC
Андрей
Андрей Викторович, начал читать первый том, и меня немного удивил подход программирования под Unix. Мне хотелось бы узнать у вас трудно ли будет найти работу программисту в России разрабатывающему ПО под unix (заранее извиняюсь,если мой вопрос выглядит как троллинг) или же у вас unix преподносится скорее для обучения, а для работы все равно придется перейти на windows?
ответить
Трудно ли будет
Трудно ли будет найти работу — зависит исключительно от квалификации. Нормальных программистов — жесточайший дефицит, и не только в россии — во всём мире.
Понятие "придётся" к квалифицированным программистам неприменимо в принципе. При имеющихся раскладах на рынке труда программисты сами выбирают, где им работать.
А вот стать программистом такой квалификации, чтобы всё вышесказанное относилось к вам, по-моему, при продолжении работы с форточками невозможно. Во всяком случае, лично я не знаю, как.
ответить
Ну вот я,
Ну вот я, например, работаю под linux -- у нас можно выбирать, под чем работать, так как разработываемое ПО -- кроссплатформенное. И использование linux среди разработчиков даже приветствуется, хотя "виндузятники" тоже есть.
Нормальных программистов — жесточайший дефицит, и не только в россии — во всём мире.
Что правда, то правда. Насколько мне известно, многие кандидаты на собеседовании не могут написать даже простейшую задачу для первого курса -- вроде того, чтобы пройти по массиву или списку чисел, удалив из него элементы, которые больше среднего арифметического своих соседей.
А вот стать программистом такой квалификации, чтобы всё вышесказанное относилось к вам, по-моему, при продолжении работы с форточками невозможно. Во всяком случае, лично я не знаю, как.
Если честно, я тоже не знаю, как, но это возможно. Лично знаю таких. Впрочем, тут есть момент, что предпочитая работать в windows (в силу определённых привычек), они умеют при необходимости работать и в linux. Пусть даже они и не знают каких-то нюансов этой системы из-за того, что не пользуются ей постоянно (как я, например, не знаю многих нюансов windows -- по той же причине).
Тем не менее, факт в том, что человек, работающий в linux, как правило, без проблем сможет делать то же самое и в windows, просто ему будет неудобно (хотя, установив в windows некоторое количество дополнительных программ, можно преодолеть часть неудобств, хотя и не все). Дело здесь в том, что использование linux поощряет "прокачку" некоторых навыков, таких как работа в терминале, ручная сборка программ из исходного кода, редактирование конфигурационных файлов, работа с правами доступа в системе и, что самое главное, привычка разбираться в деталях того, как же на самом деле всё работает. Это не значит, что при использовании linux всё это необходимо. Но для linux подобные действия являются естественными, а для windows -- скорее чужеродными. В самом деле, виндузятника, пользующегося терминалом (привет Far-Manager-у) или редактирующего конфиги^Wреестр, найти ещё можно , но покажите мне виндузятника, который настраивает в системе права доступа или (о, ужас!) устанавливает программу, компилируя её из исходников! Впрочем, попытавшись это проделать, легко понять, почему это так. Это такой квест, пройти который способен либо мазохист, либо человек, понимающий, что он делает и зачем. Под linux же всё это на порядок проще. И опыт работы с этим в linux может помочь потом проделать то же самое и в винде (например, если нужно настроить систему кроссплатформенной сборки или ещё что-нибудь не совсем тривиальное).
Тем не менее, переходить в linux полностью, забыв про windows, на мой взгляд, не совсем правильно. Linux имеет смысл сделать своей основной системой, но есть смысл оставить windows в dualboot и примонтировать её разделы. Как минимум, всё равно придётся взаимодействовать с другими людьми, у которых с большой вероятностью windows. А значит, полезно сразу узнать о различных кодировках кириллицы, о концах строк в файлах (и утилитах dos2unix и unix2dos), о программе wine (так как не все виндовые программы есть под linux), о том, что делать если безмозглый товарищ-виндузятник прислал zip-архив с русскими буквами в именах файлов, которые при распаковке превратились в закорючки (обычно в таких случаях я отправляю обратно архив в формате наподобие tar.lzma, чтобы процесс распаковки был для него максимально нетривиальным :)).
В предыдущих абзацах я несколько "ушёл в сторону" и растёкся мыслею по древу, но общая идея в том, что научившись работать в linux, вы легко освоите винду на более высоком уровне, чем если начнёте сразу с винды. Можно освоить всё то же самое и под виндой, просто это на порядки сложнее. При этом linux с большой вероятностью всё равно будет иметь смысл изучить как минимум для широты кругозора. Так проще с него и начать)
P.S. Интересно, пройдёт ли этот комментарий премодерацию.
ответить
Не, ну всё понимаю, но
Не, ну всё понимаю, но...
есть смысл оставить windows в dualboot и примонтировать её разделы. Как минимум, всё равно придётся взаимодействовать с другими людьми, у которых с большой вероятностью windows
так это что же, каждый раз, когда очередное ламо что-нибудь эдакое пришлёт, комп перезагружать?
ответить
Нет, почему же?
Нет, почему же? Смысл в том, чтобы оставить резервную возможность сделать что-либо в windows на случай если в linux быстро не получится, а сделать надо срочно. Ну вот не получится сразу всё, что работало в винде, настроить и в linux -- это время займёт. Нет, может, сейчас, в современных условиях, это и проще, но в 2009 году у меня на настройку принтера в linux ушло полгода, а на настройку сканера -- полтора. Сейчас, например, принтер подключается "из коробки", а вот со сканером по-прежнему много возни, просто теперь опыта больше.
А так -- нежелание постоянно перезагружаться как раз и должно стимулировать разбираться, как то или иное действие настроить в windows. Естественно, я не предлагаю ради того, чтобы открыть виндовый архив с русскими буквами в именах файлов, перезагружаться в винду. Да и программы виндовые многие вполне успешно работают через wine. Например, я в своё время так запускал word viewer, чтобы открывать .doc файлы, с которыми libreoffice (или тогда ещё openoffice) не справлялся. Но всё равно, на мой взгляд, винду есть смысл оставить на всякий пожарный -- мало ли что? Хотя да, сейчас с этим ситуация лучше, чем лет 10 назад.
ответить
> оставить
> оставить резервную возможность сделать что-либо в windows на случай если в linux быстро не получится, а сделать надо срочно.
Единственный вариант, когда что-то сделать в Windows проще и удобнее чем в GNU/Linux — это если нужно объяснить виндузятнику, как что-то сделать в Windows, для чего вначале нужно понять как делать это самому. Но у меня такие ситуации редко возникали, я как правило виндузятникам говорил скачать что-нибудь вроде cygwin, что бы самому не связываться с кривым виндософтом.
> но в 2009 году у меня на настройку принтера в linux ушло полгода, а на настройку сканера -- полтора.
Ты к ним драйвера с нуля писал что ли? Это единственное, чем можно объяснить столь долгий срок. Кстати, я к своему устройству, драйвер под линукс писал один раз, сделал это за неделю приблизительно. Но там я просто выловил нужные команды из обмена с проприетарным драйвером, а затем поправил код, скопированный из драйвера подобной, но другой железки.
> Но всё равно, на мой взгляд, винду есть смысл оставить на всякий пожарный -- мало ли что?
Ради такого пожарного у меня есть подержаный поломанный ноутбук который я купил за 2000р с рук семь лет назад. Включать его пришлось всего раза три, и то два из них из любопытства будет такая-то штука работать или нет, а не по необходимости.
Виртуалка однозначно лучше и безопаснее дуалбута. Из тех что пробовал, самая удобная — qemu.
> Например, я в своё время так запускал word viewer, чтобы открывать .doc файлы, с которыми libreoffice (или тогда ещё openoffice) не справлялся.
Если там docx, то можно распаковать unzip-ом и затем преобразовать в текст чем-то вроде sed -i 's/<[^>]*>//g' content.xml
ответить
Единственный
Единственный вариант, когда что-то сделать в Windows проще и удобнее чем в GNU/Linux — это если нужно объяснить виндузятнику, как что-то сделать в Windows, для чего вначале нужно понять как делать это самому. Но у меня такие ситуации редко возникали, я как правило виндузятникам говорил скачать что-нибудь вроде cygwin, что бы самому не связываться с кривым виндософтом.
А также когда я не единственный пользователь компьютера, а другие не готовы к переходу на linux. Кроме того, бывает всякое упоротое ПО вроде по для калибровки цветов у струйнымх принтеров фирмы Epson. Я не сомневаюсь, что можно потрахаться неделю и настроить, тем более, что оно вроде есть и под linux и даже с открытым кодом, но код там такой, что я удивлён, что разработчики не постеснялись его выкладывать. Учитывая, что этот принтер нужен раз в полгода, проще перезагрузиться в винду.
Ты к ним драйвера с нуля писал что ли? Это единственное, чем можно объяснить столь долгий срок. Кстати, я к своему устройству, драйвер под линукс писал один раз, сделал это за неделю приблизительно. Но там я просто выловил нужные команды из обмена с проприетарным драйвером, а затем поправил код, скопированный из драйвера подобной, но другой железки.
Нет. Я даже сейчас ни разу не пробовал писать драйвера, хотя есть мысль как-нибудь на досуге изучить, как это делается. Проблема была в том, что "из коробки" принтер не заработал, а для того, чтобы понять инструкцию по настройке, которую я нашёл в интернете, у меня не было достаточно опыта. А именно, у меня был принтер фирмы Xerox, но, как оказалось, к нему нужно было подсовывать драйвер от Samsung-а из пакета splix. Каким местом до этого догадался автор той инструкции, для меня до сих пор открытый вопрос, впрочем, я особо глубоко не копал. Со сканером ещё веселее -- там нужно было копировать проприетарные библиотеки от Samsung, но они требовали другой библиотеки, и чтобы установить это, требовалось вызвать ldd. Я согласен, что это очень просто, но не для человека, который только что поставил linux и не имеет опыта программирования. Поэтому пока настроить не получилось -- сканировал в винде. Как получил необходимые навыки -- разобрался и настроил.
Ради такого пожарного у меня есть подержаный поломанный ноутбук который я купил за 2000р с рук семь лет назад. Включать его пришлось всего раза три, и то два из них из любопытства будет такая-то штука работать или нет, а не по необходимости.
Не всегда есть возможность держать отдельный компьютер для запуска "виндовых" задач.
Виртуалка однозначно лучше и безопаснее дуалбута.
Безопаснее -- отчасти да, но если под виндой особо ничего не делать, то вредоносному ПО там взяться неоткуда (если не считать саму винду :)). Насчёт лучше -- далеко не всегда.
Из тех что пробовал, самая удобная — qemu.
QEmu же вроде медленный, насколько я знаю. Это же эмулятор процессора, пусть и с некоторой оптимизацией. Я использую VirtualBox.
Если там docx, то можно распаковать unzip-ом и затем преобразовать в текст чем-то вроде sed -i 's/<[^>]*>//g' content.xml
Нет, там был не docx, а обычный doc. Openoffice его открывал, но русские буквы почему-то не отображались, и кодировку выставить было негде.
ответить
Windows не нужен
Openoffice его открывал, но русские буквы почему-то не отображались, и кодировку выставить было негде.
Странно. В каком именно смысле они не отображались? Можно найти нужные кракозябры в таблице на одноименной статье википедии, затем применить iconv или другой транслятор кодировки.
QEmu же вроде медленный, насколько я знаю.
Не такой уж и медленный, а главное, удобнее всего остального. В VBox приходится задавать все параметры виртуалки в графическом интерфейсе, а в qemu можно просто написать например -m 1024 что бы дать виртуалке гигабайт оперативки, и загрузка системы начинается сразу после ввода команды и не нужно прокликивать настройки и кнопку "запуск".
Не всегда есть возможность держать отдельный компьютер для запуска "виндовых" задач.
Да ладно? На старые компьютеры спрос настолько низкий, что можно легко достать их бесплатно или за низкую цену. А можно и вообще взять ReactOS. Новые да — сейчас уже придётся выложить под сотню тысяч. А старый и вполне неплохой можно даже на помойке найти.
А также когда я не единственный пользователь компьютера, а другие не готовы к переходу на linux.
Дать им старый комп из предыдущего пункта, установив на него любой дистрибутив с браузером и dd в консоли, дать флешку гигабайт на 8 и пусть себе качают и ставят любую ОС, какую они хотят сами, хоть KolibriOS, хоть DragonflyBSD, хоть Windows.
Кроме того, бывает всякое упоротое ПО вроде по для калибровки цветов у струйнымх принтеров фирмы Epson.
Кстати, всегда есть вариант купить другой принтер. По затрате человеко-часов на зарабатывание 4000 рублей или сколько он там стоит и на настройку того принтера, что есть далеко не всегда побеждает второе.
---
Впрочем, признаю, что могут быть обстоятельства, делающие невозможным предложенное мной.
ответить
Смысл в том,
Смысл в том, чтобы оставить резервную возможность сделать что-либо в windows на случай если в linux быстро не получится, а сделать надо срочно.
в 2009 году у меня на настройку принтера в linux ушло полгода, а на настройку сканера -- полтора.
И понятно почему: как только вам срочно нужен был принтер или сканер, вы тут же перезагружались в винду, вместо того, чтобы серьёзно заняться его настройкой в линуксе. Так полтора года и пролетело. ;)
ответить
Бггг, и это ведь
Бггг, и это ведь даже не я сказал :-)
ответить
Срочно -- на то и
Срочно -- на то и срочно, что уже нет времени что-то настраивать, результат нужен быстро, прямо сейчас и на практике, а не в будущем в теории. А в фоновом режиме, естественно, есть смысл разбираться и настраивать. Но это может получиться не сразу -- как повезёт с оборудованием.
ответить
в 2009 году у меня
в 2009 году у меня на настройку принтера в linux ушло полгода, а на настройку сканера -- полтора.
-----------------------------------------------------------
У меня то же самое было, когда одной знакомой на Виндовс 10 надо было запустить сканер. Принтер работает, а сканер отказывается. И драйвер не сайте производителя есть, а толку - ноль. И было это не в 2009, а в 2020 году. Мне надо было перелопатить Интернет, пока я нашел программку, которая позволила запустить сканер.
ответить
Если пришлют файл
> так это что же, каждый раз, когда очередное ламо что-нибудь эдакое пришлёт, комп перезагружать?
На самом деле, нет. По крайней мере для распаковки архивов точно не нужно перезагружаться. Программы которые работают на Windows нужны очень редко и для специфической цели объяснить этому самому ламо как что-то сделать в Windows, так как если у тебя самого нету Windows. то на словах объяснить сложно, а если есть можно прислать скриншоты где обвести красным куда нажимать.
Но и для этих целей проще и удобнее завести виртуалку, пусть даже она медленная, но для снятия пары скриншотов это не важно.
ответить
Я для
Я для распаковки таких архивов запускаю виндовый разпаковщик под wine. Не знаю, есть ли менее извращённый способ.
ответить
Вроде есть, по
Вроде есть, по крайней мере мне пока что удавалось все архивы раскрыть, какие мне виндузятники присылали. Wine у меня нет :-)
ответить
Целесообразность использования мастдайки
Интересное мнение )
Обычно на винде сидят либо дотнетчики (тут как бы вообще без вариантов), либо джависты. Все остальные - всякие там пхписты, питоняши и другие программирующие пользователи используют обычно Linux.
Если человек разборчив в инструментах, то с джавой и дотнетом он связываться явно не будет, соответственно винда ему не нужна от слова совсем.
безмозглый товарищ-виндузятник прислал zip-архив с русскими буквами в именах файлов
Вот это прямо классика среди пользователей мастдайки. Перед глазами сразу возникают канонические образы 1С-"программистов", "разработчиков" макросов Excel и прочих виндовс-товарищей.
Возможно и существуют, к примеру, грамотные дотнетчики, но вот в целом мастдайка и её пользователи серьёзно как-то не воспринимаются.
ответить
Да при чём тут
Да при чём тут дотнетчики, джависты и выбор инструментов? Далеко не все люди, с кем я общаюсь, являются программистами. И большинство из них пользуется windows.
ответить
По-моему, к
По-моему, к данному конкретному обсуждению сие вообще никакого отношения не имеет, речь изначально шла о программистах.
ответить
Изначально --
Изначально -- да, но ведь вы сами в своей книге отмечаете, что будущему программисту необходимо не просто программировать под UNIX, а делать там всё (или практически всё), для чего он вообще использует компьютер. Так вот для этого придётся научиться взаимодействовать с другими людьми, работающими в том числе из под windows. Иначе у будущего программиста сложится впечатление, что linux -- это изолированная среда, оторванная от происходящего в реальной жизни.
Впрочем¸ среди программистов виндузятники тоже встречаются. И далеко не только на дотнете или джаве (среди джавишников, кстати, линуксоидов тоже хватает), а на том же C++. И при разработке кроссплатформенного проекта вполне возможна ситуация, когда один разработчик под linux случайно закоммитил в git два файла с одинаковыми именами, но в разном регистре (в linux это два разных файла), а потом другой разработчик уже под windows забрал себе эти изменения , и git-у снесло крышу, потому что винда так не умеет. Другой пример -- под linux закоммитили два каталога -- gui и con, а в windows начались проблемы из-за того, что ни файл, ни каталог с именем con там создать нельзя, так как в windows это зарезервированное имя ещё со времён dos. Наконец, пресловутое чтение бинарных файлов, где в windows при открытии файла необходимо открывать его как бинарный, иначе с байтами OD и OA начнёт происходить какая-то дичь. И квалифицировнному программисту нужно уметь разруливать подобные ситуации, а не выпадать от этого в осадок, растекаясь тонким слоем по клавиатуре.
ответить
Пережиток истории
Ну тогда разве что на виртуалку винду ставить. А лучше - пытаться убедить пользователей перейти на нормальную ОС )
А вообще, винда - это уже практически пережиток истории.
ответить
Ну тогда разве
Ну тогда разве что на виртуалку винду ставить.
На виртуалку не всегда удобно, кроме того, при этом слетит лицензия винды, которая шла вместе с ноутом. Покупать отдельную лицензию для виртуалки -- это перебор, а ставить пиратку -- тоже такое себе.
А лучше - пытаться убедить пользователей перейти на нормальную ОС )
Это не всегда легко, к сожалению. Пока только одного удалось убедить. Но работы ведутся :)
А вообще, винда - это уже практически пережиток истории.
Судя по количеству пользователей на десктопах -- пока нет. Вы можете заявить, что Вас это не волнует, но тогда следует уточнить, что именно Вы вкладываете в понятие "пережиток истории".
ответить
"Лицензия" --
"Лицензия" -- понятие юридическое, она "слететь" не может. Слетит тут разве что неуклюжая и мерзкая защита от копирования. "Пиратка" лучше хотя бы даже тем, что в ней этой "защиты" уже нет.
ответить
Тем не менее,
Тем не менее, переходить в linux полностью, забыв про windows, на мой взгляд, не совсем правильно.
Вы отстали от прогресса. Вопрос "забыть про windows" среди прогрессивных (естественно, не в том смысле слова "прогресс", который упорно пытаются придать ему молодые талантливые маркетологи) людей давно уже не обсуждается. Сейчас на повестке дня вопрос, как долго ещё протянет линукс (с учётом как его нынешнего состояния, так и явно обозначившихся тенденций) и можно ли ещё что-нибудь сделать или уже пора начать забывать про него, как про систему, пригодную для жизни и работы человека, умеющего думать и стремящегося к свободе.
ответить
>> Тем не менее,
>> Тем не менее, переходить в linux полностью, забыв про windows, на мой взгляд, не совсем правильно.
Вы отстали от прогресса. Вопрос "забыть про windows" среди прогрессивных (естественно, не в том смысле слова "прогресс", который упорно пытаются придать ему молодые талантливые маркетологи) людей давно уже не обсуждается.
Фраза выдернута из контекста. Речь шла о процессе перехода с одной системе на другую, и о том, что этот переход должен быть плавным, а не резким, иначе вероятность успеха крайне низка.
Сейчас на повестке дня вопрос, как долго ещё протянет линукс (с учётом как его нынешнего состояния, так и явно обозначившихся тенденций) и можно ли ещё что-нибудь сделать или уже пора начать забывать про него, как про систему, пригодную для жизни и работы человека, умеющего думать и стремящегося к свободе.
А с linux-то что не так? С отдельными дистрибутивами -- мб. Но с ядром вроде всё в порядке, и дистрибутивы нормальные тоже есть. Или я что-то пропустил?
ответить
Бугагагага, это
Бугагагага, это с ядром-то всё в порядке?
У меня такое ощущение, что ядро ещё как-то держится исключительно на личном авторитете Торвальдса, у которого по внезапному совпадению, кроме авторитета, есть ещё и мозги. Но именно что "как-то держится", балансирует на грани. Если что с Торвальдсом случится (не обязательно сразу bus factor, вон наезд на него по поводу недостаточной политкорректности уже был) — вся эта конструкция пойдёт вразнос моментально. Образуется полсотни форков ядра, среди которых не будет ни одного сколько-нибудь на что-то пригодного.
ответить
этот переход
этот переход должен быть плавным, а не резким, иначе вероятность успеха крайне низка.
Если под "плавностью" подразумевается "оставить винду в дуалбуте", то совершенно неубедительно. Хотя бы и ваш личный пример показывает обратное: что винда в дуалбуте успешный переход на линукс скорее тормозит, чем помогает ему. Потому что, какой же это "успех", если вы до сих пор держите винду в дуалбуте и перезагружаетесь туда для выполнения довольно-таки элементарных операций, вроде распаковки архивов? Про "полгода настраивать принтер" тоже уже все
похихикаливысказались.Ну а про линуксовое ядро Андрей тут уже
поржалответил. Мне добавить, по большому счёту, нечего.ответить
Платон мне друг, но истина дороже
В своё время у меня винда (Windows-95, чур меня) жила в дуал-буте года два, наверное. Причём я с линуксом обращаться уже умел, то есть я в 1994 году начал с ним работать как с системой, хорошо сочетающейся с Интернетом, но дома его поставил только в декабре 1996, когда пошёл работать в ISP... э... точнее, скорее будет так -- пошёл строить ISP, не умея этого :-) Но в итоге построил. Так вот, с этого самого декабря 1996 до примерно середины 1998 у меня таки винда стояла дуальной системой. Потом она в очередной раз "протухла", надо было вроде её переставить, но я внезапно понял, что под виндой у меня ничего, кроме игрушек, не осталось, да и в те давно уже играть некогда.
Если бы нужно было уходить с винды резко, скачком, то я-то, может, это и сделал бы, но не все так могут.
ответить
Ну пара лет --
Ну пара лет -- это, всё-таки, не 10 лет.
Я сам, вынужден с сожалением признать, пользовался виндой в общей сложности дольше, чем она того заслуживает. Подробности теряются в тумане памяти, но примерно в 1997 я перешёл с доса на линукс (трёшка, т.е. i386, у меня тогда была, кажется), а где-то через пару лет, обновив железо, установил вин95. И до примерно 2007 у меня на домашнем компе основной системой была периодами по несколько лет то линукс, то винда (сначала 95, а потом и XP). И только после 2007 я оставил винду уже окончательно и бесповоротно.
Но что касается дуалбута, мне он всегда казался распыляющим моё внимание. Жить нормально на две системы мне никогда не удавалось. Поэтому, если уж переходить на линукс, так переходить совсем. Это несложно, я (вспоминая Марка Твена) много раз это делал. ;)
Хотя вот сейчас у меня у самого стоит линукс и OpenBSD в дуалбуте. :) Впрочем, линукс я последний раз загружал года полтора назад, минут на 10, что-то посмотреть надо было. :)
Желающим перейти на линукс оставлять винду в дуалбуте я бы рекомендовал только в качестве моральной поддержки. Чтобы первое время было не так страшно, что "я вот винду снесу, а потом в линуксе ничего сделать не смогу, если срочно понадобится". Ну и через год-полтора потребность в дуалбуте должна отпасть полностью. Иначе можно констатировать, что перехода не получилось.
А если два-три раза в год возникает суровая необходимость запустить виндовую прогу, то любой способ мне кажется лучше дуалбута, будь то wine, виртуалка, старый ноут с виндой и проч.
ответить
☞ From Anonymous (unverified) Wed Oct 21 14:03:00 2020 UTC
warning: no newline at end of file
Здравствуйте! У меня тут с товарищем спор возник.
У него C компилятор ругается на отсутствие конца строки в файле и в ответ на все аргументы утверждает, что его текстовый редактор и так строки считает (у wc -l на одну меньше получается), конкатенировать файл через консольный cat он не собирается и тд.
В итоге он начал писать то же самое на D, где компилятору на отсутствие \n в конце файла пофиг.
Может у вас какие-то аргументы есть или мысли по этому поводу есть? Да, система у него Windows, поэтому на аргумент "в Posix так написано" не реагирует.
ответить
Во-первых, если
Во-первых, если человек пишет под Windows, то не всё ли равно, на чём он будеть писать? Путь хоть на коболе свои програмки кропает. Windows — это диагноз, и в большинстве случаев безнадёжный.
Во-вторых, "в Posix так написано" — это и для меня не аргумент. Это вообще не аргумент. Мало ли чего где написано, на заборах вон тоже пишут.
В-третьих, не надо использовать такой редактор текстов, который в конце не ставит перевод строки. А если всё-таки используете (например, Joe этим славится) — не забывайте проверить, что сами этот Enter нажали где надо. Потому что корректный текстовый файл состоит из законченных строк, то есть в нём каждая строка, включая последнюю, должна завершаться символом перевода строки. И это безотносительно всевозможных позиксов и прочих хренозиксов.
В-четвёртых, вот чего я категорически не понимаю, так это при чём тут cat.
ответить
> в нём каждая
> в нём каждая строка, включая последнюю, должна завершаться символом перевода строки.
А откуда это взялось, если не из POSIX?
И насколько это можно считать универсальным?
А то, у меня сложилось впечатление, что это примерно как разные соглашения по формату текстовых файлов. В Windows принято использовать \r\n как разделитель строк, а в UNIX \n как терминатор строк, например. И так же в Windows принято в начале файлов с UTF-8 ставить невидимый символ BOM, а в UNIX не принято. И так далее.
ответить
"Это взялось"
"Это взялось" лет за двадцать до позикса. Что вообще за бредни? От стандартов, включая позикс, никогда, нигде, никому не было никакой пользы, эти комитетские бастарды создаются низачем, а деятельность комитетов всегда, практически по определению, вредоносна.
Между прочим, абсолютно бессмысленный BOM в начале файла в utf-8 — пример того, что бывает, если апеллировать к комитетским подельям вместо того, чтобы включить мозг. Что касается CRLF, то windows тут вообще ни при чём, CRLF используют практически все текстовые протоколы в Интернете, и возникло это всё задолго до Windows, в самом начале восьмидесятых. И, кстати, всегда использовалось именно как признак конца строки, а не "разделитель строк" -- про последнее я вообще никогда не слышал.
ответить
> абсолютно
> абсолютно бессмысленный BOM в начале файла в utf-8
Кстати, я думал так же, а потом в итоге мне пришлось его вставлять в некоторые из своих текстовых файлов чем-то вроде
{ xxd -p -r << bar.txtА всё потому, что, если сервер (не мой!) в HTTP-ответе пишет
Content-Type: text/plainвместо
Content-Type: text/plain; charset=UTF-8то Firefox (другие браузеры не проверял) вначале показывает текст в кодировке CP-1251 и её приходится переключать в меню View → Text Encoding на UTF-8. А вот, если добавить BOM, то он распознаёт UTF-8 сразу.
> вот чего я категорически не понимаю, так это при чём тут cat.
Мой главный аргумент был насчёт того, что отсутствие терминатора в конце последней строки ломает просмотр файлов в консоли через
cat foo.txtв bash и некоторых других шеллах и конкатенацию файлов везде.> "разделитель строк" -- про последнее я вообще никогда не слышал.
Судя по всему, так считают разработчики многих текстовых редакторов, особенно тех что под Windows.
ответить
мне
мне пришлось
Как нынче говорят, прогиб засчитан.
если сервер (не мой!) в HTTP-ответе пишет
Откройте для себя .htaccess и другие способы управления HTTP-сервером, включая mime-types. Если сервер не указывает кодировку для текстового файла, отдаваемого в чём-то кроме ASCII, он криво настроен.
На крайняк можно ещё текстовый файл превратить таки в HTML, там в заголовке свои средства указания кодировки. Но вообще это потребоваться не должно.
Firefox (другие браузеры не проверял)
Можно ещё дефолтную кодировку сменить в настройках браузера. Но вообще-то не нужно. Правильно сделать так, чтобы всё было правильно (tm), а не городить одни костыли на другие. Вообще-то браузер совершенно не обязан пытаться детектить и как-то там угадывать кодировку текстового файла, и тем более делать это по BOM'у. Я бы даже сказал, что он тут занимается самодеятельностью, за которую надо бить по рукам.
особенно тех что под Windows.
Вот уж чьё мнение меня вообще будет беспокоить в самую последнюю очередь.
ответить
Сервер не мой, я просто размещаю файл
> он криво настроен.
Я знаю.
> На крайняк можно ещё текстовый файл превратить таки в HTML
Нельзя. Сервер не даст залить файл с расширением кроме .txt, а если переименовать html в txt, то отдавать всё равно будет с типом text/plan. Да и в любом случае превратить текст в HTML сложнее, чем добавить BOM.
> Откройте для себя .htaccess
У меня есть только доступ через веб-интерфейс для заливки файлов по одному, которые при этом проверяются как минимум по расширению (а может и ещё как-то). Я же специально в скобках написал, что сервер не мой.
> Вообще-то браузер совершенно не обязан пытаться детектить и как-то там угадывать кодировку текстового файла
Ну а почему бы и нет? Логично если не указана кодировка, предполагать UTF-8, если же UTF-8 не валидный, то показывать в дефолтной восьмибитной кодировке, которой логично выбрать cp1251, поскольку для текста на русском она наиболее распространена после UTF-8. А вот уже между восьмибитными кодировками автоматом детектить сложно.
> Я бы даже сказал, что он тут занимается самодеятельностью, за которую надо бить по рукам.
Ну, когда ты нажимаешь на ссылку и сразу видишь текст — это удобнее, чем когда ты нажимаешь на ссылку и потом ищешь в меню "кодировки" и только тогда видишь текст. Тем более что Firefox может файлы и в локальной файловой системе открывать, а там-то никаких заголовков заведомо нету.
ответить
Ещё раз, и
Ещё раз, и медленно: костыли — не метод. Варианты: дать по шее админу сервера; отказаться с ним работать; настучать на него начальству; сменить место работы. Вариант с BOM'ом — не решает вообще ничего, проблема криво настроенного сервера остаётся и никуда не девается.
ответить
> проблема
> проблема криво настроенного сервера остаётся и никуда не девается.
Сервер криво настроенным остаётся. Верно.
Firefox кодировку определять не учится. Тоже верно.
Но это не проблема, а причины этой проблемы. А сама проблема — это отображение текста браузером в неверной кодировке.
Если добавить BOM в файл, проблема решается для одного конкретно взятого файла. Ещё можно было бы переконвертировать его в Windows-1251 и залить.
> костыли — не метод.
А как это понимать? Существует определенное возможное действие. Если его выполнить, то будет достигнут желаемый результат. Другие варианты достигнуть этого же результата по тем или иным причинам или не работают (пинать админа) или условно-хуже (заливать в cp1251).
Что считать костылями, а что нет — субъективно. Единственная объективность: универсальное решение (все файлы) против частного (залитые мной). Если я не могу применить универсальное решение (исправить настройки сервера), то зачем отказываться от работающего частного решения (добавить BOM в мои файлы)?
Есть ли вообще объективное определение костылей? Или так называется любое субъоптимальное техническое решение?
> Варианты:
Это сервер для публикации художественной литературы (стихи, рассказы), поэтому три варианта сразу отпадают. Публиковать где-то ещё — можно, но почему бы не опубликовать одновременно на нескольких площадках, расширив охват аудитории?
----
Да и вообще, я не спрашивал, как решить эту проблему, а просто упомянул, что не смотря на то, что в теории BOM не нужен, на практике бывают ситуации, когда он внезапно выполняет возложенную на него задачу. Я сам был удивлён, но это сработало.
ответить
Так-с. Ну для
Так-с. Ну для начала:
> А как это понимать?
> Что считать костылями, а что нет — субъективно.
Категорически нет. Костыли — это вполне определённый подход, когда имеется техническая проблема, но её не исправляют, а "обходят" (есть такое меткое английское слово workaround) по принципу "на каждую хитрую Ж у нас найдётся вот этот вот самый винтом". Причём этот вот самый "винтом" либо исходно не предназначен для данной ситуации, либо вообще изобретается на лету конкретно под неё.
Далее, почему костыли — это принципиально не метод и
> зачем отказываться от работающего частного решения (добавить BOM в мои файлы)?
Дело в том, что костыли обычно работают здесь и сейчас, но при этом нет никаких оснований предполагать, что они будут работать и дальше, не-здесь, не-сейчас, в следующей версии, в сочетании с другим ПО и т.д. Использование костылей делает всю конструкцию шаткой и хрупкой.
> в теории BOM не нужен, на практике бывают ситуации, когда он внезапно выполняет возложенную на него задачу.
Вот именно что на BOM никто никогда не возлагал ЭТУ задачу. BOM (byte order mark, есличо) предназначен, чтобы для случая многобайтовой юникодкой "кодировки" определить, какой используется порядок байт в целых числах — little-endian или big-endian. Для UTF-8 порядок байт в целых числах не интересен вообще ни с какой стороны, поскольку она многобайтовых целых чисел не подразумевает. Но поскольку в комитетах никогда не заседают умные люди, а только агрессивные дебилы и неагрессивные, но при этом полностью безмозглые овощи, соответствующий комитет в какой-то момент заявил, что, видите ли, BOM должен присутствовать в начале _любого_ юникодного файла. При этом, по правде говоря, они никак не специфицировали, что же надо делать, если файл вообще-то бинарный, но включает в себя юникодные строки (например, исполняемый со строковыми константами, или архив, в котором есть имена файлов, или ещё что подобное), поскольку тот моральный урод, который это придумал, разумеется, вообще не думал о том, что строки не всегда занимают файл целиком. Да он вообще ни о чём не думал, поскольку думать в комитетах не умеют.
Как результат, единственный вариант юникодной кодировки, которая хоть как-то напоминает текст (в отличие от бинарных форматов, каковыми изначально являются UCS2, UCS4 и UTF16) таки тоже окончательно превратился тоже в бинарный формат (с заголовком -- а текст заголовка иметь не может) и потерял совместимость с ASCII. Как следствие, нормальные психически здоровые люди данный конкретный высер комитетского мышления игнорируют.
Теперь вот ваш случай. Чёрт подери, сервер _обязан_ отдавать кодировку для типа text/plain, если только это не ASCII (а оно не ASCII). Браузер, опять же, вообще-то не имеет права никаких догадок строить, если text/plain и не указана кодировка -- то это ASCII. Автоопределение кодировки по BOM'у -- это именно что костыль, который не обязан присутствовать в других браузерах (вообще-то, я бы сказал, обязан отсутствовать) и притом костыль крайне неприятный, поскольку поощряет, как в вашем случае, совершенно безумную практику включения BOM в UTF-8.
Вы вообще связаться с администрацией сервера пробовали? Ну, там, объяснить, что кодировки разные бывают, что вообще-то сервер некорректно настроен, что стоило бы дать возможность для текстовых файлов указывать кодировку, ну или хранить их все на сервере в одной кодировке и при получении в неё перекодировать, а отдавать с указанием кодировки? Если не захотят фиксить -- валить оттуда нафиг, а не городить костыли.
Кстати, перекодировка в 1251 -- это намного меньший костыль, нежели BOM.
ответить
> "разделитель
> "разделитель строк" -- про последнее я вообще никогда не слышал.
А он есть. Правда я не понял, зачем он нужен и подозреваю, что не нужен:
https://ru.wikipedia.org/wiki/Перевод_строки#В_Юникоде
По стандарту, любое совместимое с Юникодом приложение должно воспринимать как перевод строки каждый из нижеследующих символов:
* LF (U+000A): англ. line feed — подача строки <ПС>;
* CR (U+000D): англ. carriage return — возврат каретки <ВК>;
* NEL (U+0085): англ. next line — переход на следующую строку;
* LS (U+2028): англ. line separator — разделитель строк;
* PS (U+2029): англ. paragraph separator — разделитель абзацев.
Последовательность CR+LF (U+000D U+000A) надлежит воспринимать как один перевод строки, а не два.
Только по-моему это пример, когда придумали какую-то фигню.
Кстати NEL…не работает у меня.
И LS тоже не работает.
Да и PS — тоже нет, по крайней мере в этой форме.
А вот одиночный CR
работает, да и LF
Тоже. Набирал через ctrl-shift-u и 16-ричный код.
ответить
Я имел в виду
Я имел в виду несколько иное. Я привык к тому, что LF или CRLF — это такая штука, которая завершает строку. А словосочетание "разделитель строк" подразумевает, что этот разделитель не "завершает" строку, а "отделяет одну строку от другой". Разница именно в том, что в первом случае в конце файла ОНО быть должно, а во втором — нет. Ну вот примерно такая же ситуация в Паскале и Си с точкой с запятой, в Си она _завершает_ оператор (и не всякий притом), а в Паскале ставится _между_ операторами. Как следствие, в Паскале перед закрывающей операторной скобкой (словом end) она не нужна, а в Си — нужна.
А ещё вот это вот:
> Только по-моему это пример, когда придумали какую-то фигню.
Вообще-то это скорее про весь Юникод. И вообще про любое комитетское поделье.
ответить
☞ From Anonymous (unverified) Fri Oct 16 21:16:00 2020 UTC
Когда будут
Когда будут новые видео на infoviolence? :)
ответить
Мне это самому
Мне это самому интересно :(
ответить
☞ From Anonymous (unverified) Thu Oct 15 02:34:00 2020 UTC
Вред побочных эффектов
Андрей Викторович, здравствуйте! Читаю четвёртый том (в части до Си++) и у меня возник вопрос: почему побочные эффекты вообще вредны при восприятии программы? Во множесте слов о том, что они вредны у меня не получается понять почему они вредны.
К слову, моим первым ЯП был Си и, видимо, это наложило свой отпечаток в моём восприятии, поэтому прошу меня извинить, если вопрос покажется глупым.
Четвёртый том немного непросто воспринимать, но от того он не менее интересный. Спасибо Вам.
ответить
Да ведь очевидно же
В общем случае побочные эффекты увеличивают сложность восприятия программы, превращая отдельные её фрагменты в ребусы, которые требуется разгадывать. Больше того, вообще побочный эффект как явление противоречит привычкам условного новичка, мышление которого ещё не изогнулось под программистские реалии. Дело тут в том, что с математикой (и, соответственно, с выражениями) люди сталкиваются обычно раньше, чем с программированием, так что от выражения как-то так подсознательно не ожидают, что оно начнёт себя как-то вести, вместо того чтобы просто превратиться в значение. С восприятием условных выражений в заголовках ветвлений и циклов всё ещё хуже: весь наш опыт, включающий раннее знакомство с алгоритмами вне программирования, просто-таки восстаёт против каких бы то ни было побочных эффектов в них, ведь там же просто сравнение. Вот это вот "просто сравнение" в мозгу может засесть настолько прочно, что люди вообще не могут в заголовке if или while написать что-то отличное от сравнения — вызывают, к примеру, логическую функцию, а результат её, вместо того чтобы просто оставить как есть, сравнивают с true. А любые проявления когнитивного диссонанса отнюдь не способствуют комфортности чтения кода.
Даже когда все эти трудности успешно преодолены, побочные эффекты остаются источником ребусов в коде, потому что, например, происходят в не всегда очевидной, а часто и в совсем неочевидной последовательности. Если не верите, вспомните про несколько побочных эффектов в выражении на том же Си и небезызвестные точки гарантированных вычислений -- и это мы ещё функции вызывать не начали.
Между прочим, всё это более-менее очевидно для всех, кроме тех, кто начал программировать с Си и получил ту самую пресловутую "сишность головного мозга". Потому и нельзя с Си начинать.
ответить
Ассемблер
С восприятием условных выражений в заголовках ветвлений и циклов всё ещё хуже: весь наш опыт, включающий раннее знакомство с алгоритмами вне программирования, просто-таки восстаёт против каких бы то ни было побочных эффектов в них, ведь там же просто сравнение. Вот это вот "просто сравнение" в мозгу может засесть настолько прочно, что люди вообще не могут в заголовке if или while написать что-то отличное от сравнения — вызывают, к примеру, логическую функцию, а результат её, вместо того чтобы просто оставить как есть, сравнивают с true.
Если человек сравнивает результат логической функции с одним из возможных возвращаемых значений, то это говорит только лишь о том, что он не понимает происходящего на уровне "железа".
Pешить проблему можно практикой на ассемблере.
ответить
Ассемблер-то
Ассемблер-то тут при чём? На уровне ассемблера переходы делаются по флажкам, так что ежели мы CALL'ом вызвали логическую функцию, а потом ещё и стек очистили (обычным ADD'ом, замечу -- то есть флажки по-любому испортили, хотя их и функция не ставила -- не через флажки же она результат возвращает), нам этот несчастный EAX или кто там, RAX, шмакс, в общем аккумулятор, в котором результат лежит, придётся именно что сравнивать. Мы, конечно, вместо честного CMP напишем TEST EAX, EAX, но факта сравнения это не отменит.
ответить
Всё верно
TEST EAX, EAX
Естественно, что без сравнения не обойтись, но отсюда явно видно, что в if'е нужно просто проверить значение, которое вернула функция, а не сравнивать сначала это значение с true, а зачем проверять результат этого сравнения.
ответить
Не, не понимаю
А чем, собственно говоря, это вот test eax, eax не сравнение с true? (на самом деле с false, но это детали)
ответить
true в заголовке
Да всё правильно - это проверка по условию.
Просто выше вы писали:
люди вообще не могут в заголовке if или while написать что-то отличное от сравнения — вызывают, к примеру, логическую функцию, а результат её, вместо того чтобы просто оставить как есть, сравнивают с true
Я про то, что с помощью
test eax, eax(по крайней мере мне так кажется) проще понять, что сравнение с true в заголовке не нужно.
ответить
Видимо,
Видимо, проблема в том, что мне так не кажется :-)
ответить
Абсолютно не
Абсолютно не согласен. Огромное количество программистов не испытывает проблем с восприятием логического выражения как отдельной сущности, но при этом ассемблер даже на картинках не видели.
Ассемблер -- это совсем про другое. Тем более, что если включить оптимизацию, то порождённый ассемблерный код в обоих случаях будет идентичным.
Когда человек пишет прикладной код на C или, тем более, C++, он, как правило, не задумывается о таких вещах, вне зависимости от того, понимает он, как это устроено на низком уровне или нет -- в этом весь смысл абстракции. Переходить к более низкому уровню имеет смысл либо в случае какой-то изощрённой оптимизации, и нам действительно важно, какой именно код породил компилятор, либо в случае, когда программа начинает вести себя странно, то есть, когда наша абстракция "протекла".
Здесь же речь именно о восприятии двоичной логики как отдельной алгебраической структуры со своими операндами и операциями и с пониманием того, что условие в if-е -- это выражение из алгебры логики.
ответить
В целом согласен
В целом согласен, но по поводу "отдельной" алгебраической структуры тут скорее как раз наоборот — люди логику воспринимают как нечто "совсем отдельное", тогда как на самом-то деле это лишь одна алгебра из многих: сколько типов в программе, столько и этих алгебр, булева лишь одна из них.
ответить
☞ From farvater
Sat Oct 10 09:09:00 2020
UTC 
Защита памяти операционной системой и С++
Здравствуйте. Нахожусь в процессе чтения четвертого тома (Части о C++). Насколько я понял, полимофизм адресов возоможен в одну сторону, но не в обратную. Таким образом, логичо предположить, что если все-таки такое неправильно преобразование сделать, то наша программа обратится к недоступной ей памяти, куда ей ОС не разрешала обращаться и, следовательно, должна быть остановлена операционной системой. Для проверки
[остальной текст удалён для экономии места]
ответить
Откуда вы
Откуда вы вообще взяли такую хрень, а? Или даже так: как вообще, из какого места, каким образом в голову могла прийти такая бредятина?!
При чём тут операционная система, численное значение адреса не меняется при его преобразованиях хоть в ту сторону, хоть в другую (точнее, при множественном наследовании меняется, но я множественное наследование не зря отказался рассматривать), больше того, во время исполнения вообще никаких действий не выполняется в тех местах, где имеет место преобразование типов указателей. То есть указатель как указывал в некое (валидное вполне) место в памяти, так и продолжает туда указывать. Операционная система в принципе не имеет здесь никакого повода для недовольства, поскольку на уровне выполняемого (машинного) кода никаких преобразований не происходит, преобразование типа указателя -- это епархия компилятора и решается во время компиляции.
Судя по тому, какая ерунда у вас тут возникла, вы к Си++ приступили слишком рано. Бросайте это дохлое занятие и начинайте с азов -- Паскаль, язык ассемблера, чистый Си, причём именно в такой последовательности. И пока не напишете самостоятельно хотя бы одну или две программы объёмом в 2-3 тысячи строк каждая, причём такие, которые будет (добровольно!!! а не по вашей слёзной просьбе) использовать кто-то кроме вас -- даже не думайте о том, чтобы вернуться к изучению Си++. Если же такая рекомендация вам не нравится -- то идите ищите другого советчика.
На вопросы по Си++ здесь можете больше времени не тратить, я их не раскрою.
ответить
Прошу прощения,
Прошу прощения, я действительно сформулировал свой вопрос неправильно. Конечно, само по себе преобразование и не должно делать ничего плохого, но, именно, обращение к полям производного класса, которых там, в памяти нет (для них память не выделялась при создании объекта базового класса), это же вещь нехорошая.
ответить
И чего?
Мимо памяти, занятой одним отдельно взятым объектом, вы промахнулись, но это ещё совершенно не означает, что ваша программа при этом промахнётся мимо всей своей памяти. Память-то выделяется страницами, а они побольше будут, чем отдельные объектики. Если, скажем, слегка превысить размер переменной, находящейся в динамической памяти — никакого видимого эффекта это не даст (а лучше бы, конечно, дало), поскольку malloc/free работают с блоками -- размер их не документирован, но по факту там 64 байта квант (на разных версиях библиотеки может быть по-разному). Если переменная локальная в функции, то она находится в стеке, мимо него вообще ещё постараться надо промазать, хотя если промахнуться по-серьёзному, можно затереть адрес возврата и тогда всё, скорее всего, грохнется, но не по той причине, которой вы ожидали. Если переменная в сегменте данных (глобальная) -- то сам сегмент данных имеет размер, кратный странице (4 Kb), и когда глобальных переменных мало, промазать мимо всего сегмента тоже не столь тривиально.
А самое главное: если бы у вас был опыт практического программирования (который, подчёркиваю, необходимо получить до начала изучения Си++) -- то вот это вот всё вы бы знали не хуже меня.
ответить
А самое
А самое главное: если бы у вас был опыт практического программирования (который, подчёркиваю, необходимо получить до начала изучения Си++) -- то вот это вот всё вы бы знали не хуже меня.
Не факт. Регулярно вижу программистов на том же C++, работающих много лет, которые не только не разбираются в подобных "нюансах", но даже не считают для себя это нужным. А в ситуации, когда компилятор/программа/отладчик начинают вести себя странно, просто зовут кого-нибудь, кто поможет им разобраться. Зато они хорошо разбираются, например, в предметной области.
ответить
Си++ в связке с
Си++ в связке с STL вполне допускает макакокодинг, то есть написание программ без понимания происходящего. Это не новость.
В данном конкретном случае имеет место вот что: я, как автор книги, неоднократно подчёркиваю, что сначала надо осваивать Паскаль, язык ассемблера и чистый Си, и лишь после этого можно думать об изучении Си++; человек приходит задавать вопросы по Си++, при этом лично мне совершенно очевидно, что ни на Паскале, ни на чистом Си, ни тем более на асме он всерьёз не писал. Ну так вот если его не устраивает моя методика, то пусть он хотя бы вопросы не мне задаёт, а кому-нибудь другому.
Если что, нет, всерьёз писать на чистом Си без понимания происходяшего невозможно в принципе. Этот язык для макакинга непригоден. Ассемблер — тем более. Да даже и Паскаль, если в нём использовать указатели и динамическую память, тоже весьма сильно сопротивляется макакингу, а без указателей там толком и не написать ничего.
ответить
☞ From farvater
Mon Oct 5 19:16:00 2020
UTC 
Вопрос по C++
Здравствуйте, не могли бы вы подсказать, пожалуйста. В процессе написания класса столкнулся с такой неожиданной вещью и не могу понять, почему так происходит. Следующий код не проходит компиляцию: g++ пишет
ISO C++ says that these are ambiguous, even though the worst conversion for the first is better than the worst conversion for the second:
12 | a * 5;
| ^
t.cpp:3:16: note: candidate 1: ‘int operator*(const A&, int)’
3 | friend int operator* (const A& a, int b);
| ^~~~~~~~
t.cpp:6:9: note: candidate 2: ‘void A::operator*(const A&)’
6 | void operator*(const A& a) {}
Насколько я понял, он не может определиться какой operator* использовать (хотя в одном случае необходимо привести int к A, а в другом типы четко совпадают)
class A { public: friend int operator* (const A& a, int b); A () {} A (int) {} void operator*(const A& a) {} }; int main() { A a; a * 5; return 0; } int operator* (const A& a, int b) { return 0; }Но если убрать все const ссылки (или просто убрать везде ссылки, но оставить const), а передавать все по значению, то никаких ошибок нет.
И самое странное для меня: если изменить
void operator*(const A& a) {}на
void operator*(const A& a) сonst {}компилятор тоже перестает жаловаться.
ответить
С добавлением
С добавлением const к операции как раз всё понятно -- операции допускается перегружать по признаку константности аргумента. Далее, если из заголовка операции, которая метод класса, убрать const -- то её параметром уже нельзя будет делать временный/анонимный объект, так что она оказывается не у дел при вызове, требующем преобразования. Хуже с фразой про ISO: за ней явно стоит недоумение разработчиков gcc очередной нормой стандарта, так что это просто лишнее подтверждение необходимости физического уничтожения всех, кто входит в комитеты (любого рода).
А теперь самое главное: чёрт подери, ну не надо так делать! Вот просто не надо и всё. Или член класса, или внешняя функция. Кстати, если вы думаете, что она обязана быть friend, то вас жёстоко нае^Wобманули, это вообще довольно распространённое и совершенно дикое заблуждение, что-де операцию можно или членом, или другом класса. Спасибо идиоту Шилдту.
Но главное тут то, что в практической задаче подобная хрень никогда не вылезет, а если вылезла -- то вы что-то не то делаете. Вопросы о том, как в такой ситуации поведёт себя компилятор и как он "должен" себя вести -- из тех, что никогда не должны никого интересовать.
ответить
☞ From Anonymous (unverified) Fri Oct 2 16:49:00 2020 UTC
program CharInput;var
program CharInput; var c: char; begin while not eof do begin read(c); if c = #10 then writeln else writeln(c) end end.Почему эта программы, если ей, например, передать fff выведет три буквы f.Ведь char он же однобайтовый. Он, наверное, должен сохранять первый символ, а остальный отбрасывать. Тут он выводит 3 f это значит, что char подставляет каждый введенный символ поочереди или что?
ответить
Честно говоря,
Честно говоря, мне вообще непонятен ваш вопрос. У вас на каждый read выполняется writeln. Какая разница, char'ы тут, не char'ы, однобайтовые, многобайтовые — что прочитали, то и отдаём, всё, все свободны. С какого бодуна тут что-то должно отброситься?
На всякий случай: если эту программу запустить, ввести fff и нажать Enter, ваш цикл прокрутится четыре раза — по одному для каждой введённой буквы f и один раз для символа перевода строки.
ответить
☞ From Антон (unverified) Fri Oct 2 13:10:00 2020 UTC
Здравствуйте,
Здравствуйте, подскажите пожалуйста, с какого возраста возможно давать на изучение ваши книги детям и стОит ли детей сначала поднатаскать на scratch. Учатся в 3 и 5 классе. Любят строить объекты в блокстрайк,заглядываются в электронные книжки по ruby и go,как бы не навредить.
ответить
Вопрос не совсем по адресу
Я не педагог (в строгом смысле — то есть я не специалист по обучению детей), и возрастную психологию никогда не изучал, но думаю, что мои книги можно "давать" в любом возрасте, в котором ребёнок их согласится "взять". Подсуньте ненавязчиво и посмотрите, что будет.
Только учтите, Linux они сами не поставят, в терминал сами не залезут. И заставлять их туда лезть бесполезно — получите эффект отторжения. Так что разве что личным примером.
И нет, scratch не об этом. Вообще.
ответить
Хозяин сайта
Хозяин сайта ответил на вопрос, поэтому позволю себе вставить 5 копеек. Тут где-то в обсуждениях проскакивал "крик души" человека, закончившего 7 классов и столкнувшегося с трудностями при понимании математического минимума, изложенного в 1 томе "Введения в профессию". 5 и 3 классы - всё же несколько другой уровень. В этом возрасте с "вот непонятно вот прям тут" достаточно столкнуться на первой-второй странице, чтобы потерять всякий интерес и тягу к предмету, да и тяжеловато для школьника вообще (даже для выпускника, что уж там о "началке") принять факт, что нужно если не прочитать, то хотя бы пробежать глазами книжку в ~500 страниц, которая, несмотря на толщину едва ли не большую,чем все учебники за год, не делает "кулхацкером" (внезапно!), а просто вводит в курс дела и задаёт вектор, в котором следует двигаться дальше.
Я бы посоветовал знакомить детей такого возраста с программированием в игровой форме и постепенно подводить к концепции ЯП. Есть довольно много головоломок, завязанных и на программировании, и на решении алгоритмических задач вообще. Могу порекомендовать, например, игру от Tomorrow Corporation - Human Resource Machine (внимание, здесь и далее - проприетарщина, хотя, судя по упоминанию Block Strike, это не проблема). Игрушка о трудовых буднях офисного работника, под строгими взглядами начальства перекладывающего корреспонденцию с конвейера на конвейер в соответствии с написанной пользователем программой по определенному ТЗ. Программы составляются из графических блоков, причем весьма низкоуровневых (input, output, add, sub, jmp и т.д.), но могут быть скопированы в текстовый редактор в этаком "ассемблерообразном" виде. Можно будет на определенном этапе показать ребёнку, во что превращается его программа из блоков, чтобы стать понятной машине - вот и переход к ЯП. Ещё интересные головоломки у Zachtronics - Infinifactory (похожая на популярные нынче "кубические" песочницы вроде Minecraft или того же Block Strike), Spacechem, Opus Magnum и т.д. Если почувствуете, что ребёнку интересно - можно попробовать тот же Паскаль по первой части "Введения", а дальше видно будет. Конструктор игрушек какой-нибудь простенький можно поковырять со скриптованием (Love2D, например; это, правда, фреймворк и едва ли для новичков, но какие-то азы можно дать), дети как-то охотнее самостоятельно нарисованный мячик по экрану гоняют, чем считают корни квадратных уравнений, а эффект сопоставимый. Можно и в готовую игрушку, допускающую моддинг, влезть (там частенько скрипты на Lua).
При знакомстве с ЯП есть определённая проблема в отсутствии нативного понимания детьми английского, пусть даже и минимального набора слов. Где-то в интернетах попадался комментарий в духе "как вижу программу я и как видит её мой сын", где на первой картинке условный "хелловорлд", а на второй - мешанина из китайских иероглифов и цифр. Хотя дети сейчас изучают английский со 2 класса, а не с 4-5, как раньше, но сомневаюсь, что вот прям "шпрейхают на инглише" в этом возрасте.
В любом случае, чего точно лучше не делать в начале пути, так это сажать за Ruby, Python и прочий JavaScript. Языки, конечно, мегапопулярные нынче, но вот чему они точно не научат, так это культуре программирования. В этом смысле их, пожалуй, можно назвать "Бейсиками XXI века" (вспоминая меткое изречение Дейкстры). Go в этом плане чуть строже, там компилятор не даст пуститься совсем уж во все тяжкие, но сборщик мусора не приучит к бережной работе с памятью.
В общем, универсального совета здесь нет и быть не может. Присматривайтесь к своим детям и поддерживайте их интерес и начинания. Только не переусердствуйте - в этом возрасте еще сто раз поменяются и увлечения, и предпочтения, насильственно "увлекать" ничем не надо!
ответить
Можно пропустить
Да, в принципе школьник раздел математики может пропустить, ибо она у него в школе до 11 класса будет.
Так что подкачать мозг будеь еще шанс.
ответить
и что?
Читая любую книжку, каждый может прпопустить всё, что ему угодно. Но вот математика в том виде, в котором её "дают" в школе, подкачке мозга не способствует вообще совсем. Ну, если не считать спецшколы, где вменяемые педагоги.
ответить
Вот раскрыл
Вот раскрыл этот комментарий, а потом усомнился, что не зря.
Так или иначе, изложенное в этом комментарии с мнением владельца сайта не совпадает. Вообще практически ни в чём, кроме разве что последних двух абзацев.
ответить
☞ From P (unverified) Thu Oct 1 19:33:00 2020 UTC
Здравствуйте
Здравствуйте
У кого есть решение задачи про кубики из первой книги, где ответ 340?
Автор обучающей книги не дал объяснения решения задачи, как это обычно делается в обучающих книгах (
ответить
Бггггг.
Ну вот башен из одного кубика сколько будет разных? Четыре, так ведь? Цветов-то всего четыре.
А из двух? Первый кубик выбираем четырьмя способами, второй — тоже четырьмя, итого 4x4=16.
На каждую из таких башен (при том что они все разные) можно четырьмя способами пристроить ещё один кубик. Итого из трёх кубиков получаем 64 разные башни. А из четырёх — 256.
256+64+16+4 сколько будет? Вот, собственно, и вся задача.
На самом деле у меня есть очень плохая новость: если, дойдя до этого места в книге и притом зная ответ, читатель таки не смог построить решение, то всё, что в книжке написано, начиная с начала параграфа, с тем же успехом можно было и не читать. Увы, я не ставил и не ставлю перед собой задачи написать учебник комбинаторики, но такие и без меня есть; иначе говоря, я тут уже ничем помочь не могу, но есть, видимо, такие люди, которые могут.
ответить
А я не пойму
А я не пойму почему из 1 кубика можно построить 4 РАЗНЫХ башни, кубик же то всего один
ответить
В условиях той
В условиях той задачи можно построить четыре разных башни, каждая из которых состоит из одного кубика — поскольку кубиков четыре разных.
ответить
Можно, но вы
Можно, но вы пишите: "Ну вот башен из одного кубика сколько будет разных? Четыре, так ведь? Цветов-то всего четыре.". Так как их можно построить 4 если кубик всего 1 и соответственно 1-го цвета, то есть можно построить только 1 башню их 1-го кубика этого 1-го цвета. Или я просто не правильно что-то понял?
ответить
Вы просто фразу
Вы просто фразу разобрали не так, как её построил я. Вот есть такое понятие: "башня из одного кубика". Подобного рода понятия называются, если не ошибаюсь, "группой существительного". Вот я эту группу существительного поставил в родительный падеж множественного числа. Получилось "башен из одного кубика". Ну то есть таких башен, которые (каждая из них) состоят из одного кубика. А не все они из одного кубика, как это прочитали вы.
В принципе да, формально такой разбор, как у вас получилось, возможен и даже корректен, но из контекста разве не очевидно, что имеется в виду?
ответить
☞ From Serg (unverified) Thu Oct 1 13:51:00 2020 UTC
Здравствуйте,
Здравствуйте,
Прочитал вашу книгу "Оформление программного кода".
Интересные факты в книге и полезная информация!
Жаль что её не было когда я был студентом.
Спасибо!
ответить
☞ From Anonymous (unverified) Sat Sep 19 15:42:00 2020 UTC
О программах, говорящих по-русски
Добрый вечер, Андрей Викторович. Во 2-м томе "Введения в профессию" вы рассказываете об использовании gettext для "интернационализации" программ. В данном случае строки, выводимые программой, хранятся в отдельном файле и не изменяются. А как грамотно подойти к созданию программы, способной к обработке пользовательского ввода на русском (немецком, французском, турецком, etc.) языках? Например, какой-нибудь чат, в который нужно и писать самому, и читать присланные сообщения, или текстовый редактор. Или какая-нибудь "гуёвая" программа (да хоть на том же fltk), скажем, для создания сканвордов, в которой можно клацнуть по ячейке и вбить текст вопроса.
ответить
Не вполне понятен вопрос
Если говорить о чате или текстовом редакторе, то тут вообще неважно, какой язык. Текст -- он и есть текст. Принципиально только одно: никаких фрагментов на языках, отличных от английского, не должно быть в тексте программы, но для чата или редактора ничего подобного не нужно.
Несколько хуже, если программа в силу особенностей предметной области должна анализировать текст на естественном языке или синтезировать текст по определённым правилам. Простейший пример — в сообщении на русском языке выбрать правильную форму существительного, стоящего после числительного, вот эти вот все "одна собака" (именительный падеж единственного числа), "две собаки" (именительный падеж множественного числа), "пять собак" (не поверите, родительный падеж множественного числа). В таких случаях уже нужно смотреть на свойства предметной области и придумывать подходящие структуры данных, в том числе, возможно, для представления тех или иных правил. Так или иначе, даже в этой ситуации кириллические (и вообще не-английские) надписи в тексте программы не требуются.
ответить
Благодарю за
Благодарю за ответ; вопрос, пожалуй, и правда не совсем удачный получился, поэтому попробую перефразировать. В подавляющем большинстве случаев при обработке текстовых данных вне диапазона ASCII мы уткнемся носом в UTF-8 (в современных Unix-подобных системах, по крайней мере), так что вопрос, скорее, о многобайтовых кодировках вообще. Как обрабатывать строки в них? strlen честно посчитает байты, а не символы, пока не упрется в нулевой (хорошо хотя бы, что в валидной строке в UTF-8 в каждом байте будет установлен старший бит, т.е. '\0' среди строки не вылезет в любом случае), getchar тоже потеряет смысл как функция для чтения отдельного символа ("в лоб", по крайней мере). Существуют ли какие-то правила для оформления программ, функции в стандартной библиотеке Си, работающие с подобными данными (какой-нибудь условный strlen_utf8, чтобы strlen_utf8("Привет!") == 7, а не 13)? Или только, скажем так, "внешние" соглашения (ну вот должен быть тут UTF-8, и все), а чтение данных организовывать побайтно с анализом старшего бита?
ответить
Начать с того,
Начать с того, что "о многобайтовых кодировках вообще" разговаривать невозможно, поскольку это совершенно разные явления. Если данные в utf8 ещё как-то можно с натяжкой считать текстовыми, то остальные юникодные "кодировки" на текст не тянут, это совершенно очевидные бинарные форматы данных, ничем не лучше какого-нибудь jpeg или mp3.
В "стандарте" C99 есть поддержка для wide chars -- и, как и практически любой комитетский бастард, она не имеет никакого практического смысла. Что касается utf8, то вроде бы "стандартной" поддержки для неё нет, и это правильно -- её и не должно быть. Ну а простых (не "стандартных") библиотек для обработки utf8 существует, пардон, как грязи. Впрочем, если хочется просто посчитать буквы в строке (вот именно не байты, а буковки utf-8), то никакая нафиг библиотека для этого не нужна, достаточно при подсчёте игнорировать байты, начинающиеся с битов 10 (то есть имеющие значения 0x80 -- 0xBF), ради такого в проект затаскивать какую бы то ни было библиотеку -- просто нонсенс.
ответить
☞ From Anonymous (unverified) Thu Sep 3 11:49:00 2020 UTC
Самообучение не так просто
Добрый день, Андрей Викторович.
Вы неоднократно говорили, что человек может развиваться только сам, если адекватно развиватся. Про высшее образование понятно - оно лишь даёт вектор направления, а программист будет по этому вектору развиваться сам. А вот если недопрограммист пойдёт куда-нибудь, например в ШАД, Майл.ру, итд, то там ему только мозги изуродуют или действительно будет толк? Помимо того, что он в дальнейшем будет работать в организации, от которой нам будет только хуже и сфере IT.
ответить
А кто-то обещал, что будет просто?
> Про высшее образование понятно - оно лишь даёт вектор направления
Оно и этого обычно не даёт, увы. Оно даёт кругозор, умение думать (как это ни странно) и тот уровень фундаментальной подготовки (в том числе по математике), на самостоятельное получение которого силы воли хватает единицам. Но это всё не про профессию, это про общее развитие мозга. Профессиональная составляющая высшего образования для меня сомнительна. Мозги прокачать В/О позволяет, а вот обрести ремесло — вряд ли.
Иной вопрос, что при наличии адекватного образования (пусть даже непрофильного) дальнейшее самостоятельное обретение ремесла становится во многом делом техники.
> А вот если недопрограммист пойдёт куда-нибудь
Замечу, помешать мы ему в этом не можем.
> ему только мозги изуродуют или действительно будет толк
Depends. Зависит от индивидуальных характеристик.
> Помимо того, что он в дальнейшем будет работать в организации, от которой нам будет только хуже и сфере IT.
Несомненно, практически весь "крупняк" сугубо вредоносен. Частично нас тут спасает то интересное обстоятельство, что крупные конторы опасаются брать на работу лучших из лучших, поскольку лучшие из лучших, попав в одну контору, устраивают побоище на манер пауков в банке и норовят всё нахрен переделать в самой конторе, ломая её устои и традиции.
ответить
Способны единицы?!=О
Я помню, Вы как-то говорили, что самостоятельное обучение - единственный адекватный вариант развития человека. Неужели на такое способны единицы? Это какой-то закон природы или просто закон утёнка: в детстве нас дрессировали учителя и поэтому продолжать нужно в том же духе?
ответить
Читайте внимательно
Мой оборот "силы воли хватает единицам" относится не просто к самообучению как таковому, а к самостоятельному получению фундаментальной подготовки, в том числе изучению высшей математики, большая часть которой — да что там "большая", процентов 98! — никогда не будет непосредственно применена в профессиональной деятельности.
Самообучиться профессиональным навыкам, в том числе программированию, способен каждый, кому реально нравится означенная профессия и имеются к ней способности. Ну, или почти каждый. А вот математика — это несколько другое, она нужна каждому, кто намерен работать мозгом, просто для прокачки этого самого мозга, но мотивировать самого себя на это дело в достаточной степени — посложнее будет, чем всякие книжки по программированию почитывать и на компе что-то там запускать изредка.
ответить
Прокачка мозга
> А вот математика — это несколько другое, она нужна каждому, кто намерен работать мозгом
Даже если математику изучать в вузе, то результат тоже скорее всего будет сомнительным. Даже если студент научился находить интегралы, решать диффуры и знает центральную предельную теорему, то он в лучшем случае запомнит это наизусть, а в худшем не поймёт вообще ничего. Между всеми этими матаном, линалом, теорвером( можно бесконечно продолжать ) должна же прослеживаться какая-то взаимосвязь в мозгу. Как мне кажется ключевой момент в изучении математики именно такой.
ответить
Ну в принципе
Ну в принципе да, но тут вот какой момент. Мне почему-то кажется, что для человека, к математике способного, при изучении высшей математики понять её оказывается просто менее трудозатратно, нежели исхитриться всё сдать, так ничего и не вкурив. То есть там получается так, что путь понимания совпадает с путём наименьшего сопротивления.
Ну а кто патологически не способен понять — тому, увы, лучший тренажёр для мозга оказывается недоступен.
ответить
☞ From farvater
Mon Aug 24 17:09:00 2020
UTC 
Вопрос по 3-му тому книги
Здравствуйте, я нахожусь в процессе чтения третьего тома вашей книги, и кое-что
мне не понятно. В параграфе, посвященном Задаче о спящем парикмахере, мне
кажется, что в приведенном решении возможен данный сценарий, и я никак
не могу понять, что же я упускаю. Если можно, не могли бы вы указать, где я
заблуждаюсь?
1) Допустим парикмахер спит.
2) Почти одновременно приходят два клиента. Один из них блокируется на мьютексе
seats_mutex, а другой заходит в критическую секцию, будит парикмахера (при этом
парикмахер теперь заблокирован на мьютексе seats_mutex), занимает место в
холле, выходит из критической секции и, не приступя к выполнению lock(barber),
блокируется ОС, так как заканчивается его квант времени.
3) Процесс другого клиента разблокировался (процесс парикмахера до сих пор
заблокирован на мьютексе seats_mutex). Он занимает место в холле, поднимает
семафор (теперь он равен двум), выходит из критической секции и, не приступая
к выполнению lock(barber), блокируется ОС, так как заканчивается его квант
времени.
4) Парикмахер разблокировался. Он входит в критическую секцию и открывает
мьютекс barber, освобождает место в холле, выходит из критической секции,
выполняет BARBER_WORK(), снова понижает семафор, заходит в критическую
секцию, открывает и так открытый мьютекс barber, освобождает еще одно место в
холле, выходит из критической секции, выполняет BARBER_WORK() и засыпает
на семафоре customers.
5) Один из клиентов закрывает мьютекс barber, а другой на нем блокируется.
ответить
Вынужден
Вынужден признать, что тут я сам запутался и не вижу, почему бы этому сценарию не сработать; хуже того, не понимаю, как исправить решение (заметим, это именно то решение, которое весь мир друг у друга копирует), чтобы этот сценарий "закрыть". Вообще задача о спящем парикмахере какая-то мутная, если с другими сравнивать.
Может быть, кто-нибудь ещё объяснит нам, в чём тут дело?
ответить
Две проблемы
Я, кажется, вижу две проблемы. Первая —
barberдолжен быть семафором, а не мьютексом (чтобы не возникало ситуации проскакивания лишнего клиента через открытый парикмахером мьютекс). Вторая — нужно синхронизировать доступ к креслу (BARBER_WORK()иCUSTOMER_WORK()).Подробнее про обе проблемы:
1. Комментарий
/* если парикмахер занят — ждём */ошибочен, поскольку по факту мьютекс разблокируется сразу после начала стрижки, и парикмахер не защищён ничем, пока он выполняетBARBER_WORK(). Заменаbarberна семафор с тем, чтобы парикмахер вместоunlock(barber)делал быup(barber), позволит не пускать других клиентов, пока парикмахер к этому не готов.2. В текущем решении при наличии более одного клиента в холле парикмахеру позволено несколько раз подряд выполнить
BARBER_WORK(), не обращая никакого внимания на то, сидит ли кто-то в кресле. Выглядит так, как будто нужен ещё один семафор, отвечающий за кресло, который может быть равен 0 (никого нет) или 1 (в кресле сидит клиент), и тогда парикмахер должен перед выполнением своей работы дождаться (down(chair)), пока клиент реально усядется в кресло (up(chair)), а потом уже стричь.клиент:
down(barber)— ждёт освобождения парикмахерапарикмахер:
up(barber)— «Проходите, пожалуйста»парикмахер:
down(chair)— ожидание клиентаклиент:
up(chair)— сел в креслопарикмахер:
BARBER_WORK()клиент:
CUSTOMER_WORK()Пока идёт стрижка, все остальные клиенты висят на
down(barber).ответить
Довольно странно
Вполне возможно, я чего-то по-прежнему не понимаю, но если про защиту кресла (то есть про то, что нужно добавить лишний то ли семафор, то ли таки мьютекс -- см. ниже) я готов согласиться, то вот замена barber с мьютекса на семафор, по-моему, вообще ничего не способна исправить. Семантика barber -- "свободен ли парикмахер" (если это мьютекс) или "сколько у нас свободно парикмахеров" (если это семафор), но парикмахер-то по условию задачи всего один, то есть если barber -- семафор, то значений у него будет ровно два: ноль и единичка.
КМК, заявление (или поверье, как хотите назовите), что barber должен быть семафором, основывается скорее на новых веяниях от стандартизаторов, согласно которым мьютекс может открывать тот и только тот тред, который ранее его закрыл. В "современных" мануалах на pthread_mutex_* заявляется, что открывать мьютекс из треда иного, чем тот, что его закрыл -- это UB (!). При этом точно могу сказать, что в тех же мануалах, датированных 2009 годом, такого ограничения не было; в какой момент оно появилось -- не знаю, не отследил. Так или иначе, реализации вряд ли когда-нибудь станут такими, чтобы реально в ситуации "один закрыл, пришёл другой и открыл" происходило хоть что-то неожиданное, поскольку это сломает совместимость с кодом, написанным до "магического" года.
Чего я не могу сообразить -- так это достаточно ли добавления семафора/мьютекса chair для решения проблемы с исходно приведённым сценарием. Вроде бы должно быть достаточно, но, возможно, я опять чего-то не вижу?
ответить
Опечатка?
Все гораздо проще: barber должен быть семафором.
Я не знаю почему в вашем решении стоит мьютекс, т.к. весь мир друг у друга копирует вариант с семафором. Исключение — англоязычная википедия с некорректным комментарием "The first two are mutexes" и, возможно, еще пара источников.
P.s. В пункте 3) семафор равен не 2, а 1, поскольку декремент уже был в пункте 2), а именно "будит парикмахера". Небольшой недочет, логики дальнейшего повествования не изменяющий.
ответить
По-моему, таки нет
Поскольку парикмахер у нас один, у семафора будут возможны только два значения -- 0 (парикмахер занят) и 1 (парикмахер свободен). Сдаётся мне, от мьютекса это толком не отличается. См. ниже мой ответ на другой комментарий.
ответить
☞ From шнайдер
Fri Aug 7 20:44:00 2020
UTC 
Упоминание о проекте разработчиком World of Tanks
Книгу рекомендует один из разработчиков World of Tanks.
https://youtu.be/QQZmDWnV618?t=7217
Очень тепло отзывается о книгах.
ответить
Он еще и JavaScript
Он еще и JavaScript назвал в ответ на вопрос о худшем ЯП. Наш человек, наш...
ответить
☞ From Anonymous (unverified) Thu Aug 6 10:14:00 2020 UTC
Читаю первый
Читаю первый том вашей книги. На стр.373 функция QOLget у вас написано queue^.first := queue.first^.next. Либо я не понял указатели, либо у вас опечатка, ведь queue не является указателем, он является записью, содержащей 2 указателя. В любом случае при компиляции у меня возникала ошибка, поэтому я написал просто queue.first := queue.first^.next и всё заработало.
ответить
Давно
Давно известная и очень досадная опечатка. В архиве примеров эта программа есть, и там текст правильный. Естественно, ко второму изданию будет исправлено.
ответить
☞ From Anonymous (unverified) Wed Jul 15 00:07:00 2020 UTC
Альтернатива стандартам
Здравствуйте Андрей Викторович. Собственно красной нитью через многие ваши публикации проходит нелюбовь к так называемым комитетам, стандартам и т.п. Я раньше даже не задумывался об этом этом, воспринимал как должное, а теперь стало интересно, а как оно должно происходить, так сказать, правильно? Например, некий человек придумал новый ЯП, написал компилятор, документацию, оно обрело некую популярность, но потом он отошел от дел... Возможно теперь каждый желающий может написать свою спецификацию и они будут между собой конкурировать, какая кому больше по душе? Либо взять тот же C++, каким должен был быть путь его развития, прежде чем за него взялись ISO/IEC?
Возможно есть интересные статьи/литература на эту тему. Спасибо.
ответить
стандарты и спецификации
некий человек придумал новый ЯП, написал компилятор, документацию, оно обрело некую популярность, но потом он отошел от дел...
Ну и? Сплошь и рядом такое происходит. Впрочем, могу даже предложить пару реальных случаев для сравнения. Н.Вирт свой Паскаль придумал, реализовал, потом на него забил; в ISO приняли стандарт, который, к счастью, никто никогда не пытался применять. В итоге есть минимум две вполне живые реализации сильно модернизированного Паскаля — Delphi и Free Pascal, который я в книжке использую. А раньше их было ещё больше, Паскаль был довольно популярен в 1980-е и 1990-е. И, главное, никаких стандартов — на "стандартный Паскаль" никто не оглядывался, а то бы Паскаль точно помер.
А вот другой пример: Лисп. Маккарти именно что от дел отошёл, забил на Лисп, а зря — пришёл особо злостный вредитель Guy L. Steele Jr., организовал процесс стандартизации Лиспа, результатом которого стал Common Lisp, ну в общем нету больше у нас Лиспа. Common Lisp и некоторые его условно-живые (поддерживаемые) реализации я подробно рассматриваю в четвёртом томе, и, увы, всё это рассмотрение можно свести к одной фразе: перестаньте пинать труп CL, нужен новый лисп.
Возможно теперь каждый желающий может написать свою спецификацию и они будут между собой конкурировать, какая кому больше по душе?
Именно. Спецификация — это заявление вида "я тут что-то сделал, кто хочет — присоединяйтесь". Полагаю, что "что-то сделать" имеет право каждый, и сообщить об этом — тоже. А стандарт — это, натурально, приказание всему миру теперь делать вот так, а не как-то по-другому. Я имею наглость утверждать, что полномочий на такие приказания никто никогда и нигде не имел, не имеет и иметь не будет, у подобных вещей не может быть легитимного источника.
Скажу больше, одно изделие (например, компилятор) может поддерживать много разных спецификаций (и не поддерживать ещё больше других). И да, выбирать, что поддерживать, а что нет, должны создатели компилятора — а кто ещё?
ответить
Спецификация —
Спецификация — это заявление вида "я тут что-то сделал, кто хочет — присоединяйтесь". Полагаю, что "что-то сделать" имеет право каждый, и сообщить об этом — тоже. А стандарт — это, натурально, приказание всему миру теперь делать вот так, а не как-то по-другому.
Блин, как все, оказывается, просто... Вот серьезно, большущее вам спасибо за этот комментарий - отпала целая куча вопросов. В здешних обсуждениях частенько проскальзывают "стандарты", причем в негативном ключе, но вот почему они так плохи, лично мне стало абсолютно ясно только вот после этого вашего комментария.
ответить
☞ From Игорь
Sat Jul 4 17:22:00 2020
UTC 
Идеальный сферический браузер в вакууме
Андрей Викторович, добрый день!
У меня к вам такой чисто теоретический вопрос, как к эксперту в программировании.
Скажите пожалуйста, если рассмотреть ситуацию с разработкой браузера с нуля, при этом придерживаясь исключительно корректного, неизбыточного и оптимального кода, с изначально чрезвычайно дотошно продуманной архитектурой приложения, то возможен ли итоговый браузер чтобы работал достаточно шустро на железе уровня P2, с 256Mb ОЗУ?
Если рассматривать как конечный результат - полная поддержка CSS3 и HTML5.
Вопрос повторюсь - чисто теоретический, и выбор типа ПО - браузер, исключительно потому что сейчас это наиболее прожорливое приложение на практически любом ПК.
ответить
Можно-можно
Я практически уверен, что это возможно, причём за счёт одной очень небольшой (на первый взгляд небольшой, а в действительности определяющей) поправки.
Если вы в браузере (да, вот прямо в этом "современном" поделье от лучших моральных уродов мира) отключите выполнение JS, тормозить ОНО перестанет. Практически на любом сайте. Теоретически можно, задавшись целью, на CSS3 сотворить что-то такое, что начнёт жрать ресурсы как следует, но в реальной жизни такого не бывает.
В принципе было бы правильно поступить именно так: убрать поддержку JS и вообще любого тьюринг-полного исполнения на стороне клиента, а всех, кто что-то по этому поводу вякнет, тупо пристрелить как крыс (замечу, вреда от них гораздо больше, чем от крыс; и да, это практически всех нынешних веб-макак придётся перестрелять, но лично мне их было бы нисколько не жаль). Но, насколько я понимаю ваш вопрос, вы имеете в виду именно поддежку веба в его "современном" (и весьма прискорбном) состоянии.
Так вот, это тоже можно сделать с копеечными затратами ресурсов. Нужно только написать свой собственный интерпретатор JS, который с точки зрения приложения, в которое он встроен, представляет собой не то, что сейчас — некую процедуру, которой мы вынуждены отдать управление и надеяться, что она когда-нибудь завершится — а сущность совершенно иную: виртуальная машина должна быть оформлена как конечный автомат (точнее говоря, скорее "формальный автомат", поскольку "конечный автомат" — это строгий термин, и в этом смысле с его помощью реализовать тьюринг-полный язык нельзя, поскольку сами КА не тьюринг-полные), меняющий своё состояние по мере неких элементарных "шагов", каждый такой "шаг" выполняется за очень короткое (и уж точно заведомо детерминированное) время. Браузер реализуется однопоточным и никогда не отдаёт управление скриптам на JS — вместо этого он, обработав все входящие события вроде воздействий на GUI и данных, пришедших из сокетов, позволяет автоматам, выполняющим все активные в настоящий момент скрипты, сделать по одному шагу. Если событий нет, а активные скрипты есть -- фигачим, скажем, по 100 или 200 шагов, равномерно распределив их между активными скриптами, после чего снова проверяем, нет ли событий, подлежащих обработке. В toolbar'е браузера размещаем ВОООТ ТАКУУУУУЮ кнопку "stop scripts now".
Эта конструкция ни тормозить, ни подвисать, ни выжирать весь процессор не будет. Некоторые сайты, слепленные особо криворукими макаками, будут рендериться намного дольше, чем сейчас (возможно, в десятки раз), но читать их можно будет прямо сразу, так что пользователь даже неудобств никаких в большинстве случаев не заметит.
ответить
Макакинг-технологии
полная поддержка CSS3 и HTML5
А зачем эту хрень поддерживать? CSS3 нормальные люди не юзают, по причине, мягко говоря, ущербности. Как и CSS2. HTML5 - это вообще диверсия, макакинг - "стандарт", поощряющий встраиваивание жабаскриптов. Создание браузера с нуля с поддеркжкой этих макакинг-технологий??? Зачем, если это дерьмо и так намертво прибито гвоздями к любому нынешнему браузеру. Браузерный скриптинг - безусловное зло.
ответить
Кто б спорил
CSS3 нормальные люди не юзают,
Нормальные люди и JS не юзают, и HTML (я бы сказал, вообще любой, а когда совсем припрёт — xhtml1). Да можно и больше сказать, нормальные люди в наше время вообще сайтостроительством не занимаются, в этой области, считай, остались одни макаки.
К сожалению, на сайты ходить иногда приходится. А они макаками сделаны чуть менее чем все.
HTML5 - это вообще диверсия
Я больше скажу, все SGML-образные языки разметки, включая и все варианты HTML, и XML, и всё, что рядом с ними — всякие DTD/DOM/whatever — это всё одна большая диверсия. Но, конечно, HTML5 — это просто преднамеренное вредительство глобального масштаба с целым букетом отягчающих обстоятельств. Как, собственно, и всё, что сейчас в мире делается по части стандартов (всех поголовно) и спецификаций (не всех, но многих).
ответить
Хотел бы
Хотел бы узнать, чем именно плохи языки разметки, и что можно считать альтернативой по Вашему мнению для создания машиночитаемых документов?
ответить
Вопрос не имеет отношения к делу
Языки разметки как таковые — разумеется, ничем не плохи; речь идёт в данном случае о потомках SGML с этими его тэгами в угловых скобках, это семейство очевидных бастардов: вроде бы текст, то есть предназначено для написания и чтения человеком, но писать это невозможно, руки устают от угловых скобок, да и читать это тоже не шибко удобно.
Кроме того — и это более серьёзно — XML сейчас норовят применить для любых данных, а не только для разметки текста. Например, конфигурационные файлы для программ встречаются xml-ные. Или — просто частный пример, который первым пришёл в голову — электронная отчётность во всякие налоговые и фсс/пфр нужно направлять в виде файлов, имеющих xml-ный формат. И т.п. Так вот, если для представления текста (документа, если угодно), предназначенного к прочтению человеком, форматы с неограниченной рекурсивной вложенностью структур оправданны и понятно, зачем нужны, то для всего остального сие не имеет никаких причин и никаких оправданий, только усложняет софт на ровном месте. И это уже касается не только xml, тот же JSON тоже рекурсивно определённый и позволяет неограниченную вложенность.
Ну и последнее: судя по формулировке вашего вопроса (особенно учитывая, что формулировка приписывает мне утверждения, которых я не делал), у меня чёткое ощущение, что сюда вы забрели напрасно. В Интернете есть много других сайтов. В данном конкретном случае пояснения могут быть полезны для публики, но вообще я обычно подобные "вопросы" не раскрываю и на них не отвечаю, не теряйте время зря.
ответить
☞ From Алексей (unverified) Wed Jul 1 06:36:00 2020 UTC
Опечатка или мой затуп?
Добрый день. В 3-м томе на с. 181 возможно в картинку закралась опечатка (или я чего-то не понимаю, тогда прошу пояснения). Подсеть Бориса должна быть 192.168.45.64/29, на картинке же мы видим 192.168.64.0/29.
ответить
Опечатка,
Опечатка, конечно. Её даже уже нашли, но всё равно спасибо за внимательность :-)
ответить
Раздел с опечатками
Возможно стоит завести в том или ином виде раздел с опечатками? Или он уже есть? Все-таки теряешь время на попытке понять заведомо неверные значения.
ответить
Этой идее по
Этой идее по меньшей мере четыре года. Ну нету у меня времени её реализовать :(
ответить
Может быть для
Может быть для этих целей использовать готовую стороннюю платформу? Например, Яндекс.Дзен. Это типа ютуба, только для коротких текстовых заметок.
P.S. Капча - боль. Личное сообщение не смог отправить, зарегистрироваться не смог, комментарий оставить случайно удалось. The answer you entered for the CAPTCHA was not correct.
ответить
Вы вообще понимаете, где находитесь?
Может быть для этих целей использовать готовую стороннюю платформу? Например, Яндекс.Дзен.
Честно говоря, после таких "предложений" возникает желание врезать. Как следует. Возможно, даже ногами. Но оно, в общем, довольно быстро проходит.
Мне вот что интересно. Ладно, допустим, вы реально не заметили, кому и что предлагаете. Уточню: вы предложили использовать веб2.0-ный сервис, созданный агрессивными безрукими и безмозглыми макаками, человеку, который считает, что за применение на сайтах js следует ставить к стенке. Ну хорошо, всякое случается.
Но вы хотя бы понимаете, что дело тут не в технике и что никакая "платформа" никаким способом не сможет мне из ничего нарисовать сотню часов времени, необходимую, чтобы сверстать эту эррату? При чём тут вообще какие-то "платформы"? Вы где потеряли свои мозги? Пойдите поищите их, без мозгов жить сложно.
В любом случае можете больше не стараться проходить капчу на этом сайте — отныне ни один ваш комментарий никогда не пройдёт здесь премодерацию.
ответить
Полный хаос
Таких людей даже жаль. Предложение использовать js-нутую рекламную помойку... Просто за гранью. Т.е. человек готов наблюдать все эти рекламные испражнения абсолютно добровольно. Это же инволюция мозга какая-то.
ответить
☞ From Anonymous (unverified) Sat Jun 27 19:59:00 2020 UTC
Вопрос о математике
Какие дисциплины по математике полезно знать?
ответить
Все.
Все.
ответить
Для программирования
Изучаю алгебру, геометрию собираюсь изучать дискретную математику и физику, вот только пригодится это все для программирования или достаточно этих наук.
ответить
Depends
Смотря что вы понимаете под программированием. Сам процесс топтания кнопок вообще не требует никакой математики — на самом деле она там есть, но на это можно не обращать внимания. И вот это вот "пригодится для" — ну, скажем, какое-нибудь тензорное исчисление точно не "пригодится" в том смысле, что непосредственно его использовать в работе никогда не потребуется. И это касается большей части математики — если рассматривать одного отдельно взятого программиста, за всю его практику в течение всей жизни ему если что из математики и понадобится, то уж точно не всё. А дальше возникает закономерный вопрос, мол, применил я формулу Тейлора один раз за всю жизнь в каком-то проекте, и стоило ради этого пять лет в университете биться лбом о высшую математику.
Проблема в том, что математика на самом деле совершенно не для этого. Математика — это на сегодняшний день наилучший способ накачки мозгов. Даже не просто наилучший, в своём классе это, пожалуй, способ единственный. Чем лучше человек освоил математику, тем лучше у него работают мозги, и обратное, увы, тоже верно.
Просто, как ни странно, пресловутое топтание кнопок до поры до времени не требует мозгов — точнее, задействует только небольшую часть мозга, но такую, которой у многих людей нет :-) Поскольку этой части мозга у большинства нет, те, у кого она есть (те, кто умеют писать программы, хотя бы даже не очень большие), начинают думать, что раз они могут делать то, чего другие не могут, то у них офигенно развитые мозги. А потом внезапно оказывается, что для очередного проекта мозгов как-то маловато, не тянут. И это довольно обидно, особенно когда уже поздно что-то с этим делать; скажем, после 25-30 лет мозги качать уже объективно поздно, то есть можно, но качаются они при этом крайне неохотно.
Собственно говоря, изучение математики как раз и даёт возможность отодвинуть этот потолок по вертикали повыше. Чем лучше вы будете знать математику, тем выше будет располагаться ваш потолок возможностей.
Основная мысль тут вот какая: математику надо изучать не потому, что она "пригодится", вопрос вообще не в этом. Математику нужно изучать, чтобы прокачать мозг. И это нужно делать вовремя, пока мозг ещё готов прокачиваться. В каком количестве? Ну, э... all of them.
ответить
Спасибо
Очень полезная информация. Спасибо!
ответить
Полезно для
Полезно для чего? Для спасения души? Бесполезных нет, все математические дисциплины появились в ответ на насущные потребности человека. Назовите конкретную область - будет вам конкретный ответ.
ответить
Ну, Платон мне может и друг, но...
все математические дисциплины появились в ответ на насущные потребности человека
Вот ни фига, справедливости ради. Читать тут: Апология математика
Харди — один из наиболее известных сторонников "чистой математики", такой, которая вообще не имеет приложений; и он в этой приверженности совершенно не одинок.
Иной вопрос, что абсолютно любой раздел математики при его освоении придаёт мозгам большую эластичность. Посему полезны они все до единого.
ответить
абсолютно
абсолютно любой раздел математики при его освоении придаёт мозгам большую эластичность
Это, имхо, ее терминальная ценность, но за поправку, конечно, спасибо. А чистая математика со временем может и "загрязниться" - Фурье едва ли думал о сжатии картинок с котиками... Ну да не будем мешать все в одну кучу.
ответить
Может-может
Сейчас не нашёл конкретики, но как раз про вышеупомянутого Харди я слышал, что он особенно гордился какой-то из выстроенных им самим теорий, заявляя, что уж это точно никто никогда не сможет ни к чему приложить. Приложение нашлось через десять лет после его смерти.
ответить
☞ From Anonymous (unverified) Sat Jun 27 05:46:00 2020 UTC
Pascal
Изучаю по вашей книге Pascal, но хочется этот язык углубленно изучить. Какая есть хорошая литература для дальнейшего изучения Паскаля.
ответить
Не знаю
Я не изучал этот вопрос, поскольку не предполагал и не предполагаю использование Паскаля в качестве профессионального инструмента — несмотря на то, что такое использование, несомненно, возможно.
ответить
☞ From Сергей (unverified) Fri Jun 26 20:04:00 2020 UTC
ошибка в тексте
Первая книга "Введение в профессию" страница 94: цитата
"Права на чтение соответствуют 1, права на запись -2, права на чтение - 4; " Там где единичка там должно быть "исполнение".
ответить
Эта известна
Эта известна уже давно, почему-то её всегда замечают первой. Спасибо за внимательность :-)
ответить
☞ From Anonymous (unverified) Thu Jun 18 00:30:00 2020 UTC
Вопрос по размеру шрифта
Добрый день! Существуют ли ваши книги в каком-либо другом формате или в том же в pdf только с увеличенным шрифтом? На электронной книге (не на маленькой 6", а на 7.8" дюймах) шрифты кажутся не комфортными. Пробовал перегнать pdf в epub, но безуспешно.
ответить
Я не вполне
Я не вполне понял, где тут "увеличенный" шрифт. Все файлы, выложенные на сайте — это тупо оригинал-макеты, с которых печатались бумажные книги (плюс обложка, страничка лицензии и в конце ещё задняя обложка).
Отвечая на ваш вопрос: нет, в других форматах мои книги недоступны. Больше того, прошу обратить внимание, что перевод в другие форматы является прямым нарушением лицензии.
ответить
Большое
Большое спасибо за Ваш труд, за книги.
Мне тоже стало интересно, из каких соображений Вы переопределили шрифт в самом шрифте? Страдает поиск по тесту, лично в моем случае, и еще я делаю пометки к тексту. Вы не хотите индексации поисковыми машинами? Но эти чудесные тексты, в таком случае, не получают должного распростанения. Можно было делать выборочно, например - оглавление с нумерацией и пару абзацев из главы другим шрифтом, хотя бы для индексации ключевых моментов.
Поясните Вашу позицию, спасибо.
ответить
Сколько можно одно и то же мусолить?
Мне, честно говоря, уже надоело повторять одно и то же. Я не хочу, чтобы из PDF-файлов с моими книжками любое чмо могло сделать copy-paste, например, в какой-нибудь реферат или псевдометодичку, которую делают для галочки "за публикацию". Это можно обойти, но те, кто умеют обходить, обычно не делают того, что мне не нравится.
Как следствие, текстовый слой в моих PDF-файлах сломан. Преднамеренно. И нет, это не изменится, я не думаю, что ко всему, что я на эту тему уже успел услышать за 11 лет существования данного сайта, можно добавить что-то ещё, т.е. все аргументы против такого решения я давно уже знаю.
Между прочим, поисковики прекрасно индексируют мои книжки. Как они это делают — спросите у них.
ответить
☞ From Anonymous (unverified) Sun Jun 14 21:04:00 2020 UTC
Здравствуйте! В
Здравствуйте! В поисках "рабочей лошадки" попробовал несколько дистрибутивов Linux и обнаружил, что в некоторых из них valgrind обнаруживает у скомпилированных программ (даже простейшей int main() { return 0; } ) некие области памяти, обозначенные в "LEAK SUMMARY" как "still reachable", хотя динамическая память не используется. Собственно, вопрос: насколько это критично и стоит ли избегать использования таких дистрибутивов?
ответить
Это зависит,
Это зависит, скорее всего, не от дистрибутива, а от сочетания версии libc и версии самого valgrind. В любом случае "still reachable" -- это не криминал.
ответить
Address Sanitizer
В качестве альтернативы valgrind можно ещё попробовать указать компилятору флаг -fsanitize=address. После этого программа запускается как обычно. Механизм работы у этой штуки несколько иной, нежели у valgrind, он использует так называемый shadow memory. Программа, скомпилированная с address sanitizer работает по-прежнему медленнее, чем без него (что понятно, так как проверки не бесплатны), но это сильно быстрее, чем valgrind. Кроме того, он отлавливает ошибки стековой памяти, в то время как valgrind этого не делает по умолчанию. С другой стороны, valgrind показывает условные переходы по неинициализированному значению, что asan вроде как не умеет. В целом эти инструменты неплохо друг друга дополняют (правда использовать их одновременно, то есть запускать под valgrind программу, скомпилированную с -fsanitize=address, всё же не следует).
ответить
☞ From Алексей (unverified) Sun Jun 14 17:15:00 2020 UTC
Точки следования
Добрый день. Упоминаются ли в одной из ваших книг точки следования (sequence points)? Столкнулся с этим вопросом в ВУЗе при изучении C++. Так и не смог разобраться, на мой взгляд, абсолютно нелогичная и ненужная вещь. При самостоятельном изучении такой вопрос не возникал. Вот пример кода:
cout << (ч++ && --x) << endl; // output 0
cout << "x = " << x << endl; // output x = 1
cout << (x++ && --x) << endl; // output 1
cout << "x = " << x << endl; // output x = 1
Для меня его результат оказался неочевидным.
ответить
Я для этой
Я для этой сущности предпочитаю термин "точки гарантированных вычислений". Нет, в моих книгах этого нигде нет. Нормальные психически здоровые люди два побочных эффекта в одном арифметическом выражении не используют; следовательно, для нормальных психически здоровых людей это знание лишнее, только мозг засорять.
ответить
Нет, в моих
Нет, в моих книгах этого нигде нет.
Ну как же нет? Второй том, страница 227. Даже жирным шрифтом выделено: "если значение выражения уже определено, второй операнд не вычисляется".
Правда само понятие "точки гарантированных вычислений" там в явном виде не вводится, но для того, чтобы понять, что выведет приведённый топикстартером код, данной информации вполне достаточно.
Другой вопрос, что в реальных программах такой код писать не следует, так как
Нормальные психически здоровые люди два побочных эффекта в одном арифметическом выражении не используют,
но вот с утверждением о том, что
для нормальных психически здоровых людей это знание лишнее, только мозг засорять
вы, пожалуй, несколько погорячились, так как код вида
if (p && p->foo ()) { ... }вполне легитимен, хоть и использует ту же особенность оператора &&.
Кстати, интересно, что это верно только для встроенного оператора &&: если его перегрузить (топикстартер задал вопрос о C++), то для перегруженного оператора это уже не так: так вычисляются оба операнда, причём в неопределённом порядке.
ответить
> Даже жирным
> Даже жирным шрифтом выделено
Это не про точки гарантированных вычислений, это про ленивую семантику логических связок. Предметы, конечно, связанные, но совсем не одно и то же :-)
> оператора &&.
Не оператора, а операции :-P Вот низзя слово "operator" читать как "оператор", спасибо тому странному человеку, который когда-то давно перевёл словом "оператор" английское statement.
По существу -- ну да, понятно, перегруженная операция -- это по сути просто функция; кстати, это ещё одна особенность Си++, которая мне не нравится; перегружали бы операции макросами -- ну, типа шаблонов, только чтобы их перегружать можно было по типу аргументов -- и был бы не нужен манглинг.
ответить
Это не про
Это не про точки гарантированных вычислений, это про ленивую семантику логических связок. Предметы, конечно, связанные, но совсем не одно и то же :-)
Согласен, но для того, чтобы понять приведённый топикстартером код, этого достаточно. Конечно, точки гарантированных вычислений -- это действительно больше про побочные эффекты, но так или иначе, из ленивой семантики оператора^H^H^H^Hции && логически вытекает порядок вычисления левой и правой части.
Кстати говоря, возвращаясь к вашему замечанию о том, что
Нормальные психически здоровые люди два побочных эффекта в одном арифметическом выражении не используют; следовательно, для нормальных психически здоровых людей это знание лишнее, только мозг засорять..
Это было бы так в идеальном мире. А в реальном никто не гарантирует, что код, с которым придётся работать, писали "нормальные психически здоровые люди" в здравом уме и трезвой памяти. Поэтому да, конечно, писать такое не следует, но при чтении чужого кода следует быть готовым ко всему, от чего не падает компилятор :) Хотя иногда даже это не выполняется...
Вот низзя слово "operator" читать как "оператор"
Я даже обратил на это внимание перед отправкой комментария, но в последний момент решил оставить как есть. Даже вы в своей книге отмечаете, что когда человек видит слово operator, его очень тяжело убедить не произносить русского слова "оператор". Да и в литературе много где operator overloading переводят как "перегрузка операторов", и никому это не режет глаз. По-видимому, следует смириться с тем, что слово "оператор" в зависимости от контекста может означать как operator, так и statement, подобно тому, как слово "поток" может означать либо stream, либо thread.
ответить
логически
логически вытекает порядок
Да вытекает, конечно, кто б сомневался. Но точки гарантированного вычисления — это отнюдь не только про логические связки и даже, я бы сказал, не столько. Пример ТС привёл со связками, но вопрос-то был задан не про связки. Ну и ответил я тоже не про связки.
По-видимому, следует смириться
С этим и мирились — ровно до тех пор, пока не появился Си++, описание которого требует эти два термина употреблять зачастую чуть ли не в одном предложении (и уж точно в одном абзаце). А тут уже "мириться" не получается, текст превращается в шараду.
Например, при описании Пролога и Хоупа я сам, если вы не заметили, использую слово "оператор" как перевод operator, но в этих языках нет statement'ов.
ответить
С этим и
С этим и мирились — ровно до тех пор, пока не появился Си++, описание которого требует эти два термина употреблять зачастую чуть ли не в одном предложении (и уж точно в одном абзаце). А тут уже "мириться" не получается, текст превращается в шараду.
Напомнило байку, которую рассказывал нам один преподаватель, когда я учился на первом курсе. У него один аспирант написал работу, в которой среди прочего была формула с тремя буквами μ (мю). И комментарий к ней: "В этой формуле первая буква μ означает число Милнора, вторая — это функция Мёбиуса, а третья буква μ — это мера, по которой мы интегрируем. Поскольку эти три понятия перепутать нельзя, то я оставил все обозначения как есть". Ну а что, overloading в действии :)
Например, при описании Пролога и Хоупа я сам, если вы не заметили, использую слово "оператор" как перевод operator, но в этих языках нет statement'ов.
Пока не заметил, так как четвёртый том пока прочитал не полностью. Но, вероятно, ещё замечу :)
ответить
Так классика
Так классика же. И да, в здравом уме такое в голову не придет, тут вы правы.
ответить
☞ From Anonymous (unverified) Sat Jun 13 15:58:00 2020 UTC
infoviolence
Будет ли продолжение видеоблога?
ответить
Будет.
Будет.
ответить
Когда
Когда планируете возобновить?
ответить
Ну вот скажу я,
Ну вот скажу я, что завтра -- и что, это что-то изменит? ;-)
ответить
Конечно!
Конечно! Очень хочется увидеть продолжение.
ответить
Я к тому, что
Я к тому, что планировать я могу что угодно -- я уже раз десять планировал очередной ролик записать "прям вот на днях". Но вообще шанс сейчас есть :)
ответить
☞ From Gleb (unverified) Mon Jun 8 12:32:00 2020 UTC
Арчитектура компьютера
Здравствуйте, Андрей! Можете посоветовать хорошую книжку об архитектуре компьютера. А то какой из меня выйдет программист если не знаю как работает компьютер. Или всё что нужно, будет сказано в ваших книгах? Я читаю пока что вашу первую книгу...
ответить
Основы
Основы архитектуры рассказываются во вводной части, потом им же посвящена первая половина второго тома, и ещё довольно много на эту тему будет в третьем томе. Дальше — разве что справочники и другая специальная литература, но начинать с неё, пожалуй, всё-таки не стоит :-)
ответить
Если
Если интересует "железная" сторона вопроса, рекомендую "Цифровую схемотехнику и архитектуру компьютера" Харрисов - в простой, доступной и местами юморной форме описывается все, что творится под капотом, начиная с логических элементов и заканчивая конвейерами, виртуальной памятью и прочим.
ответить
Для начинающих
Ч.Петцольд - Код. Тайный язык информатики
ответить
☞ From Anonymous (unverified) Sat Jun 6 10:35:00 2020 UTC
Malware
Сейчас, во время дистанционных экзаменов, многие университеты вынуждают студентов использовать вредоносные программы (такие как Zoom, ProctorU и т.п.)
Я считаю, что учебное заведение не имеет право компрометировать безопасность моего компьютера.
Что остаётся делать? Категорический отказ от использования этих программ чреват несдачей экзамена.
ответить
Попробуйте
Попробуйте подать заявление официально, что у вас отсутствует возможность использования предложенного вам софта, и что если учебное заведение настаивает, то пусть вам предоставят (за счёт заведения, естественно) компьютер с уже установленным софтом и выход в интернет.
Получится ли из этого хоть что-то — не знаю, у нас страна беспредела. Так или иначе, пусть вам хотя бы официально откажут, а то разговоры к делу не пришьёшь. Потом можно будет накатать тонны жалоб в рособрнадзор и прочие инстанции. Как ни странно, иногда это срабатывает, поскольку на жалобы нужно официально ответить, то есть написать текст ответа, а это чиновников дико раздражает.
ответить
☞ From Vladimir_M
Fri Jun 5 16:59:00 2020
UTC 
Вопрос о vim.
Здравствуйте. Скажите пожалуйста, при работе в vim с русским текстом при переходе из режима вставки в режим команд вы каждый раз переключаетесь на английскую раскладку? Ведь с другими раскладками команды не работают. Вы к этому привыкли или как-то технически решили проблему? Если решили, то как? Полагаю что при программировании для вас это значения не имеет, там русская раскладка крайне редко нужна. Но вы ведь в vim целые книги на русском пишите.
ответить
Вот не вижу
Вот не вижу проблемы.
Мне этот вопрос уже не впервые задают, и меня это несколько удивляет. Да, я переключаю раскладку "каждый раз", и не только при переходе в режим команд. Я, например, точку с запятой и двоеточие набираю, переключаясь на латинский регистр, ну то есть я тупо не помню, где они в русской раскладке. Вот сейчас поискал, они оказалось на четвёрке и шестёрке; я этим не пользуюсь никогда, вот то есть вообще, я не знаю и не помню, где там что на Shift-циферках в русском варианте. Хотя нет, вру -- восклицательный знак и двойную кавычку набираю таки как shift-1 и shift-2. Попробовал сейчас вопросительный знак набрать, пальцы сами собой переключили регистр и нажали shift-? (ту кнопку, которая рядом с shift'ом). Про двоеточие я это за собой знал, про вопросительный вот сейчас только выяснил.
Возможно, это потому что у меня переключение регистров висит на правом Alt. Я сам не замечаю, когда успеваю переключить раскладку туда и обратно. А вот как люди могут работать с переключениями по всяким Ctrl+Shift, вообще не представляю, причём вне всякой связи с vim'ом. Это же положение руки сменить надо, чтобы переключить раскладку. Кто придумал такое?!
ответить
У меня в .vimrc
У меня в .vimrc есть такой кусок:
set langmap=
\ёйцукенгшщзхъфывапролджэячсмитьбю;`qwertyuiop[]asdfghjkl\;'zxcvbnm\\,.,
\ЁЙЦУКЕНГШЩЗХЪФЫВАПРОЛДЖЭЯЧСМИТЬБЮ\\,;~QWERTYUIOP{}ASDFGHJKL:\"ZXCVBNM<>?
ответить
Прикольно, не знал
Вот прямо по классике: "а что, так можно было?" Но мне, пожалуй, уже поздно, просто не нужно — я и без этого прекрасно справляюсь.
ответить
Полностью
Полностью проблему не решает. Как минимум '$' и '^' для перехода в конец строки или на первый символ при русской раскладке не воспользуешься.
ответить
~/.vimrc
set keymap=russian-jcukenwin
set iminsert=0
set imsearch=0
inoremap <C-l> <C-^>
Переключатся в режиме вставки ctrl + l
ответить
Спасибо. Может
Спасибо. Может буду пользоваться. Хотя все-же слегка неприятно что раскладка в редакторе отличается от системной и переключается иначе.
ответить
Не сразу
Не сразу заметил. Теперь в режиме вставки не работает клавиша Tab. Вместо табуляции наравне с ctrl+i переключает раскладку. Буду разбираться.
ответить
С табуляцией
С табуляцией разобрался. Просто по ошибке сперва вместо настроил .
ответить
vim-xkbswitch
vim-xkbswitch
ответить
Прям как в анекдоте
- Петька, приборы!
- Восемь!
- Что "восемь"?
- А что "приборы"?
ответить
☞ From izyk
Thu May 14 07:48:00 2020
UTC 
habr
Здравствуйте.
Андрей Викторович, скажите, пожалуйста, почему о вас нет упоминария на самом, на мой взгляд, популярном сайте о компьютерах в нашем Интернете, habr.com? Вы имеете что-то против упоминания вас на этом сайте? Или я плохо искал.
Если вы считаете возможным. Я бы мог вам дать приглашение на сайт и, я думаю, если вы напишите о своих книгах на нём, я так хорошо не смогу, это существенно расширит аудиторию заинтересованных спонсоров, а главное, читателей.
ответить
Меня нет и
Меня нет и никогда не будет на хабре, так что приглашение меня не интересует. Против упоминаний я не возражаю, а если бы и возражал, то это, как мы понимаем, ничего бы не изменило.
ответить
А почему вас
А почему вас никогда не будет на хабре?
ответить
Не нравится он
Не нравится он мне. Вызывает отторжение пополам с омерзением. Вопрос "почему так" несколько сложнее; хотел что-то сформулировать, но, пожалуй, не буду, поскольку это может показаться поводом для обсуждения, в действительности же никакие аргументы меня всё равно не убедят туда пойти.
ответить
Ну можно начать
Ну можно начать с того, что он без JS нормально не работает, насколько я знаю. ;)
А в целом, на мой вкус, за последний десяток лет он стал намного более омерзительным и отталкивающим. Может быть причина в том, что за это время он был избран корпорациями площадкой для их маркетинговой деятельности.
ответить
А по-моему
А по-моему только без JS он хоть как-то и работает. Для меня основным поводом к отключению JS стал именно этот сайт. Причём у меня так нет аккаута, я просто иногда его почитываю, но это не мешало ему подвешивать браузер намертво даже на неприлично мощном "железе". Хотя для входа на сайт, скорее всего, нужен JS.
P.S. Про этот сайт я узнал именно из комментариев к статье на хабре (там упоминалась статья про язык Си и начальное обучение программированию, пример про функцию fork из которой вошёл в 4-й том).
ответить
аудиторию
аудиторию заинтересованных спонсоров
Пожалуйста, не надо путать спонсорство с благотворительностью.
ответить
Их довольно
Их довольно сложно не путать, термины по смыслу очень близкие, хотя, конечно, не тождественные. Тонкие смысловые грани чувствуют не все, а те, кто чувствуют — не всегда сходятся во мнениях на эту тему.
ответить
Лично я всегда
Лично я всегда понимал отличие спонсорства от благотворительности примерно так же, как это отмечено в википедии:
спонсорская деятельность, в отличие от благотворительности, является инструментом маркетинга, который используется в целях создания положительного образа и рекламы спонсора
Спонсорство, конечно, может маскироваться под благотворительность, но при внимательном рассмотрении отличить одно от другого обычно можно.
ответить
Русский раздел
Русский раздел Википедии пишут троечники и прочие недоучки. В действительности спонсор -- это тот, кто принимает на себя чьи-то расходы или их часть. Есть ли у него при этом какой-то рекламный интерес и вообще какова его мотивация — вопрос второй; например, родители, оплачивающие проживание своего ребёнка за границей (скажем, на время учёбы) тоже называются спонсорами. Это просто факт.
ответить
Не только
Не только википедия, но и многие толковые (особенно финансовые или экономические) словари определяют цели "споносора" как саморекламу.
Тут дело в том, что русское слово "спонсор" и английское слово "sponsor" -- это разные слова, с близкими, но разными значениями. Нельзя просто взять перевод слова "sponsor" и сказать, что это и есть, один в один, значение слова "спонсор". (Помню как-то одного моего знакомого поразило до глубины души различие значений между словами "патетический" и "pathetic".)
А слово "спонсор" ещё с девяностых (если не раньше) приобрело в русском языке устойчивый коммерческо-маркетологический оттенок.
Это всё тоже просто факты.
Но ОК, согласен с тем, что в просто в значении "оказывающий материальную помощь" слово "спонсор" в русском языке использовать допустимо.
ответить
Ой да ладно.
Ой да ладно. Когда некий респектабельный господин средних лет оплачивает расходы симпатичной особы женского пола, годящейся ему в дочки, но дочкой не являющейся :-) — его именно что в современной семантической версии русского языка таки называют спонсором (и что-то сдаётся мне, что как раз такого значения у исходного английского слова нет).
Если ближе к коммерции, то бывает, что коммерческие компании спонсируют научные исследования — не в целях саморекламы, а чтобы воспользоваться результатом. Или спонсируют обучение студентов — опять же, не в целях рекламы, а чтобы потом часть выпускников (в ряде случаев тщательно выбранную часть) прибрать к себе на работу.
Как раз таки просто оказание материальной помощи — это если и спонсорство, то очень частный случай такового.
Вот тот же взять мой проект. Многие донэйторы, даже, я бы сказал, большинство из них, деньги присылали просто чтобы поддержать проект. Но были и такие, для кого целью было получение бумажных книжек; NB: в этом нет ничего плохого, напротив, это даже очень хорошо, я рад, что много кто готов был рискнуть деньгами ради перспективы поставить на полку мою книгу в бумажной версии. Но это уже не вполне благотворительность. Я бы сказал, что вот это как раз и есть спонсорство.
ответить
☞ From Anonymous (unverified) Sat May 9 20:56:00 2020 UTC
Аналог Intel ME у ARM'ов
Здравствуйте! Существует ли аналог Интел МЕ у АРМ процессоров? Спрашиваю, поскольку в Интернете ничего толкового не нашел. Правда, в одном видео на ютубе говорилось про некий чип в смартфонах, преобразующий аналоговые сигналы в цифровые, якобы он аналогичен чипу ИМЕ, а в другом говорилось про GPU в составе ARM процессора (взаимосвязь вообще не понял)
ответить
Мне об этом
Мне об этом ничего не известно.
ответить
Существует,
Существует, причём появился даже раньше. Называется ARM TrustZone. Именно на его основе работает AMD PSP (аналог Intel ME на AMD), например.
Правда это не совсем полный аналог и ближе к режиму SMM чем к ME, насколько я понимаю. Но эффект такой же — код производителя железа, который имеет более высокие привилегии чем ядро ОС.
ответить
☞ From Modest (unverified) Sat May 2 16:08:00 2020 UTC
freebsd+icewm
С чем это связано: захожу в меню пуск+программы а там программ не обнаружено. В линуксе devuan+icewm всё работает.
ответить
Здесь
Здесь сказывается принципиальная разница в подходах к построению программного окружения. В линуксах есть пакетные менеджеры, на которые возложено создание списков установленных программ, а пакеты, в которые завёрнуты оконники, из этих списков тем или иным способом генерируют свои менюшки. Когда я в последний раз имел дело с FreeBSD (а это, увы, было очень давно -- лет пятнадцать назад), ничего похожего на пакетные менеджеры там не было, вместо них присутствовала port collection, но эти порты никак друг на друга не оглядывались и на присутствие-отсутствие друг друга не реагировали.
Конкретное содержание всех менюшек в оконнике (не только в IceWM, практически в любом) настраивается в его конфигурационных файлах. В большинстве дистрибутивов Linux "кто-то добрый" сделал это за вас, используя информацию об установленных пакетах. Во FreeBSD этого никто за вас не сделал, в этом вся разница.
ответить
Строго говоря,
Строго говоря, возможность генерации менюшек никак не связана с наличием или отсутствием пакетного менеджера. Менюшки обычно генерируются из набора имеющихся в системе *.desktop файлов. А desktop-файл обязана иметь каждая пользовательская программа, по мнению парней из freedesktop.org
ответить
Ну, обязана-то
Ну, обязана-то обязана, но мнение авторов программ по этому поводу может отличаться от мнения этих самых парней из freedesktop, и в этих случаях часто .desktop для них пишут мейнтейнеры пакетов под конкретный дистрибутив. Опять же, насколько я понимаю эту механику, менюшки сами собой не сгенерятся, нужно, чтобы их кто-то сгенерил при установке оконника и потом перегенерировал при установке новых программ. Вообще могу, конечно, ошибаться, но у меня чёткое ощущение, что в линуксах всей этой магией занимается именно пакетный менеджер.
ответить
Я вам больше
Я вам больше скажу, даже мнение пользователей программ может отличаться от мнения парней из freedesktop. Мне, например, все эти менюшки нафиг не сдались, а всякие *.desktop файлы, вместе с иконками и прочим хламом, только глаза мозолят.
всей этой магией занимается именно пакетный менеджер.
Да, конечно, в тех дистрибутивах, которые я щупал, запуском программы генерации менюшек занимался либо пакетный менеджер при обновлении пакетов, либо никто.
Небольшое лирическое отступление про магию и пакетные системы, если позволите.
Году так в 2008-м понадобилось мне собирать собственный модифицированный микро-дистрибутив для специализированных компов. Попробовал я взять для этой цели дебиан, которым давно пользовался. Стал разбираться, как там создавать свои пакеты, и оказался перед выбором: либо пользоваться готовыми магическими заклинаниями, мало понимая их смысл, либо отказаться от дебиана. (Вариант всё-таки вникнуть и понять оказался неподъёмно трудоёмок.) Магию, кроме развлекательной, я не очень люблю, поэтому пришлось выбрать второй вариант. В результате задача была успешно и довольно быстро решена с помошью ArchLinux'а, да и сам я потом какое-то время им на десктопе пользовался. В пакетной системе арча всё было (по крайней мере на тот момент) весьма прозрачно, никакой нездоровой магии.
ответить
Дебиановские
Дебиановские спеки — это даааааааа... жуть с ружьём. RPMовые, впрочем, не лучше, их тоже чтобы осилить, нужно потратить этак с месяцок.
Для меня мораль той басни, в общем, вполне ясна: зависимости — абсолютное вселенское зло. Я даже об этом написал в только что вышедшем четвёртом томе, см. параграф 12.5.5 (в книге стр. 629, в PDF-файле соответственно 631). Что характерно, во всей главе 12.5 речь идёт о том, почему нехорошо программировать на интерпретируемых языках, но конкретно вот этот параграф более чем наполовину — о том частном случае dependency hell, который порождается линуксовыми системами инсталляционных пакетов.
ответить
FreeBSD действительно "ручная" система
Андрей Викторович отчасти правильно сказал, во фре поставляется ПО как это говорят "ванильное", без всяких придуманых за вас конфигов.
Насчёт пакетного менеджера, во фре он уже года 3-4 имеется, вполне могучий pkg. Только я им не пользуюсь, как-то привычней портами всё ставить.
А про меню в icewm - на форуме FreeBSD очень подробно и детально описана конфигурация это wm:
https://forums.freebsd.org/threads/howto-icewm-configuration.59161/
ответить
Только я им не
Только я им не пользуюсь, как-то привычней портами всё ставить.
Позвольте поинтересоваться, что значит "ставить портами"?
В OpenBSD, например, из системы портов я собираю пакеты, которые затем всё равно нужно ставить с помощью пакетного менеджера. В CRUX или Slackware примерно так же (хотя в них, конечно, не столько система, сколько просто коллекция портов).
А как во FreeBSD это устроено? Можно как-то ставить из портов в обход пакетного менеджера, без предварительной сборки пакета? Или речь просто про
make install?ответить
Именно про make install
Да, ставлю просто make'ом.
Сложностей никаких при этом не наблюдается, настроить опции опять же можно чтобы ничего лишнего не ставилось.
Во фре тоже можно из порта собрать пакет который затем сохранить и использовать при необходимости.
ответить
make install
Я прошу прощения, но я ещё уточню, если можно. Речь идёт о запуске
make installиз дерева портов?Дело в том, что в OpenBSD тоже можно сделать
make installиз дерева портов. (Я таким способом не пользуюсь, поскольку сборку делаю от обычного пользователя, а для установки нужны, ясное дела, права суперпользователя.) Но при таком способе, по сути, выполняется сначалаmake package, а затем уже полученный пакет устанавливается в систему (и конечно сохраняется в кэше, так что собирать его при повторных установках уже не нужно).Во FreeBSD не так?
ответить
Таки да,
Таки да, устанавливаю make install'ом из каталога нужного мне порта в дереве портов.
Но бывали пара-тройка раз когда трогал не портированные исходники, и собирал их совсем вручную ./configure, make.
Пакеты если просто ставить порт я так понимаю не собираются.
Если нужен пакет, то надо конкретно цель package указывать.
А опёнке если в каталоге порта дать команду make install, там при этом пакет соберётся и из него уже установится само приложение?
ответить
В опёнке да, в
В опёнке да, в дереве портов по
make installвыполняется сначалаmake package, а потом устанавливается полученный пакет.Более того, если переменная
FETCH_PACKAGESне установлена вNo(значение по умолчанию) и пакет с точно такой же полной версией уже есть в PKG_PATH (она обычно указывает на официальный репозиторий в инете), тоmake packageдаже не будет собирать пакет, а просто скачает его из репозитория.ответить
Надо будет ещё
Надо будет ещё раз установить опёнка. А то я ради интереса как-то в виртуалке поставил базовую систему, а дальше что-то не пошёл.
Дойду до графики в этот раз :)
ответить
Попросту
Попросту говоря, в де{би|ву}ане меню генерируется автоматически, а во фре это дело оставлено на усмотрение пользователя.
Файс с описанием меню можно создать вручную, а можно запустить какой-нибудь автоматический генератор. В комплекте с IceWM, вроде бы, должен быть какой-то генератор меню (может даже не один, в зависимости от ОС и версии IceWM). Ну или можно установить универсальный menumaker.
А пакетные менеджеры давно есть во всех основных *BSD системах (ну вот про DragonFlyBSD не уверен, а в остальных трёх точно есть). К тому же, даже собрав софт самостоятельно из портов, удобно получить на выходе готовый пакет, а не просто россыпь файлов.
ответить
☞ From Anonymous (unverified) Sat Apr 25 16:51:00 2020 UTC
Линус Торвальдс .vs. CS
Набрёл тут на интересную переписку 2003-го года.
Я, конечно, согласен с тем, что goto в некоторых отдельных случаях использовать можно и нужно (тем более в Си, о котором идёт там речь). Но само отношение Линуса к Вирту, Дейкстре и CS в целом заставляет, вообще говоря, задуматься о его профпригодности:
No, you've been brainwashed by CS people who thought that Niklaus Wirth actually knew what he was talking about. He didn't. He doesn't have a frigging clue.
> I thought Edsger Dijkstra coined the "gotos are evil" bit in his structured programming push?
Yeah, he did, but he's dead, and we shouldn't talk ill of the dead. So these days I can only rant about Niklaus Wirth, who took the "structured programming" thing and enforced it in his languages (Pascal and Modula-2), and thus forced his evil on untold generations of poor CS students who had to learn langauges that weren't actually useful for real work.
ответить
Что, простите? :-)
В чьей-чьей профнепригодности вы собрались сомневаться? Торвальдса? Ну сомневайтесь, сомневайтесь. На здоровьечко.
Между прочим, не знаю как раньше, а сейчас, после Оберона, по мне так Вирта всерьёз воспринимать уже нельзя.
Не, ну Торвальдс тоже не бог, конечно, и, по-видимому, сишность головного мозга у него на всю катушку присутствует, но, между нами говоря, ему — можно.
ответить
Да,
Да, действительно. Неудачно выразился. Линус Торвальдс, безусловно, очень профессиональный разработчик ядра линукс на языке Си. Даже несмотря на то, что начинался линукс как совершенно наколенное поделие, за 30 лет, конечно, профессионализм можно накопить очень приличный.
Знаете, есть такой анекдот, "да что тут думать, тут трясти надо". Вот Линус тут мне напоминает очень профессионального трясуна.
Я ни в коем случае не хочу преуменьшать его заслуг. В конце концов, я сам полтора десятка лет плотно жил в линуксе (хотя, опять же, не было бы линукса, жил быв какой-нибудь BSD, может даже и лучше бы вышло). Но вот то, с какой лёгкостью он сам преуменьшает чужие заслуги, сильно обесценивает в моих глазах его мнение.
Ну посудите сами, ведь по сути он говорит что-то вроде: "CS не нужно и только мешает, мы и так нормально
трясёмпилим ядро". И ведь обязательно найдутся люди, которые эти слова напишут на знамени, Линус Торвальдс же авторитетный профессионал.ответить
Лично ему CS
Лично ему CS действительно не нужен, и что теперь? Причём я бы даже несколько удивился обратному.
ответить
☞ From Sergei (unverified) Tue Apr 21 21:14:00 2020 UTC
Монтирование внешних устройств
Здравствуйте!
Много раз на этом сайте Вы отмечали, что не стоит использовать Desktop Environment, который помимо рисования окошек отвечает много за что ещё. Среди этого "чего-то ещё" присутствует монтирование съёмных устройств: флэшек, USB-дисков, и т.д.
Закономерным образом возникает вопрос: как именно следует их монтировать "правильно", на ваш взгляд? В голову приходят варианты:
1) Из текстовой консоли под root-ом. Не всегда приемлемо.
2) Прописать в fstab. Проблематично, так как туда заносятся фиксированные имена устройств.
3) Использовать pmount или его аналог. Возникает вопрос о безопасности данной утилиты (к монтированию через DE это тоже относится).
4) Какой-то неизвестный мне способ?
ответить
Desktop Environment,
Desktop Environment, который помимо рисования окошек отвечает много за что ещё.
Мне вот интересно, что должно произойти с мозгом, чтобы в него приходили подобные идеи. Кора должна атрофироваться? Или что? Как вообще можно допустить мысль, что никчёмная (я на этом настаиваю) графическая приблуда нужна для чего-то ещё, кроме рисования этих своих иконок и что того же эффекта нельзя получить без неё.
1) Из текстовой консоли под root-ом. Не всегда приемлемо.
Практически никогда не приемлемо. Ради флешки каждый раз рутом заходить — очевидный перебор.
2) Прописать в fstab. Проблематично, так как туда заносятся фиксированные имена устройств.
Фиксированные? Да неужели? И что из этого? У вас их что, так много бывает разных?
Вот, если что, мой кусок fstab'а:
В большинстве случаев требуется только sdf, остальные появляются крайне редко. Устройства, не входящие в этот список, для usb stick'а моя система не задействовала ни разу, иначе они были бы уже в списке.
3) Использовать pmount или его аналог. Возникает вопрос о безопасности данной утилиты (к монтированию через DE это тоже относится).
Ну уж во всяком случае она точно не опаснее, чем DE. Хотя бы исходя из объёма кода. Оконным приложениям вообще нельзя ничего критического доверять, одна Xlib для этого уже слишком жирная, а всякие gtk/qt/... (подставить по вкусу) — это вообще не такие программы, относительно которых можно всерьёз говорить о безопасности.
Можно ещё и udev сконфигурить, чтоб флешки автоматически монтировал, или есть такой пакетик usbmount (он в том числе и udev переконфигурирует, но не только, у него бинарник свой). Есть, в принципе, ещё много чего.
А ещё есть основополагающий принцип: если для решения какой-то задачи есть графическая приблуда, а сама задача с графикой не связана (то есть это не видеоплеер, не смотрелка для фоток, не браузер и не какой-нибудь визуализатор графов), то та же задача может быть решена без GUI. Исключений в мире *nix я не видел ни разу.
ответить
Благодарю за
Благодарю за ответ!
По поводу неправильности использования DE для монтирования я, безусловно, согласен, иначе и не задавал бы этот вопрос. В пользу этого говорит даже то, что то же XFCE начинает работать намного стабильнее, если из него выпилить всё лишнее, включая автомонтирование и иконки на рабочем столе, оставив, по сути, оконный менеджер и панель с индикаторами различных параметров. С монтированием в этом плане вообще всё плохо. Доходило до того, что примонтированные с помощью DE устройства периодически приходилось отмонтировать вручную под root-ом, так как иначе всё это поделие зависало в хлам.
По поводу приведённого куска fstab: ну всё же это выглядит как костыль. Да, в реальной жизни он работает, а по мере добавления новых устройств можно добавить новые строчки. Но во-первых, fstab после этого начинает выглядеть уродливо, а во-вторых, это решение выглядит как заматывание разваливающейся конструкции синей изолентой по мере того, как она разваливается. Кстати, несколько неожиданный у вас fstab: у вас на флэшках логические разделы присутствуют? ;)
Видимо, в моём случае действительно больше всего подходит pmount -- пока с ним проблем не замечаю.
usbmount и предложенный в комментарии выше ldm тоже посмотрю, спасибо! В любом случае я предпочёл бы, чтобы устройство монтировалось вручную: автоматическое выполнение каких-либо действий при вставке носителя (кстати, многие DE этим грешат) весьма сомнительно в плане безопасности, а также не всегда нужно: может я хотел отформатировать устройство или снять с него образ -- зачем его монтировать.
...а сама задача с графикой не связана (то есть это не видеоплеер, не смотрелка для фоток, не браузер и не какой-нибудь визуализатор графов), то та же задача может быть решена без GUI.
Более того, зачастую это возможно даже если задача связана с графикой. Взять тот же imagemagick...
ответить
По поводу
По поводу приведённого куска fstab: ну всё же это выглядит как костыль
Когда fstab придумывали, USB mass storage не было. Потому и "выглядит". Откровенно говоря, что бы ни работало с USB, будет выглядеть как костыль, потому что само USB изначально бастард.
fstab после этого начинает выглядеть уродливо
Уж не уродливей, чем при использовании UUID'ов, как это сейчас по умолчанию делается.
это решение выглядит как заматывание разваливающейся конструкции синей изолентой по мере того, как она разваливается.
Пока что ни разу не развалилось. Синей изолентой скорее все эти pmount'ы выглядят.
у вас на флэшках логические разделы присутствуют?
Во-первых, если Debian с флешки ставить будете, тут же обнаружите, что там аж три раздела. Во-вторых, кроме флешек, у меня в ходу ещё usb hard drives, и там у меня всегда два раздела — ext4 для своих бекапов и NTFS, чтоб у друзей видосики утаскивать (ну и притаскивать их друзьям, соответственно, тоже).
Взять тот же imagemagick...
... а ещё LaTeX, gnuplot, ffmpeg — это только то, что с ходу в голову пришло.
ответить
что бы ни
что бы ни работало с USB, будет выглядеть как костыль, потому что само USB изначально бастард
Эх, прекрасным был бы мир победившего Ethernet'а, мне думается. Ну, сделали бы разъем покомпактнее, были бы такие же почти хабы, из которых сейчас у всех пучок флешек торчит. "И все так чинно-благородно, по-старому", и никаких бы недостандартов с поллингом не надо было изобретать.
ответить
немного о безопасности
В любом случае я предпочёл бы, чтобы устройство монтировалось вручную: автоматическое выполнение каких-либо действий при вставке носителя (кстати, многие DE этим грешат) весьма сомнительно в плане безопасности
Гм. А в чём, по-вашему, безопасность ручного монтирования устройств выше автоматического?
Автозапуск всяких файлов с устройства, как в винде было, это да, небезопасно. Но при чём здесь монтирование?
А так-то физическое подключение внешнего USB-устройства к компьютеру само по себе действие, вообще говоря, весьма небезопасное. В силу ублюдочности спецификаций USB, устройство может оказаться чем угодно (в том числе и вовсе не тем, что вы о нём думали). Скажем, оно может представиться компьютеру как клавиатура и начать нажимать какие-нибудь кнопки. Это уже не говоря о банальном сжигании материнской платы специально сконструированными псевдо-флешками, которое возможно благодаря тому, что далеко не на всех платах USB-вход корректно электрически развязан.
ответить
Согласен,
Согласен, подключение USB-устройства -- действие небезопасное, и это подтверждает то, о чём написал автор сайта:
само USB изначально бастард
В этом смысле USB ещё хуже, чем JavaScript на сайтах. Последний хотя бы можно контролировать, запуская браузер под отдельным пользователем, в виртуальной машине или как-то ещё. От уязвимости BadUSB адекватной защиты вроде как нет, во всяком случае, программной.
Тем не менее, я не исключаю возможности наличия уязвимости в драйвере файловой системы, например. Поэтому даже если флэшка является флэшкой, иё монтирование может быть небезопасным. Кроме того, от автомонтирования всего один шаг до автозапуска -- мало ли что туда разработчики напихали?
Кроме того, помимо безопасности есть ещё и технический момент. У меня, например, несколько пользователей, для которых запускаются при входе в систему различные WM/DE. И когда нельколько пользователей зашли в систему одновременно (с разных виртуальных терминалов), то при втыкании флэшки каждое DE считает нужным её смонтировать именно для того пользователя, от имени которого оно запущено. Например, так любит делать MATE с настройками по умолчанию. А при извлечении флэшки в графическом режиме DE часто норовит вместо отмонтирования полностью отключить устройство так, что его уже не видно в /dev.
ответить
мало ли что
мало ли что туда разработчики напихали?
Это можно сказать про любую программу. Этот вопрос -- хороший повод отказаться от использования программ с закрытым исходным кодом и от программ с открытым, но переусложнённым исходным кодом. Код должен быть доступен для чтения, а переусложнённость в этом плане равноценна закрытости.
В случае линукса, к сожалению, это означает отказ от линукса в целом, так как ни самостоятельно читать код ядра, ни доверять тем людям, которые его пишут, я не готов.
при втыкании флэшки каждое DE считает нужным её смонтировать именно для того пользователя, от имени которого оно запущено.
И вот именно поэтому задачей автомонтирования устройств должен заниматься системный демон, а не DE. Это в копилку того, почему DE не нужны.
Но можно и вручную, конечно.
ответить
Класс
Приятно знать, что всё-таки есть люди, ещё более повёрнутые на всём этом, чем я :-)
ответить
взаимно
У меня примерно такое же чувство возникает, когда я ваши комментарии (здесь или на ЛОРе) читаю. :-)
ответить
Этот вопрос --
Этот вопрос -- хороший повод отказаться от использования программ с закрытым исходным кодом и от программ с открытым, но переусложнённым исходным кодом.
Это, к сожалению, не всегда возможно. Как и отказ от сайтов, использующих JavaScript. Поэтому приходится искать компромиссы. Например, закрытая/переусложнённая программа, выполняющаяся с правами root, в плане безопасности намного хуже закрытой/переусложнённой программы, выполняющейся с правами ограниченного пользователя.
А, например, закрытый модуль ядра -- вообще сомнительный шаг. Это, впрочем, не значит, что я ими не пользуюсь. В частности, я вынужден держать у себя на одной из машин проприетарный драйвер NVIDIA, так как это необходимо для работы. Но отдавать себе отчёт в этом в любом случае следует, а именно, при установке соответствующего драйвера я теперь вынужден доверять разработчикам NVIDIA. При этом при установке чего-то ещё я буду подобное решение принимать отдельно, подбирая баланс между доверием к разработчикам и необходимостью использовать данное ПО. В конце концов, есть ещё прошивка BIOS/UEFI, а она, как правило, всё же проприетарная, а по сложности может превосходить иную операционную систему.
Возвращаясь к переусложнённым программам -- здесь в зависимости от ситуации можно действовать по-разному. Например, любой современный веб-браузер -- программа априори переусложнённая (если не брать lynx или links, в которых работает полтора сайта). Поэтому доверять ему особых оснований нет. Однако можно запустить браузер от имени ограниченного пользователя и/или в виртуальной машине/контейнере и/или на отдельном физическом компьютере, в зависимости, опять же, от уровня паранойи и доверия к соответствующим инструментам. А какой-то программе, работающей с пользовательскими данными, можно наоборот, запретить доступ в сеть. К сожалению, единственный известный мне более-менее надёжный способ это сделать также связан с запуском из-под отдельного пользователя.
В случае линукса, к сожалению, это означает отказ от линукса в целом, так как ни самостоятельно читать код ядра, ни доверять тем людям, которые его пишут, я не готов.
Интересно. И какой же системой пользуетесь, в таком случае, если не секрет? Своё ядро разработали? ;) Насколько я понимаю, полное изучение кода ядра более-менее любой современной ОС общего назначения -- задача нереальная для одного человека.
Но можно и вручную, конечно.
Это же логично! Отмонтирование же делается вручную, значит и монтирование должно делаться так же. С чего вдруг я должен отмонтировать то, что я не монтировал? Процесс вставки и извлечения устройства должны быть симметричными)
ответить
А я пользуюсь
А я пользуюсь mplayer. Программа вроде как бы и графическая, но почему-то работает и без иксов, показывая видео прямо поверх текстовой консоли. Да и в иксах показывает только окно с видео и всё, нет никаких графических элементов, а управляется с клавиатуры.
SoX умеет визуализировать спектр аудио, но при этом выводит результат в графический файл, а не на экран.
ответить
Совершенно
Совершенно верно, на примере mplayer хорошо видна разница между программой, работающей с графикой, и программой, имеющей графический интерфейс.
ответить
Дополню Андрея
Дополню Андрея по поводу автомонтирования.
Есть такой лёгкий демон ldm. Он у меня неплохо работает на компе пожилых родителей в комплекте с IceWM и лёгким файловым менеджером ROX-filer (они привыкли к винде с иконками, да).
ответить
Добавлю... В
Добавлю... В файле /etc/fstab, вместо фиксированныъ имен устройств, лучше использовать UUID устройства, так как имя устройства может поменяться, по мере подключения друних устройств, а вот UUID не поменяется. Команда lsblk покажет имена устройств, и куда они смонтированы, а blkid покажет UUID всех подключенных к системе устройств.
Команда blkid | grep [имя_устройства] | cut -d' ' -f2 | tr -d '"' даст Вам UUDI интересуюущего Вас устройства. Остается потом только это дело записать в /etc/fstab
ответить
Охренеть теперь
Даже решил раскрыть этот комментарий, хотя, конечно, для его автора это последний комментарий, который здесь появился в открытом виде.
Интересно, вот откуда таких людей берут, а? Скажите мне, и я туда не пойду (c).
Нет, разумеется, использовать UUIDы не только не "лучше", их вообще нельзя использовать -- хотя бы потому, что они не human-readable. То есть, глядя на UUID, нормальный психически здоровый человек не поймёт, от какого из его дисков этот UUID. Классическое линуксовое имя устройства при этом вполне себе читаемо, хотя, конечно, мысль выпилить IDE и сделать доступ к IDE-дискам через эмулятор SCSI -- это была эпично дебильная идея в своё время; ну да ладно, IDE сейчас мало у кого остался. Так или иначе, если имена устройств для встроенных в комп жёстких дисков вдруг "поплыли", есть самый прямой смысл выяснить, что за хрень происходит, и заставить эту хрень перестать происходить.
Но вот сейчас речь шла вообще о флешках. Йолки-моталки, у меня в хозяйстве десятка три разных флешек, если считать все карточки от фотоаппаратов, всяких Raaspberry Pi и прочего такого. Мне что, в fstab на всех настольных машинах прописать все эти UUIDы? Они, между прочим, форматируются то и дело, UUIDы при этом меняются. А когда ко мне кто-нибудь в гости пришёл с флешкой, мне под рутом заходить и fstab редактировать?
Ей-богу, ньюфагов отстреливать пора. Исключительно из санитарных соображений.
ответить
Так или иначе,
Так или иначе, если имена устройств для встроенных в комп жёстких дисков вдруг "поплыли", есть самый прямой смысл выяснить, что за хрень происходит, и заставить эту хрень перестать происходить.
А это вообще возможно? Я неоднократно сталкивался с проблемой, описанной автором предыдущего комментария: когда в fstab монтирование дисков было прописано по непосредственному имени устройсва, а жёстких дисков было несколько, то система загружалась через раз из-за того, что какой из дисков станет sda, а какой sdb, определяется рандомно. Если вы знаете, как это исправить, мне было бы очень интересно получить ответ. В прошлом году я из-за этого чуть было не потерял данные, указав команде dd в качестве параметра of не то устройство из-за того, что после перезагрузки номера устройств "поплыли". К счастью, для данных на первом разделе была резервная копия, а второй раздел удалось восстановить, так как я быстро обнаружил проблему и остановил команду dd, а второй раздел был смонтирован, и через данные файловых систем /proc и /sys таблицу разделов удалось вернуть на место.
По поводу нечитаемости UUID: для не-сменных носителей теоретически ещё можно метку тома (label) использовать, это решает проблему с нечитаемостью. Для съемных носителей вроде флэшек и USB дисков это, естественно, не годится.
ответить
Такое обычно
Такое обычно происходит, когда подключено больше одного диска SATA. libata в ядре реализована чёрт-те как, куда Торвальдс смотрит, непонятно — для меня очевидно, что этот модуль ну вот просто обязан принимать параметры, указывающие, под какими именами следует регистрировать обнаруженные диски, но таких для него не предусмотрели.
Сам я в такие ситуации не попадаю, поскольку у меня в хозяйстве ещё даже не все IDE вымерли, а два SATAшника в одной машине не встречались пока что никогда. Но если это и стряслось — ну не UUIDы же использовать — хотя бы label'ы или partlabel'ы, и то и другое можно сделать человекочитаемым и мнемоничным.
В любом случае вся эта кривизна — скорее повод избегать двух SATA-винтов в одной машине, а если уж никак не получается — то вот тогда, и не раньше, перейти в fstab от имён устройств к тем или иным меткам.
ответить
Такое обычно
Такое обычно происходит, когда подключено больше одного диска SATA.
Не только SATA -- с пресловутым USB то же самое) Более того, в тот раз, когда я тогда вызвал неправильно команду dd, поменялись имена дисков USB и SATA. Правда с UUID и fstab это уже не связано, так как внешние диски я в fstab обычно не прописываю, даже те, что воткнуты всё время.
В любом случае вся эта кривизна — скорее повод избегать двух SATA-винтов в одной машине
У меня их 5... а IDE на современных материских платах уже не делают физически. Поэтому монтировать по имени устройства, увы, не вариант. Наверное, правильнее было бы, действительно, использовать label, но пока дисков меньше десятка, вариант с UUID-ами поддаётся пониманию, особенно учитывая, что рядом с каждой записью в fstab есть комментарий, в котором указано линуксовое имя устройства и метка -- правда нужно при ручном редактировании следить за тем, чтобы эти комментарии не перемешались. Была мысль перейти на использование label-ов, чтобы избавиться от комментариев, но руки так и не дошли.
На самом деле, понятно, почему по умолчанию используются UUID-ы: установщики популярных дистрибутивов не предполагают наличия у человека, ставящего систему, тайных знаний об fstab и рандомном порядке определения устройств, поэтому и используют UUID-ы, чтобы из коробки проблем было меньше. А те, кто всё это знают, отредактируют руками как им надо, а то и вовсе будут пользоваться дистрибутивом, не предполагающим использование программы-инсталлятора (gentoo, arch, и иже с ними), где этот файл пишется руками в процессе установки.
ответить
На современных
На современных материнских платах делают IntelME. У меня есть одна машинка "современная", она обычно выключена, и, конечно, ничего серьёзного я на ней делать не собираюсь — брал её специально под видеомонтаж, но всерьёз до монтажа руки всё ещё не дошли, иногда под настроение на ней кино смотрю (файлы притаскиваю на неё через другой комп, интернет с её ip-адреса недоступен). А ещё есть один интересный казус: я-то сисадминство оставил в прошлом веке, а один приятель, который до сих пор именно этим зарабатывает деньги, мне сказал, что если имена дисков эдак вот плавают -- нужно менять контроллер (если он на борту -- значит, всю материнку) и что "нормальные" (ну, в его понимании нормальные) контроллеры такого бардака не устраивают.
С USB-дисками вроде бы вопрос решается через udev, если считать сам udev допустимым.
Всё остальное, гм... если вам удобнее UUIDы, то ради бога (хотя мне этого вовек не понять, они же нечитаемы абсолютно); просто тредстартер заявил, что их "лучше использовать", не уточнив контекст — вот это уж вообще никак.
ответить
☞ From Anonymous (unverified) Sun Apr 12 06:18:00 2020 UTC
Выбор ОС для изучения Unix-а
Здравствуйте! Начал читать 1-ый том и добрался до параграфа "Unix на домашней машине". Хочу выбрать ОС, чтоб хоть чуть-чуть понять Unix. На фоне последних коментариев у вас на сайте думаю не пользоваться Linux-ом, а взять FreeBSD и поверх него X.org + Xfce. Хорошая ли это идея для начального обучения или всякие Ubuntu тоже сойдут?
ответить
Идея-то хорошая, гм...
Для начала -- зачем вам Xfce, это же desktop environment. Возьмите IceWM или что-то ещё такое, что не рисует иконок.
Что до FreeBSD, то идея, несомненно, хорошая, если вы справитесь её поставить и настроить. Для начинающих это довольно сложно (хотя и не скажу, чтобы совсем невозможно).
Ubuntu годится довольно условно -- то есть в принципе годится, но лучше всё-таки какой-нибудь другой дистрибутив. Хоть даже тот же Devuan.
ответить
Спасибо за советы
Спасибо вам Андрей Викторович за совет (да двум другим комментатором тоже). Попробую поставить на разные логические диски Free- и OpenBSD с window manager, потом походу дела буду решать какой использовать (если не получится не один из поставить, тогда уж "дружественные" к новичкам Ubuntu).
ответить
по OpenBSD
Вся информация по установке и настройке базовой системы доступна на официальном сайте и в man pages в установленной системе (разработчики OpenBSD очень серьёзно относятся к документации). Перед установкой в первую очередь надо внимательно прочитать FAQ. (Так как позавчера в работе openbsd.org возникли перебои и он доступен не полностью, то вот ссылка на зеркало.)
Но практически вся актуальная информация -- только на английском. Если на другие языки что и переводят, то этого мало и оно быстро устаревает.
ответить
Unix на домашней машине
Доброго времени суток. Хотел бы поделиться опытом в теме изучения Linux'а среди начинающих. Сам пользуюсь Linux-ом уже 3 года, и изучаю программирование по книжкам Андрея Викторовича. Если вы начинающий, вряд ли вы столкнётесь в процессе обучения программированию с системами инициализации(я спустя три года изучения до этого ещё не добрался), а работа с консолью, компиляция программ, настройка пользовательского окружения и т.д. во всех Unux'ах +- одинаковая. Поэтому, с моей точки зрения, не стоит быть таким категоричным в отношении Linux'а. Попробуйте начать с "Дружественных" дистрибутивов по типу Убунты или Минта, хотя все дистры с графическим интерфейсом из коробки ставятся не очень сложно, и тут имеет смысл просто попробовать разные варианты. По мере накопления опыта и навыков, вы сами начнёте понимать, что в системе работает плохо, а что хорошо. Главное эти опыт и навыки получить, ну а потом вы сами сможете принять осознанное решение, какая система лучше, а какая хуже. Тем более для вас не будет проблемой поставит FreeBSD или что либо ещё. Сейчас же для вас куда важнее просто начать работать в Unix'е каким бы он ни был.
P.S. Также знание английского языка поможет сильно сократить время обучения. Лично я очень жалею, что не смог его выучить. Информация по любой детали системы доступна либо в manах либо в интернете. Не пренебрегайте этим.
P.S.S. Попробуйте посмотреть в сторону manjaro xfce, бысто ставится, не требовательна к ресурсам и выглядит красиво, хорошая замена убунты.
ответить
Хотел бы
Хотел бы поделиться опытом в теме изучения Linux'а среди начинающих.
Тут дело в изначальной постановке задачи.
Если цель -- изучить линукс, то, конечно, надо ставить линукс. Естественно, не отягощённый поттеринго-софтом, который изучать совершенно не нужно и даже вредно.
Если цель -- научиться программировать по книгам уважаемого хозяина этой странички, то сойдёт любая рабочая юниксо-подобная система. Пусть даже и линукс, пусть даже и голимая убунта с системд. Всё равно сталкиваться с этими какашками, вероятно, почти не придётся.
Если же цель -- изучить юникс, то имеет смысл сразу прививать хороший вкус и начинать сразу с какой-нибудь BSD-системы.
ответить
Поповоду целей
Хочется выработать небольшую базу для понимания происходящего с компьютером, а потом идти в свободное плавание программирования (а всякие там популярные курсы для начинающих говорят: "Ты можешь делать так, но что творится с машиной, даже чуть-чуть мы тебе не скажем").
Ещё изучить Юникс во всей красе для понимания, что есть иной путь отличный от Винды, и он может быть лучше майкрософтовского детища.
ответить
Ясен пень
а всякие там популярные курсы для начинающих говорят: "Ты можешь делать так, но что творится с машиной, даже чуть-чуть мы тебе не скажем")
Те, кто понимают, что творится с машиной, не преподают на курсах, ибо им некогда :-)
ответить
Курсы "программирования"
популярные курсы для начинающих говорят: "Ты можешь делать так, но что творится с машиной, даже чуть-чуть мы тебе не скажем"
Потому что тамошние "преподаватели" этого сами не понимают. Но ещё больше доставляют "современные айтишники" из ютуб-роликов, строящие из себя "гуру", но при этом уходящие в бесконечный цикл при упоминании собеседником чего-то по типу "топология сети". Естественно, что кроме пропаганды потребительства, глупости, макбучков, пользования веб-поделиями и других проявлений "прогресса" в этих роликах ничего нет. Но направить начинающего по ложному пути эти средства пропаганды глупости вполне себе могут. Вполне вероятно, что подобные деятели ведут подобные курсы, поэтому нужно крайне критически относиться к выбору методов и средств обучения.
Сейчас, когда факт того, что язычки скриптовых поделок абсолютно не подходят для создания чего-то сложнее хеллоуворда стал более-менее очевиден не совсем потерянным представителям индустрии, появился тренд на изучение С++. Но изучать его предлагают настолько извращённым способом, что лучше его не изучать совсем. Мало того, что обучать берутся типично STL-ному его варианту, так ещё и советуют пропустить plain С. Очевидно, что на выходе будет макака. Если вам предложат что-то подобноее, сразу же разворачивайтесь и уходите от такого псевдо-преподавателя.
ответить
Я бы всё-таки
Я бы всё-таки заменил "потребительство" на "потреблядство" :-) В потреблении как таковом ничего плохого в сущности нет, это не более чем удовлетворение потребностей (реально существующих), т.е. то, ради чего вообще совершаются любые осмысленные действия. Иное дело, когда потребность, как сказали бы математики, чисто мнимая, синтезированная на пустом месте из ничего с помощью рекламы.
ответить
Позвольте
Позвольте посоветовать OpenBSD. Для изучения Unix'а, в силу своей простоты, подходит ещё больше, чем FreeBSD. Но при этом вполне рабочая система. Да и с "поставить и настроить" в ней я особых проблем не наблюдаю. (Хотя, конечно, адекватно оценить это с позиции "начинающего" не смогу.)
Засада только одна: не всё железо поддерживается. Например, практически не поддерживаются видеокарты Nvidia, в силу особо тщательно закрытых спецификаций. Но уж если железо поддерживается, то никаких других значительных проблем с OpenBSD я не вижу.
Xfce не ставьте, тут я с Андреем полностью согласен. Поставьте какой-нибудь простой оконный менеджер (window manager, в противовес сложному desktop environment), помимо IceWM есть ещё, например, JWM, Fluxbox, Openbox, и многие другие.
А вот Devuan и прочие деривативы Debian я бы не рекомендовал для "изучения Unix". Мало того, что линукс в принципе во многом отступает от классических принципов Unix, так дебиан с последователями ещё добавляет туда приличное количество собственной специфики, которая нигде, кроме дебианов, неприменима.
ответить
Пожалуйста,
Пожалуйста, разверните свой ответ по поводу предпочтения OpenBSD в противовес FreeBSD. Не ради холивара, в данный момент мне тоже предстоит сделать выбор. Интересуют доводы более опытных товарищей. Спасибо.
ответить
Сразу скажу,
Сразу скажу, что провести полноценное техническое сравнение OpenBSD и FreeBSD я не смогу, так как последний раз сам активно работал с FreeBSD больше 15-ти лет назад (и больше в качестве сервера, чем десктопа).
Более-менее технический аргумент у меня один, уже упомянутая простота устройства системы (без значительной потери функциональности, естественно). Эта означает, что мне проще понять, как система работает, проще разобраться, почему она не работает или работает не так, как мне надо, проще самому что-то починить или, по крайней мере, составить адекватный баг-репорт. Также это означает, что всё вышперечисленное проще не только мне, но и разработчикам системы. А OpenBSD определённо проще, чем FreeBSD.
Остальные аргументы больше идеологические, чем технические (хотя, конечно, всё взаимосвязано).
Например, по моим ощущениям, FreeBSD стремится быть догоняющей системой по отношению к Linux. (Тут, кстати, был интересный комментарий на эту тему). А я почти уверен, что линукс идёт не туда и надо не догонять, а идти в совершенно другую сторону.
Ещё момент: в среде разработчиков FreeBSD считалось (а возможно и сейчас считается) совершенно нормальным держать в качестве основной десктопной рабочей системы, например, какой-нибудь макбук с макосью на борту. (Вот тут George Neville-Neil, один из основных разработчиков FreeBSD, соавтор МакКузика по книге The Design and Implementation of the FreeBSD Operating System, упоминает, что сам довольно долгое время пользовался макбуком, и что на FreeBSD-конференциях половина присутствующих с макбуками — это норма.) А это значит, что сами эти разработчики не интересуются использованием FreeBSD на десктопе. Среди разработчиков OpenBSD, напротив, считается обязательным использование OpenBSD на своих рабочих десктопах. Для меня это означает, что процент разработчиков, делющих систему для личного пользования, в OpenBSD заметно выше, чем во FreeBSD.
Тут надо сделать лирическое отступление: лично я считаю, что хороший софт (да и вообще, хорошую вещь) можно сделать только в том случае, если он делается либо для себя любимого, либо, в крайнем случае, под строгим контролем непосредственного будущего пользователя этого софта. Когда программисты начинают писать программы для "сферического тупого юзера в вакууме", они начинают городить несусветную чушь. А уж если к этому процессу подключаются маркетологи, то, простите, тут цензурные слова у меня заканчиваются.
Пожалуй, для меня это главный аргумент в выборе OpenBSD: люди делают эту систему для себя. Я мог бы ещё добавить, чем мне нравится подходы к разработке OpenBSD, но в рамки именно сравнения с FreeBSD это уже не вписывается.
ответить
маленькое уточнение, чтобы не было недопонимания
Среди разработчиков OpenBSD, напротив, считается обязательным использование OpenBSD на своих рабочих десктопах.
В смысле, как десктопную систему. То есть, и на десктопах, и на ноутбуках.
ответить
NetBsd
Что вы можете сказать о NetBsd, просто мне удалось установить только эту OS.
ответить
К сожалению,
К сожалению, ничего толкового сказать не могу, поскольку не пользовался.
Несколько раз слышал мнения, что она менее практична, чем OpenBSD или FreeBSD. Что для её разработчиков это больше playground для проверки разных новых идей и технологий. Но встречал на просторах интернета и пару человек, которые утверждали, что предпочитают именно её в качестве десктопной системы.
В любом случае, если бы кроме Linux и NetBSD других доступных систем не было, то лично я сначала бы попробовал использовать NetBSD.
ответить
☞ From Gleb (unverified) Sat Apr 4 16:29:00 2020 UTC
1 чась 1-го тома
Здравствуй Андрей! Какую дополнительную литературу прочитать, чтобы осмыслить текст первой части первого тома. Дело в том я закончил 7 классов и многое из разряда математики я не понимаю, а страницы пропускать не хочется.
ответить
Честно говоря,
Честно говоря, не знаю, я никогда не занимался ни с кем школьной математикой (когда-то давно занимался абитуриентской, то есть готовил к вступительным экзаменам, но это совершенно другое дело). Поэтому я просто не в курсе, какая на эту тему есть литература.
А что конкретно непонятно? Может быть, совместно сумеем разобраться?
ответить
Абитуриентская математика
Здравствуйте, Андрей Викторович. А какие советы можете дать изучению математики для абитуриентов (учебники, книги, статьи)? Хочется повторить лично для себя и восполнить пробелы.
ответить
Depends
Это очень сильно зависит от того, куда вы собираетесь поступать. Но вообще тут вы совсем не по адресу, я уроков математики не проводил уже лет пятнадцать, всё давно забыл. Задайте этот вопрос на каком-нибудь тематическом форуме, толку будет больше.
ответить
Формулы комбинаторики и Бином Ньютона
Саму суть комбинаторики я понимаю, вы это хорошо объяснили на пальцах, но формулы... А Бином Ньютона вообще пришлось пропустить.
ответить
То есть что, вы
То есть что, вы не умеете читать формулы? Или дело не в этом?
Уж бином-то, гм... реально прост как валенок.
ответить
Да.
Да. Именно формулы я читать не умею. Без математики некуда.
ответить
Так-с
Ну вот давайте попробуем понять, как снять эту проблему. Возьмите книжку, начните "математический" раздел с начала, дойдите до первой формулы, которая оказалась непонятна, и здесь в комментах расскажите, какая формула на какой странице вам "не далась".
ответить
Перечитал главу и вот
Перечитал главу и вот я ожидал что найдутся те формулы, которые я не понимаю, но нет ... я их все понял. Спасибо!
ответить
На самом деле так часто бывает
Как в том анекдоте: главное — не ба-ба-ба-баяцца.
А если серьёзно, то при попытке внятно сформулировать возникший вопрос примерно половина вопросов благополучно отпадает. Я учеников обычно прошу все возникшие вопросы сформулировать обязательно на бумаге, обязательно от руки и обязательно в виде грамматически корректного вопросительного предложения с вопросительным знаком на конце. Совершенно дебильная мнемотехника, но работает со страшной силой.
ответить
Есть вот такая
Есть вот такая книжка. У неё, правда ненулевой порог вхождения, она рассчитана на 8-10 класс матшколы, поэтому что-то может оказаться непонятным с первого раза. Но там есть как формулы, так и сопровождающий их текст.
http://www.kvant.info/panov/enciklop.pdf
ответить
Извините за
Извините за ответ на столь древний комментарий.
Правильная книжка для школьников по комбинаторике так и называется - "Комбинаторика", автор - Виленкин Наум Яковлевич (в более поздних изданиях в соавторы добавились его дети, тоже Виленкины).
ответить
☞ From Anonymous (unverified) Wed Apr 1 15:46:00 2020 UTC
Чистая компиляция
Андрей Викторович, планируете ли Вы работу над языком в парадигме чистой компиляции?
ответить
Очень хочется
Очень хочется сказать, что да — но нет. Без внешней поддержки мне это не поднять.
ответить
Сколько по
Сколько по Вашим оценкам понадобиться для этого денег и людей?
Или дело не только в этом?
ответить
В основном,
В основном, конечно, именно в этом.
Сколько? Ну, тут нужно два-три года разработки и команда из трёх-четырёх очень серьёзных программистов, плюс два-три человека чуть попроще. Плюс помещение, накладные расходы в виде всяких отчислений на фонд з/п... в общем, бюджет этого дела составит лямов этак пятьдесят в нынешних ценах.
Если найдутся те, кто готов это финансировать (причём, как мы понимаем, без внятных гарантий результата), то, очевидно, с внедрением потом проблем уже не будет :-) Те, у кого есть деньги такого порядка "на игрушки", внедрять обычно умеют.
ответить
Standalone vs Docker
Правильно ли я понимаю, что такой язык позволит избавиться от Docker-а и других подобных систем контейнеризации? Т.е на выходе мы получаем бинарный файл, который при условии использования кроссплатформенных библиотек может быть запущен на многих ОС? Либо же как второй вариант, можно скомпилировать несколько бинарников, каждый для своей целевой ОС.
Нельзя ли воспользоваться моделью разработки Линуса Торвальдса, т.е организовать "открытую" разработку, авось потом и бизнес подтянется с его дотациями? По сути такой язык был бы своего рода революцией.
Какую бы литературу Вы посоветовали чтобы ознакомиться с созданием языков в принципе?
ответить
У вас в голове чёрт-те что
> такой язык позволит избавиться от Docker-а
Чтобы "избавиться от Docker'а", нужен не язык, а пулемёт. Перестрелять макак, использующих интерпретируемые языки в роли языков общего назначения — и никакой докер больше не потребуется.
Компилируемые языки есть и сейчас — C, C++, Pascal и т.п.
> на выходе мы получаем бинарный файл, который при условии использования кроссплатформенных библиотек может быть запущен на многих ОС?
Категорически нет. Чистая компиляция в обсуждаемом смысле предполагает, что полученный исполняемый файл не имеет иных зависимостей, кроме ядра ОС, и, как следствие, ни о каких "кроссплатформенных библиотеках" речи идти не может. Кроме того, бинарная переносимость между различными ОС (если речь идёт именно о разных ОС, т.е. разных ядрах, а не, например, о разных дистрибуциях того же Linux) может быть обеспечена разве что самим ядром (например, ядро FreeBSD поддерживает набор системных вызовов для линуксовых бинарников), и это совершенно омерзительный хак. В норме такой переносимости быть не должно. Она, впрочем, и не нужна.
Если же говорить о различных версиях юзерспейсовского окружения, то нормально написанной программе должно быть глубочайшим образом наплевать на то, в составе какого окружения её используют. Это, заметим, безотносительно "языка с чистой компиляцией", для этого просто нужен компилируемый язык, допускающий статическую сборку -- такие есть и сейчас.
> организовать "открытую" разработку
Начинайте, вам никто не мешает. А то советы давать все горазды.
На меня, если что, при этом можете не рассчитывать. Меня не привлекает идея на выходе получить такого ожиревшего бастарда, в которого в итоге превратилось ядро Linux.
> Какую бы литературу
Мне не удалось найти никаких исследований в направлении чистой компиляции. Как следствие, порекомендовать ничего не могу.
ответить
Докер не нужен
Есть мнение, что докер станет не нужен сам по себе, если использовать в работе нормальные инструменты, вместо скриптовых поделок по типу пайтона или что там ещё в почёте у разнорабочих от мира IT. Докер - это апофеоз глупости, т.к. идея решения, позволяющего упростить клепание скриптовых поделок, не может прийти в голову здравому человеку. Для избавления от пользования докером не нужен новый ЯП, нужно скорейшее повышение квалификации программиста. Скриптовые поделки под виртуализацией - доразвивались, как говорится. Вместо одного процессорного такта - 1000, вместо килобайта - десяток мегабайт. Зато прогресс, чё...
ответить
Я ж говорю
... пулемёт тут нужен, а не язык.
ответить
☞ From Nick (unverified) Mon Mar 30 09:37:00 2020 UTC
Императивное программирование
Здравствуйте!
Во второй части первого тома встретилось понятие «императивное программирование». Т.к. чтение книги во времени разбилось на несколько частей, возможно я упустил объяснение этого термина ранее. Если не затруднит, покажите на пальцах, что это за фрукт, что еще бывает и чем отличаются.
Спасибо.
ответить
Тому, что ещё
Тому, что ещё бывает, посвящён только что вышедший четвёртый том — собственно говоря, целиком. Но это вам, скорее всего, рано.
Можете считать приблизительно, что "императивное программирование" -- это когда программа строится как инструкция, в какой последовательности выполнять некие действия. Можете принять во внимание, что бывает и по-другому; а можете вообще до поры до времени это проигнорировать.
ответить
Императивное программирование
что еще бывает и чем отличаются
Если совсем упрощённо, то императивное программирование - это реализация решения задачи в "терминах компьютера". Все остальные парадигмы предполагают реализацию "в терминах более понятных человеку". К примеру, sql-запросы составляются "в терминах баз данных", что и откуда выбрать, по каким критериям и т.д. При этом, в общем случае, пользователь не задумывается каким образом всё это происходит на уровне машинных команд. Т.е. пользователь просто описывает то, что хочет получить в итоге, а СУБД исполняет его указание.
Другой пример: работа с текстом, к примеру, с помощью Perl'a. Пользователь с помощью синтаксиса регулярных выражений составляет указание интерпретатору найти какие-то сочетания в текстовом файле (к примеру), интерпретатор исполняет это указание, при этом пользователя совершенно не волнует что там происходит на уровне машинных команд.
ответить
Вот ни фига, между прочим
Это всё действительно существует, но называется совершенно иначе: "низкоуровневое программирование". Императивное программирование бывает и высокоуровневым тоже, достаточно вспомнить тот же Tcl (да и вообще любые командно-скриптовые языки) или, например, доисторический Бейсик с нумерованными строками.
ответить
☞ From Ilia (unverified) Tue Mar 24 21:00:00 2020 UTC
Тотальная безграмотность
Доброго времени суток, Андрей Викторович!
На днях мне одному приятелю пришлось объяснить разницу между языком С и С++. И в ответ я услышал: "не нужно смешивать возможности языка и сам язык, они почти одинаковы. Лучше сейчас вообще использовать Python" . Честно говоря, у меня волосы дыбом встали. И это говорит человек, который уже почти три года проработал "программистом". Как думаете, преодолеем ли мы этот этап повальной безграмотности хоть когда-нибудь?
И почему большинство так повально стремятся изучать сначала Python, Java, итд? Я могу ошибаться, но как по мне это напоминает, такую картину: давай сначала обучимся водить АКПП. А если на механике тебе покажется сложно, ничего страшного, на автомате умеешь и хватит.
ответить
Никто их не
Никто их не стремится "изучить", вы путаете причины и следствия. Неофит, не знающий ничего, не знает, естественно, и того, с чего следует начать. А вот дальше ему встретится целая толпа "доброжелателей", которые посоветуют изучать какую-нибудь хрень. И да, таких будет очень много. Просто потому что объяснить питончик какой-нибудь так, чтобы неофит смог что-то на нём такое сделать — ума много не надо.
Преодолеем ли мы это когда-нибудь? Вряд ли. Но тем ценнее будут те, кто понимает, что к чему.
ответить
Пользователи Python
На днях мне одному приятелю пришлось объяснить разницу между языком С и С++. И в ответ я услышал: "не нужно смешивать возможности языка и сам язык, они почти одинаковы. Лучше сейчас вообще использовать Python" . Честно говоря, у меня волосы дыбом встали. И это говорит человек, который уже почти три года проработал "программистом".
Тот, кто "разрабатывает ПО" на Python или любом другом скриптовом языке, не может называться программистом по определению. Такого деятеля нужно называть "пользователь интерпретатора", который в силу своей необразованности ваяет поделия на скриптовых языках под видом ПО. Типичный представитель "макако-ориентированного программирования". Но особенная дичь начинается, когда подобные адепты начинают ваять на "современном С++", начиная тянуть "возможности" из С++ 11 и последующих стандартов. Получаемая на выходе высокоуровневая лапша выдаётся за "модные паттерны". На уровне машинных команд там, естественно, дичайший треш. Зато "я пишу на современном С++, который безопасен, словно жаба, везде пихаю STL-контейнеры, мозг не включаю".
ответить
Ого
И ведь это даже не я сказал :-)
ответить
Так это же nelson.
Так это же nelson. Достаточно увидеть этот ник, чтобы понять, что в последующем комментарии концентрация "[веб/питоно]макак", "современного C++", его "стандартов", "хухеля" и всякого такого превысит летальную дозу.
ответить
Вот прям как
Вот прям как будто это что-то плохое. Остаётся только мечтать, чтобы доза и впрямь была летальной (вот прям так -- зашёл очередной вебкодер-жабаскриптер на сайт, прочитал и помер), но увы, это так не работает.
ответить
☞ From Anonymous (unverified) Sat Mar 21 23:42:00 2020 UTC
Андрей
Андрей Викторович, учитывая последние события, не задержится ли выпуск последнего тома хотя бы в электронном виде?
ответить
Я не знаю,
Я не знаю, задержится ли выпуск, в нынешние времена вообще трудно что-то прогнозировать. Думаю, что в ближайшие несколько дней мы это поймём.
К сожалению, ни о каком "хотя бы в электронном виде" речи идти не может, эти события жёстко связаны: электронная версия появится на сайте через 1-2 дня после выхода книги в бумаге.
ответить
☞ From Anonymous (unverified) Fri Mar 6 18:07:00 2020 UTC
The V Programming Language
Андрей Викторович, позвольте узнать ваше мнение о [link removed] вот этом художестве. Без сборки мусора, с претензией на bare metal. Есть, правда, ложка дегтя - UTF-8.
ответить
Не знаю как
Не знаю как насчёт самого языка, но их сайт повесил мой браузер, если не ошибаюсь, на второй просматривавшейся странице. Смотреть дальше желания не испытываю.
ответить
Язык в
Язык в "глубокой альфе", поэтому говорить о нем всерьез пока нет особого смысла. Конечно, есть интересные вещи, разработчиков, очевидно, вдохновляли Rust, Go и всякое прочее модное. Язык довольно простой и компактный, я, правда, во всей документации и примерах так и не нашел аналога сишной функции scanf. Настораживает стремление разработчиков усидеть на всех стульях сразу - и компилируемый, и тут же скриптовать на нем можно, и в вебе чего-то строчить, и библиотека для UI своя есть. Но самая, пожалуй, странная штука - как раз работа с памятью. Она непрозрачна, сборщика мусора нет, но при этом и у пользователя нет контроля как такового. На сайте утверждают, что, если ваша программа скомпилировалась, в ней гарантированно нет утечек памяти. Я честно попробовал кусок кода из документации, где в динамический массив добавляют два элемента и выводят на экран. Valgrind мне сказал, что все это добро таки утекло, хотя скомпилировалось без вопросов...
С bare metal тоже все сложно. Как дела с кросс-компиляцией? Как ему скормить скрипт компоновщика? Прикола ради попробовал собрать программу-пустышку с этим самым ключом -freestanding, так он выдал кучу ошибок, среди которых проскакивали строчки на x86-ассемблере, хотя все происходило на ARM-машине... Короче говоря, пока больше вопросов.
ответить
Если работа с
Если работа с памятью непрозрачна, то это не взлетит.
Всё-таки не могут люди понять, что воюют даже не то чтобы с мельницами, а просто не с той мельницей. Если говорить о проблемах чистого Си, то вот это вот "ну как же, там же можно случайно не в ту память залезть, и тогда
все умрутвсё упадёт" будет последним, про что я вспомню.ответить
Язык реализации
ну это же вообще несерьёзно:
What language is V written in?
V. The compiler can compile itself. The original version was written in Go.
ответить
☞ From Антон (unverified) Wed Mar 4 06:41:00 2020 UTC
Артефакт
Доброго дня, Андрей Викторович!
Нашёл занимательный артефакт 1996 года выпуска: Столяров А., Столярова Е. — «Вы купили компьютер…». Разъедает любопытство — не приходятся ли вам случайно авторы родственниками?
https://starina.ru/item/123440053_%D0%A1%D1%82%D0%BE%D0%BB%D1%8F%D1%80%D0%BE%D0%B2_%D0%90_%D0%A1%D1%82%D0%BE%D0%BB%D1%8F%D1%80%D0%BE%D0%B2%D0%B0_%D0%95_%D0%92%D1%8B_%D0%BA%D1%83%D0%BF%D0%B8%D0%BB%D0%B8_%D0%BA%D0%BE%D0%BC%D0%BF%D1%8C%D1%8E%D1%82%D0%B5%D1%80_1996_%D0%B3%D0%BE%D0%B4
ответить
Была такая
Была такая книжка, да. Мне попадалась. Нет, родственников таких у меня нет, но это и не удивительно — моя фамилия не относится к редким.
ответить
☞ From Oilver (unverified) Mon Mar 2 13:58:00 2020 UTC
Ошибка
Добрый день, Андрей Викторович! Я набрал в текстовом редакторе первую программу на ассемблере из книги, но при запуске команды "nasm -f elf hello5.asm" у меня выдает ошибку
hello5.asm:1: fatal: unable to open include file `stud_io.inc'
В чем может быть дело?
Спасибо
ответить
Очевидно
Ошибка состоит в отсутствии файла stud_io.inc, спасибо Капитану Очевидность.
Файл берёте здесь: http://www.stolyarov.info/books/extra/stud_io_inc
Его нужно будет переименовать в
stud_io.inc.Про это говорится на странице, посвящённой второму тому.
ответить
☞ From ugly_duckling (unverified) Mon Mar 2 06:37:00 2020 UTC
Программист в 30 лет
Здравствуйте, Андрей! Возможно ли стать программистом, если начинать заниматься программированием, ну скажим с нуля в 30 лет? Сам я занимаюсь около года, и мне нравится программировать.
ответить
Всё возможно
Думаю, будет трудно, но принципиально невозможного здесь ничего нет. Я лично знаю людей, начинавших ещё позже и ставших профессионалами.
ответить
☞ From Anonymous (unverified) Tue Feb 25 23:42:00 2020 UTC
Андрей
Андрей Викторович, доброго здравия! Можете посоветовать какие-нибудь книги из мира математики, которые Вам понравились? Очень понравилось Ваше повествование в первом томе в разделе про математику. Это то, чего мне так не хватало. Как будто меня взяли за руку и повели в страшный мир, а он оказался вовсе не страшный, а очень даже красивый.
ответить
Буду банален :-)
Я.И.Перельман "Живая математика" вот тут, например: https://math.ru/lib/book/djvu/perelman/alive_math.djvu
Другие книги того же автора тоже весьма способствуют.
ответить
☞ From Dmitriy (unverified) Thu Feb 13 07:26:00 2020 UTC
А могут
А могут некоторые примеры не работать в Windows?
Произошёл затык в программе char2num.
После ввода первого числа выдаёт такое:
`` in pos: 4'и снова предлагает ввести первое число.
И в примере из этого коммента http://stolyarov.info/guestbook#comment-2167 тоже выходит такое:
123]1][2][3][
В чём может быть дело?
ответить
Конечно, могут
Больше того, вообще удивительно, что под виндой у вас заработало хоть что-то.
Если вы не готовы к отказу от Windows, найдите себе более подходящие учебники. От моих книжек вам никакого проку не будет.
ответить
Другие примеры
Другие примеры работали, так как я переводил их в С.
Отказаться от вашей книги не вариант, поэтому поставил Линукс (пока на виртуалку).
Консоль+vim+fpc - и всё заработало.
Надо сразу делать, что говорит учитель. Урок усвоен. Спасибо.
ответить
Что ж вы своё
Что ж вы своё время и силы до такой степени не цените?
Если для вас Linux так и останется "учебным пособием на виртуалке", программистом вы не станете — во всяком случае, если будете при этом продолжать пытаться это сделать по моим книжкам. Причины этого подробно расписаны во втором ("методическом") предисловии к первому тому.
Вся эта штука сработает лишь в том случае, если в Linux'е вы будете жить, делать всё, что обычно делается с помощью компьютера, причём основным средством работы для вас будет командная строка. Даже если вы перейдёте на Linux, но будете продолжать использовать иконочные файловые менеджеры, толку не будет. А если останетесь под форточками — тем более. Не буду утверждать, что, сидя под форточками, вообще невозможно научиться программировать, но что это невозможно сделать по моим книжкам — это я вам гарантирую.
ответить
В целом всё так,
В целом всё так, но справедливости ради, несмотря на всё вышесказанное, вопрос о том, почему это всё не работает под виндой, всё же имеет право на существование, и знать на него ответ может быть полезно. Особенно учитывая, что у многих процесс перехода на linux идёт постепенно, а кто-то и вовсе держит на компе две системы, и при перетаскивании текстовых файлов из одной системы в другую данная проблема регулярно всплывает. В любом случае при постепенном переходе на linux может возникнуть желание запустить какие-то программи на винде, и сложности с их запуском могут создать ощущение, что там все полученные знания о программировании неприменимы, что, разумеется, неверно.
Проблема здесь в том, что в windows, в отличие от linux, конец строки обозначается двумя символами, а не одним. Если в linux это символ с кодом 10 (0xOA --- перевод строки), то в windows перед ним добавляется символ с кодом 13 (0x0D ---возврат каретки). Поскольку обе упомянутые программы в явном виде ожидают увидеть там символ с кодом 10, нет ничего удивительного в том, что под windows они работают, цитируя примечание на странице 282 второго тома, "как-то не так".
В целом проблема довольно известная и для борьбы с ней есть даже специальные программы dos2unix и unix2dos для преобразования концов строк в текстовых файлах при их переносе между различными системами. Кстати, я неоднократно натыкался на вопросы знакомых студентов мехмата МГУ, почему у них дома программа работала, а в компьютерном классе ---нет. А проблема была в том, что тестовый файл они, естественно, принесли на флэшке из windows, где концы строк другие, а графический текстовый редактор (в отличие от консольного mcedit) даже не показывает эти лишние ^M в конце каждой строки. Непонимание данной проблемы создаёт у автора программы "ощущение магии", в то время как на самом деле здесь всё очень просто.
ответить
Это для нас с
Это для нас с вами всё просто, а для людей, только начинающих что-то такое делать, даже само понятие «символ перевода строки» может оказаться нетривиальным для постижения. И трудностей на этом этапе хватает без того, чтобы ещё и бороться с разностью представлений. Ну а главное тут то, что переход на *nix является обязательной частью моего подхода, и с этой точки зрения рассказывать человеку, как именно ему и дальше сидеть под любимыми форточками — я бы сказал, контр-целесообразно.
ответить
☞ From Lambert (unverified) Tue Feb 11 08:11:00 2020 UTC
Прошу совета
Добрый день
Андрей Викторович, сейчас нахожусь на ассемблерной части вашей книги. Далее в соответствии с содержанием: Си и С++.
Проблема в том, что у нас в вузе начинают сразу с плюсов. С одной стороны не хочу бежать впереди паровоза, а с другой - весной нужно сдавать зачёт по С++.
Посоветуйте, пожалуйста, как поступить?
ответить
Честно говоря, понятия не имею
В вашей ситуации правильного решения просто нет. Посоветовать могу одно — берегите мозг, иначе его вам там в этом ВУЗе вынесут.
ответить
Прошу прощения,
Прошу прощения, что вклиниваюсь в дискуссию, но многое зависит и от того, что ваш преподаватель понимает под C++. Если векторы-лямбды-auto-и-прочее, то да, берегите мозги и читайте правильные книжки. Если iostream вместо stdio.h, шаманское заклинание using namespace std перед main и закорючки вместо printf, то тут и бояться нечего, просто перетерпите.
ответить
Такие вещи (C++
Такие вещи (C++ первым языком) обычно бывают из-за одной маленькой проблемы: начинающим невозможно рассказать указатели так, чтобы в группе больше одного-двух человек поняли, что происходит. Увы, C++ в сочетании с его так называемой "стандартной библиотекой" допускает макакокодинг, т.е. использование инструментов без понимания происходящего, а применения операции взятия адреса на первых порах можно избежать, таки да, за счёт iostream -- но vector вместо обычных массивов при таком раскладе практически неизбежен. А дальше -- как в той серии мемасиков про ёжика в тумане: "И что? И всё. И п-ц".
ответить
Добрый деньВсе
Добрый день
Все оказалось не так стрёмно. Вместо плюсов нам стали преподавать чистый Си. После Pascal и Asm в принципе норм.
ответить
Если вы на
Если вы на Паскале успели дойти до указателей и их освоить -- то да, с чистым Си у вас уже проблем быть не должно.
ответить
Осваивал
Осваивал указатели на Паскале. Было непросто, но разобрался. Если честно, то после раздела с указателями я начал понимать или, говоря точнее, в общем представлять, что такое "боевое" программирование
ответить
Уууу
Боюсь, реальность вас несколько удивит. Между упражнениями с указателями из первого тома (да и вообще любыми упражнениями из любой книжки по программированию) и реальным "боевым" программированием разница примерно как между трёхколёсным детским велосипедом и 250-тонным карьерным самосвалом "Белаз".
Иное дело, что указатели -- один из самых заметных "барьеров вхождения" при освоении азов. Так что если смогли преодолеть -- дальше уже будет проще. Просто будьте готовы к тому, что в реальности перед вами встанут такие проблемы, которые просто невозможно себе представить, пока вы ковыряетесь с учебными програмками на две-три страницы.
ответить
Уточнение
Действительно, на счёт "боевого" программирования я загнул. Правильнее будет сказать, что в процессе изучения указателей пришло понимание что можно писать и нечто более серьезное, чем задачи из учебников или практикумов.
ответить
если позволите,
если позволите, вмешаюсь, сказав, что нахожусь в подобной ситуации и меня спасают индивидуальные договоренности с преподавателями. Часто удается договориться не писать на языке формальной программы обучения. Вот, только, не знаю, почему: то ли из-за разумности аргументов студента, то ли из-за того, что преподавателям все равно, на чем я там напишу лабы.
ответить
Проблема в том,
Проблема в том, что у нас в вузе начинают сразу с плюсов
У вас там часом не для хухля программистов готовят? Тамошние "гении" вон возможности С++ 17 используют в аллокаторах памяти - http://www.opennet.ru/opennews/art.shtml?num=52364#13
Такая вот "работа мечты", как любят вещать маркетолухи: stl-макакинг, бессмысленный и беспощадный.
ответить
☞ From Anonymous (unverified) Mon Jan 20 14:15:00 2020 UTC
without-systemd.org
Добрый день, Андрей!
Как это ни печально, сайт http://without-systemd.org/ уже пару месяцев выдаёт Database error. Жаль, там была неплохая вики.
Так я к чему: может быть имеет смысл заменить (или дополнить) эту ссылку на вашей заглавной странице на что-нибудь работающее. Поверхностным гуглением нашёл сайт https://nosystemd.org/ По-моему, подходящий кандидат. Там есть подборка ссылок на критику systemd и достаточно полноценный список дистрибутивов без systemd.
ответить
Спасибо
Добавил nosystemd.org в начало списка, очень, кстати, понравился их слоган. without-systemd пока не убираю, вдруг оживёт.
ответить
☞ From Oliver (unverified) Sat Jan 4 13:43:00 2020 UTC
Бинарное дерево поиска
Добрый день, Андрей Викторович! У меня следующий вопрос (возможно, глупый, но все же...): часто ли на практике может пригодиться балансировка бинарного дерева поиска? Каков Ваш личный опыт с этим?
Спасибо!
ответить
Лично мне не
Лично мне не потребовалось ни разу.
Это, впрочем, не значит, что можно про балансировку ничего не знать. По крайней мере, стоит иметь представление о красно-чёрных деревьях, чтобы, когда/если соответствующая задача всё-таки попадётся, во-первых, понять, что тут как раз их и нужно применять, и, во-вторых, этого применения не бояться.
ответить
☞ From Anonymous (unverified) Sat Dec 28 22:55:00 2019 UTC
Итоги
Итоги голосования Debian
http://www.opennet.ru/opennews/art.shtml?num=52104
"Победил второй пункт ("B") в списке - предпочитаемым остаётся systemd, но оставляется возможность сопровождения альтернативных систем инициализации."
ответить
Кавалерийский
Кавалерийский наскок стукнутых ньюфагов кончился ничем. Это хорошо.
ответить
Скорее всего,
Скорее всего, это потянет за собой один из не очень благоприятных вариантов: Поддержка s-d будет обязательной, а вот наличие альтернативных init-скриптов, перестанет быть обязательным.
И как итог, их отсутствие перестанет отмечаться как ошибка в программном пакете.
Вероятное апоследствие: Полная привязка к s-d, всех программных пакетов со временем.
ответить
Риск
Риск наступления всех этих последствий возник намного раньше — ровно тогда, когда в дебиане было принято решение в принципе допустить туда systemd, то есть около пяти лет назад. Сейчас ньюфаги попытались закрепить успех, отбросив вообще любую поддержку других init'ов, но, как видим, получили щелчок по носу.
Что будет дальше — в любом случае никто не знает.
ответить
На случай
На случай самого нелицеприятного варианта развития событий.
(постепенная полная привязка ПО к s-d)
http://www.trek.eu.org/devel/sysd2v/
Трансформация сервисов s-d в init-скрипты.
P.S.
По возможности s-d лучше не касаться и выбирать альтернативные init'ы изначально.
Конвертация сервисов воспринимается как "инструмент последнего выбора"
ответить
Собственно
Собственно говоря, лично я с дебиана давно переполз на Devuan, мне сейчас только интересно, насколько дебиановские новшества могут на него негативно повлиять.
ответить
Ну, devuan всё-таки
Ну, devuan всё-таки скорее форк имеющегося дистрибутива, в первую очередь развиваться будет скорее основная ветка.
А вот Gentoo вроде бы наоборот придерживается прямо противоположной политики. Там _поддерживается_ systemd (хотя я не проверял, насколько этот вариант работает), но по умолчанию предлагают ставить openrc. Теоретически, наверное, можно и любую другую систему инициализации прикрутить.
P.S. Капча реально зверская!
ответить
Да какой там
Да какой там "щелчок по носу". Из семи предложений выбрано второе по pro-systemd'шности. Первое было "не поддерживаем ничего кроме systemd", а выбранное второе "ну вы там пилите свои инит-скрипты, если хотите, но systemd-юниты чтобы были обязательно". Это не щелчок по носу ньюфагам, а подачка противникам гегемонии systemd, чтобы слишком громко не возмущались.
Ну да и чёрт с ним. Мне дебиан и его деривативы не интересны уже лет 15 как. С тех пор, как я осознал, насколько жирна там дебиано-специфичная прослойка между пользователем и юниксом.
ответить
А чем
А чем пользуетесь?
ответить
Отвечу
Отвечу развёрнуто, пожалуй.
Очень уважаю принцип KISS. Ну и пользуюсь, соответственно, теми системами, которые этот принцип стараются поддерживать.
После дебиана был ArchLinux (в те времена он принципу KISS ещё пытался соответствовать, да и systemd ещё не изобрели), потом CRUX. А несколько лет назад, глядя на тенденции развития не только линукса в целом, но и, в частности, его ядра, ушёл вообще на OpenBSD. Доволен, поскольку на CRUX'е приходилось порядочно пилить, чтобы немного приблизиться к моему представлению об идеале, а OpenBSD к этому идеалу гораздо ближе прямо из коробки.
Был период, когда по работе пришлось пользоваться убунтой. Впечатления очень напомнили жизнь в винде (образца XP и раньше, после XP я виндой практически не пользовался, и сказать ничего не могу): постоянная борьба с системой в попытках заставить её сделать то, что мне надо, и так, как мне надо. И в винде, и в убунте постоянно испытывал ощущение, что компьютер принадлежит не мне, а операционной системе.
Если бы сейчас пришлось пользоваться линуксом, то выбирал бы из CRUX, Void или Slackware. Возможно Alpine, если она юзабельна в качестве десктопа, надо проверять.
PS. А первым линуксом, до дебиана, у меня была Caldera OpenLinux купленная в книжном магазине в комплекте с книжкой. ;)
ответить
Void
выбирал бы из CRUX, Void или Slackware
Так. Вынужден изменить своё мнение относительно Void'а. Выяснились некоторые обстоятельства, в связи с которыми рекомендовать его я больше не могу.
Основная причина в том, что методы, которыми его разработчики пользуются для обновления пакетов, не годятся для думающего самостоятельного пользователя.
Подробности тут и тут.
Если коротко, то при обновлении, вместо очередной версии пакета, молча, без каких-либо уведомлений, под тем же именем, ставится пустая заглушка, которая тянет зависимостью уже совершенно другой пакет. Такое поведение было замечено как минимум пару раз. На мой взгляд, это неприемлемо.
Дополнительная причина в том, что, вообще говоря, разработчики Void не имеют ничего против systemd. Void перешёл с systemd (да, именно так, изначально системой инициализации в Void была systemd) на runit всего лишь из-за несовместимости systemd с musl. Так образом, я не вижу ни малейших гарантий, что в будущем они не вернутся на systemd.
А жаль, дистрибутив был неплохой, как минимум два несомненных плюса в нём есть: поддержка musl и внедрение LibreSSL вместо OpenSSL.
Кстати, Андрей, сайт по одной из ссылок, приведённых выше, содержит весьма подробный список дистрибутивов без systemd: https://sysdfree.wordpress.com/2019/10/12/135/ Может быть имеет смысл добавить его на заглавную страницу вашего сайта, а то without-systemd.org не оживает, а больше такого подробного списка я нигде не видел.
ответить
☞ From Алексей (unverified) Fri Dec 27 14:21:00 2019 UTC
IT-вуз
Добрый день, Андрей Викторович. Хотел поделиться данной новостью, которая уже совсем не новая. https://sputnik.by/education/20191020/1043045493/Zachem-Belarusi-IT-vuz-i-kakim-on-mozhet-byt.html
Что думаете? Особенно порадовали IT-ПТУ.
P.S. Если комментарий премодерацию не пройдёт, то надеюсь, что вы тоже посмеётесь над этим цирком.
ответить
Я не в курсе
Я не в курсе ситуации в Белоруссии. В России бы подобная инициатива ничем, окромя очередного могучего распила, не кончилась.
Но, кстати, про IT-ПТУ я полностью согласен с текстом новости: чтобы просто топтать кнопки или тем более админить, высшее образование не нужно от слова "совсем". И, кстати, есть шанс, что при наличии адекватных средних специальных учебных заведений, где учат именно что админить и кодить, всякая корпоративная (копроактивная) шушера, рыщущая в поисках источника кадров, пойдёт туда, вот в эти ПТУ, техникумы и прочее, и перестанет, наконец, портить воздух в университетах.
ответить
☞ From Anonymous (unverified) Sun Dec 8 10:41:00 2019 UTC
Голосование
Debian проводит голосование о необходимости поддержки альтернативных систем инициализации (а нужно ли что-то кроме s-d)
https://www.debian.org/vote/2019/vote_002
Организация, курирующая разработку Devuan, написала открытое письмо, в котором указала, что Devuan умрет, если по результатам голосования в Debian, альтернативные системы будут заброшены.
https://www.dyne.org/devuan-cannot-exist-without-the-help-of-debian/
ответить
Debian проводит
Debian проводит голосование
Вот не понимают люди, что нельзя такие вещи решать голосованиями; в голосованиях бывают те, кто за, и те, кто против, и когда большинство перевешивает, получается, что интересами меньшинства просто пренебрегли (замечу, именно поэтому я не считаю себя демократом). Между прочим, если пройдёт "proposal F", можно будет констатировать, что Дебиан нынче находится под руководством комитета, т.е., читай — превратился в токсичную и вредоносную сущность.
Организация, курирующая разработку Devuan, написала
В упор не вижу никакой "организации", вижу частное лицо Denis Roio, письмо написано от первого лица. Вообще говоря, напоминает паникёрство.
Так или иначе, на Дебиане свет клином не сошёлся. Ну, уйдём на Слаку или ещё куда. Хотя мне, в принципе, видится ещё один вариант развития ситуации -- сейчас в Дебиане происходит как раз то, что нам не нравится, после чего большая часть проекта заявляет "вы достали" и уходит в Devuan. Маловероятно, конечно, но не так чтоб совсем невозможно.
ответить
Подобное
Подобное "протаскивание" s-d путем "демократического голосования" с получением "нужного" результата и привело к рождению Devuan'а
Поэтому, вариант с миграцией разработчиков в Devuan вполне себе возможнен.
ответить
В
В дополнение
https://diziet.dreamwidth.org/3999.html
"In the short term, Debian contributors and users who don't like systemd may switch to Devuan instead (or simply shrug their shoulders and reduce their engagement). In the medium to longer term, Debian's narrowing of focus will make it less attractive for its current variety of interesting use cases. Debian's unwillingness to let people within Debian forge their own path will make it less fun."
"Разработчикам и пользователям, которым не нравится SystemD рекомендуется переключиться на Devuan
Дальнейшая фокусировка Debian на SystemD, сделает его менее превлекательным для разработки"
ответить
А что делать новичкам?
> Так или иначе, на Дебиане свет клином не сошёлся. Ну, уйдём на Слаку или ещё куда.
А что остаётся новичкам? Им явно не разобраться без посторонней помощи со Слакой и подобными, ведь начинать с них сложно. А если начнут с Убунты или Дебиана, то велик шанс, что на них и останутся, то есть systemd для них станет "стандартом".
ответить
Ну это
Ну это проблема, да. Но вообще мейнстрим сейчас по-прежнему винда, и да, многие с неё вообще слезть не способны. Те, кто с винды слезли — это такие люди, которые умеют слезать. Просто, видимо, теперь это слезание будет проходить в два этапа :-)
ответить
С s-d слезть
С s-d слезть вообще не проблема: он сам подталкивает отказаться от него.
Например, когда не дает перезапустить сервис или просто выключить компьютер.
И это мелочи, с которыми может столкнуться новичёк, не отягочающий себя администрированием.
Парадокс именно в этом: Новичек ленив: Он не захочет разбираться, почему не выключился компьютер с "дружелюбным linux'ом"
Он почитает и узнает о SysVinit.
P.S.
Я же прочёл. :-)
ответить
☞ From Вячеслав (unverified) Sat Dec 7 09:00:00 2019 UTC
Компьютерные игры
Андрей Викторович, добрый день.
Продолжаю изучать программирование, следуя вашему курсу.
Многое даётся с трудом, но желание писать игры помогает.
Сейчас подошёл к рубежу, где очень нуждаюсь в совете. Пожалуйста, подскажите, правильно ли начинающему программисту для создания игр пользоваться специальными средами их разработки (мне не нравится слово "движок")?
Из всех жанров пока хочется что-то, вроде этого:
- [url removed]
Ben Croshaw (программист) использовал [url removed]
Эта среда запускается и под Linux. Подобные ей подпограммы разработаны для среды Unity.
Возможность кажется привлекательной, но не хочется попасть в западню привлекательности и остановиться в развитии.
Как лучше программировать игры: в среде или без неё?
Большое вам спасибо за совет.
С уважением, Вячеслав.
ответить
Для начала
Для начала определитесь для себя, какова ваша конечная цель: научиться программировать (а игры при этом лишь средство) или же научиться делать игры (а программирование при этом лишь средство).
Если второе — то можете использовать что угодно и для чего угодно, только зачем об этом спрашивать у меня? Я никого не учу GameDev'у и никогда не пытался, сам его никогда не трогал, меня вообще эта область не интересует.
Если первое — то та хреновина, на которую вы постили ссылку, никакого отношения к программированию не имеет. Вообще. Те мелкие скриптики, которые в этой "среде" пишутся на непонятном языке (вроде C#, а вроде и нет) — это не программы, это именно что скриптики, а стряпанье игр в подобных "средах" — ну, с таким же успехом можно программистами считать, например, продвинутых пользователей Excel, там ведь тоже бывают макросы.
для среды Unity
Если под любую из Unix-систем разрабатывается программа, предполагающая графический интерфейс, то она не имеет права быть завязана на конкретный оконник. Все эти "для Unity", "для KDE", "для Gnome" — результат деятельности безграмотных моральных уродов, не понимающих действительной роли оконного менеджера в экосистеме X Window.
ответить
Unity
не имеет права быть завязана на конкретный оконник. Все эти "для Unity", "для KDE", "для Gnome" — результат деятельности безграмотных моральных уродов, не понимающих действительной роли оконного менеджера в экосистеме X Window.
Понимаю и целиком поддерживаю вашу, Андрей, горячую ненависть к разного рода desktop environments.
Однако, исходя из контекста, есть подозрение, что Вячеслав имел в виду несколько другую Unity.
ответить
Возможно :-)
Я же говорю, я в GameDev никогда вникать не пытался. В общем, это ещё хуже, проприетарщина как она есть.
ответить
☞ From Игорь (unverified) Thu Nov 28 18:31:00 2019 UTC
Про вас тут общаются
Андрей Викторович, здравствуйте!
Тут почитывая новости на opennet'е о релизе системы сборки cmake и последующем листании комментариев увидел что в обсуждении как-то внезапно возникли вы :)
Вот ссылка на комментарий, но всю ветку вполне могут и потереть
http://www.opennet.ru/openforum/vsluhforumID3/119109.html#11
Если потрут, и вы это не прочитаете, то я возьму на себя смелость скопипастить основные моменты. Не для "стукачества", а по причинам а) раз уж про вас и ваши книги обсуждение, вы имеете право как минимум знать. б) Обсуждение ведётся по большей части технически грамотными специалистами, и отзывы от грамотной публики могут быть полезными ну или как минимум интересными.
[цитирование поскипано — объёмчик-с]
ответить
Таки я шо, сто баксов?
С одной стороны, да пусть общаются на здоровье. Я же не сто баксов, чтобы всем нравиться.
С другой стороны, там про меня исключительно лажа. И фанатом Столлмана я никогда, собственно говоря, не был, а сейчас даже перестал, пожалуй, быть его сторонником. Не, ну я всё понимаю, но чтобы в погоне за этой "свободой", которая, собственно, им самим и придумана и на самом деле свободой не является — не просто забыть исходную цель (ликвидацию копирайта и прочей интеллектуальной собственности), а наехать на пиратские партии, что, мол, они требуют отмены копирайта, а GPL основана на копирайте, как же мы без копирайта теперь будем свободу защищать... короче, клиническая картина ясна.
И книжки у меня свёрстаны вовсе не под A4, а под A5, и ни в одной из них нет строчек длиннее 65 символов, и про нормы эти я, разумеется, в курсе (см. книжку про оформление кода, стр. 28, абзац в середине).
Ну а уж с Шилдтом мои книжки сравнивать, гм... Если б они были "ничем не лучше", я бы их и не писал.
В общем, не тот уж критик пошёл, не тот. Вот раньше критики бывали, уууууу. А нынче — разве ж это критики.
ответить
☞ From Anonymous (unverified) Thu Nov 21 11:25:00 2019 UTC
Опасные вещества
> На всякий случай: я, как и большинство либертарианцев, также считаю, что гражданам должны быть доступны вообще любые вещества, которые способен изготовить человек
А как насчёт сверхтоксичных или высокорадиоактивных веществ?
Я бы не хотел, чтобы мои соседи устроили аналог инцидента в Гоянии.
В 1987 году деталь от медицинской установки выкинули на свалку. Владелец свалки её нашел и с ней начали развлекаться. Мелкие фрагменты источника брали в руки, натирали ими кожу, передавали другим людям в качестве подарков, и в результате началось распространение радиоактивного загрязнения. В течение более чем двух недель с порошкообразным хлоридом цезия-137 контактировали всё новые люди, и никто из них не знал о связанной с ним опасности.
ответить
Старо
Начну с конца — когда там что-то радиоактивное оказалось на свалке. Сдаётся мне, проблема тут не в том, что кто-то владел медицинской установкой или деталью от неё, а в том, что её выкинули на свалку. Что можно и что нельзя выкидывать на свалки, а также, говоря шире, проблема утилизации отходов — вообще отдельное происшествие и уж точно не для короткого комментария, но если кратко — вот, скажем, батарейками вроде бы все имеют право владеть, но выбрасывать их в обычный бытовой мусор в цивилизованных странах давно уже нельзя, и это правильно.
Теперь по поводу "сверхтоксичных" и "радиоактивных". В принципе, в словосочетании "способен изготовить человек" я имел в виду именно человека, т.е. индивида или группу таковых, а не всё человечество в целом, государство и т.п., т.е. я не призываю, например, к свободной продаже ядерного оружия (хотя свободная продажа огнестрела с моей точки зрения — просто аксиома, то есть пока оборот огнестрела ограничен, государство остаётся моим заведомым врагом). Изготовить радиоактивные вещества вообще вроде бы пока невозможно, их нужно добыть, а координация добычи полезных ископаемых, с моей точки зрения, как раз вполне себе одна из естественных функций государства. С химическим оружием тоже вроде бы всё не так чтоб совсем просто, то есть его невозможно изготовить, не прибегнув к помощи государства. Ну то есть, к счастью для человечества, вопрос запрещения изготовления оружия массового поражения частными лицами пока что не стоит.
Если когда-то этот вопрос встанет, то этот день в любом случае станет днём похорон человечества вне всякой зависимости от того, будут ли введены соответствующие запреты или нет. Если же говорить о философской теории, то да, я в любом случае останусь противником любых запретов частным лицам создавать что бы то ни было, а равно и владеть чем бы то ни было (естественно, коль скоро речь идёт о материальных предметах, изготовленных человеком), здесь не может быть никаких исключений — поскольку, во-первых, индивидуальная свобода есть ценность терминальная, а не инструментальная, и она важнее любых гуманитарных химер, в том числе "выживания человечества"; и, во-вторых, если что, человечеству выжить никакие запреты всё равно не помогут, поскольку любое ограничение индивидуальной свободы — оно не про выживание человечества, и не про что-то там ещё, оно про власть.
ответить
Вот про
Вот про сложность изготовление химического оружия индивидуалами коммент не очень понятен. Тот же хлор применялся в качестве такового и изготовить его может любой школьник из отбеливателя, доступного в свободной продаже.
Но хлор — это ерунда, а ведь есть и вещества, которые многократно опаснее и которые так же, при наличии знаний и некоторого оборудования, изготовить может каждый.
То что изготовить эти вещества можно — не такая уж и проблема. Обычно люди, которые способны сделать такие вещества, понимают, что эти вещества опасны и будут обращаться с ними соответственно, а скорее вообще не будут пытаться их получить, ибо ещё жить хотят.
А вот если такие вещества окажутся в свободной продаже и их сможет купить любой гопник в ближайшем супермаркете — вот это уже будет проблемой, ибо если он разобъёт контейнер в подъезде — вымрет весь подъезд. Но опять же, не апокалиптического уровня.
ответить
Ни хлор, ни
Ни хлор, ни другие отравляющие газы — это не оружие массового поражения. К счастью. Угробить двадцать человек, да даже двести — это плохо, но для человечества в целом не смертельно. Массовое поражение — это когда одной единицей оружия можно грохнуть, скажем, миллион народу.
А если условному гопнику не продадут химическое вещество, то он купит в ближайшем хозмаге канистру, на ближайшей заправке зальёт её обыкновенным бензином (1000 рублей за всю канистру), разольёт в подъезде и подожжёт. По масштабу получится ничуть не хуже.
ответить
☞ From Anonymous (unverified) Thu Nov 21 11:02:00 2019 UTC
Торговля электронными книгами
Есть один автор художественных книг (ну может не только один), который продаёт свои книги через свой собственный сайт в электронном виде, но хотя бы без DRM, то есть после оплаты качается обычный fb2/txt/pdf файл.
С одной стороны, эта деятельность сомнительна, с другой — а как вообще можно заработать написанием художественной литературы, если учесть, что бумажные книги в качестве носителя отмирают?
Ещё 20 лет назад были КПК, с которых можно было нормально читать, а уж сейчас их современные аналоги можно найти даже в карманах младших школьников.
Crowd funding как видим на примере вашей книги по программированию, работает, но подойдёт ли он для художественной литературы?
ответить
> который
> который продаёт свои книги через свой собственный сайт
буду краток: шоб он сдох, как и все копирасты
> С одной стороны, эта деятельность сомнительна
Она не "сомнительна" ни разу. Ну то есть у меня сомнений на этот счёт нет ни малейших.
> а как вообще можно заработать написанием художественной литературы
Никак. Художественная литература не должна быть работой. Впрочем, НЕхудожественная — тоже.
> Crowd funding как видим на примере вашей книги по программированию, работает
Не так чтобы очень. Ну то есть выстрелил мой проект со страшной силой, это да, но деньги, которые я на этом заработал, ни в какое сравнение не идут с затратами труда. Если бы моей целью был заработок, я бы эти полторы тысячи рабочих часов (если быть точным, на текущий момент 1482) и пять лет жизни потратил совсем иначе.
> но подойдёт ли он для художественной литературы?
Для некоторых писателей, возможно, подойдёт. Для тех, кто пишет ради денег — однозначно нет. И это очень хорошо, поскольку те, кто пишет ради денег, вообще не должны писать и отнимать время у аудитории, а аудиторию у тех авторов, которые её (аудиторию то есть) реально заслуживают.
ответить
☞ From Anonymous (unverified) Thu Nov 21 08:13:00 2019 UTC
Немного оффтопа
Андрей Викторович, расскажите, пожалуйста, как Вы в процессе чтения лекций демонстрируете студентам фрагменты кода? Доска-мел-тряпка-вот-это-вот-все, слайды? Все же код отличается от физических, химических или математических формул, здесь не проходит фокус с "я исправлю, а вы перепишите", порой надо что-то добавить в середину фрагмента и т.д.
ответить
>
> Доска-мел-тряпка-вот-это-вот-все
Именно.
> слайды?
Если я когда-нибудь до этого опущусь, пусть меня кто-нибудь пристрелит.
> Все же код отличается
Ни хрена он не отличается. А доска выступает синхронизатором скорости лектора с возможностями аудитории. Конспектировать лекцию, читаемую с использованием проектора и прочей электроники, в разы труднее, и слушатели тупо не проглотят столько информации, сколько на них можно вывалить с помощью слайдов.
Что я точно знаю -- так это что если мне на какой-то пример кода не хватает доски и/или скорости его написания, то этот пример для лекции не годится, ибо слишком громоздок.
ответить
Если я
Если я когда-нибудь до этого опущусь, пусть меня кто-нибудь пристрелит.
Спасибо, честно говоря, именно такой ответ я ожидал услышать :) Помню, сколько теплых чувств у меня вызывал один любитель "читать лекции", вываливая на слайды сканы разворотов своей книги формата ~A4.
ответить
Слайды
>> > слайды?
>>Если я когда-нибудь до этого опущусь, пусть меня кто-нибудь >>пристрелит.
Браво! Как почти-бывший студент, жму вам руку. Было бы ещё здорово, если бы вы могли обратить в свою веру всех остальных преподавателей МГУ. Намучился от этого безобразия порядочно. Мечтать не вредно :-)
ответить
А как Вам такой вариант?
А что насчёт проектора и написания кода "вживую"? У нас действует такая система, по-моему неплохо (примеры краткие, но образцовые). А на соседнем потоке как раз таки вываливают кучу слайдов. А ещё если на одном слайде находятся несколько способов решения задач, то хочется пристрелить лектора на месте. Я и сам на таких "лекциях" (а по-моему это так, для галочки) предпочитаю сесть подальше и порешать или почитать что-то самому.
ответить
А никак мне
А никак мне такой вариант. Кодинг — это не то, чему следует учить на лекции. Если же целью является именно кодинг, то не нужно читать лекцию.
ответить
Только сейчас осознал.
Что ж, после ваших слов осознал, что это именно кодинг. Однако появился вопрос. Задаю его не ради спора или какой-то издёвки, а по причине любопытства и непонимания. А какой должна быть идеальная лекция на темы, связанные с программированием?
ответить
Если бы на ваш
Если бы на ваш вопрос можно было дать хоть как-то сформулированный ответ, вписывающийся в жанр коммента на сайте, то, гм... настал бы рай.
ответить
Снизим планку
Ну тогда, чтобы это было лекция, а не кодинг. Просто я не представляю, как должна выглядеть лекция по программированию. Текущий формат мне подходит, скорее всего, потому, что я интересуюсь этим и въезжаю в тему. Однако одногруппники пытаются меня переубедить, аргументом является то, что я не видел и не слышал хороших лекций. Это так, ведь мне хватало собственного любопытства, книг и компьютера.
ответить
Ух, тяжело
Честно говоря, не представляю, как ответить на вопрос "какой должна быть лекция по программированию" в одном комменте. Но, возможно, у меня есть идея поинтереснее.
Собственно говоря, вопрос в том, что считать программированием. Если под программированием понимать такое ремесло, при котором человек (превратившийся в социальную или, если угодно, производственную функцию) пишет тексты программ и за это получает деньги, то по этому предмету лекций не должно быть вообще. Не может быть лекций по ремеслу. Ремеслу вообще невозможно научить в ВУЗе или каком-то другом учебном заведении, ремесло постигается только в мастерской.
Иной вопрос, что вокруг этого ремесла имеется ненулевое количество теории. Такой, которую вообще-то, если совсем честно, знать не обязательно, программировать можно и без этого — во всяком случае, можно писать программы и получать за это деньги. Насколько это будут хорошие программы, насколько они будут оптимально спроектированы — вопрос уже второй, да и знание теории тут не гарантирует ничего, как и незнание — тут могут быть как максимум корреляции.
Что это, с моей точки зрения, должна быть за теория — тут я как раз сказать могу легко. Во-первых, должна быть математика, и её должно быть много; но как должны выглядеть лекции по математике — это и без меня, думаю, понятно. Во-вторых, есть и чисто программистская теория, и я своё видение таковой, как говорят нынче, объективировал :-) — вон книжка есть, аж три тома.
ответить
Спасибо.
Спасибо, ответ я получил. =)
> вон книжка есть, аж три тома
2 тома уже прочитаны, впереди 3, а 4 жду с нетерпением.
ответить
☞ From Oliver (unverified) Wed Nov 20 09:11:00 2019 UTC
Линукс
Добрый день, Андрей Викторович! У меня такой вопрос: нужны ли программисту знания администрирования ОС Линукс? Спасибо!
ответить
Мне вот даже
Мне вот даже интересно, как вы собираетесь подчинить себе компьютер в роли программиста, если не умеете с ним обращаться в роли пользователя, пусть и продвинутого?
ответить
☞ From Oliver (unverified) Fri Nov 8 16:44:00 2019 UTC
Хеш-таблицы
Добрый вечер, Андрей Викторович! Я хотел спросить про хеш-таблцы: их на этапе использования языка Паскаль стоит изучать и стоит ли их изучать вообще, либо же лучше освоить работу с двоичным деревом поиска, и использовать его, когда число хранимых элементов среди которых надо проводить поиск - большое? Спасибо!
ответить
Общий принцип
Общий принцип работы хеш-таблиц прост до невозможности, эффект от них весьма серьёзный, так что нужно, по-видимому, понимать, что это такое и как оно (в общих чертах) работает. "Изучать" их не надо — изучите, когда попадётся соответствующая задача. Пока она не попалась, достаточно знать, что это за зверь.
ответить
☞ From Алексей (unverified) Wed Nov 6 18:57:00 2019 UTC
Возможно глупый вопрос
Добрый вечер. Хотелось бы задать пару, возможно, глупых вопросов. Начать хотелось бы с офф-топа, учусь на 1 курсе, на лекциях по программированию (а начали мы сразу с C++, ведь это современно!) часто всплывают вопросы компиляции всего, что мы пишем, а также организации кода в памяти. В общем, меня интересуют следующие вопросы:
1) часто упоминается undefined behavior и говорится о том, что с этим не стоит бороться и понимать, просто следует избегать;
2) при вопросах, связанных с памятью (хочу заметить, что 2 том вашего введения я читал, но кое-что следует просмотреть ещё раз) ответы совпадают с содержанием вашей книги, но просят в это не лезть, так как "всё это было так лет 20 назад, сейчас любой профессионал скажет, что всё намного сложнее". В общем, любые попытки узнать что-то новое заканчиваются провалом.
Ну, и последнее. Является ли это дезинформацией? И что делать, если я хочу в это лезть и хочу понимать?
Извиняюсь за некоторую расплывчатость вопросов. С нетерпением жду ответа, спасибо.
ответить
Что-то вам неудачный вариант попался
Undefined behavior (само понятие такового) — это порождение проклятых стандартизационных комитетов. Между прочим, согласно пресловутым стандартам, сложение двух целых чисел может вызвать UB — если числа знаковые и результат не поместится в разрядность. Как можно это воспринимать всерьёз, лично для меня вопрос открытый.
По поводу памяти — всё по-прежнему именно так, как было «лет двадцать назад», (ну вот разве что появилась секция .rodata, я её не рассматриваю в книге) и если интересно мнение профессионала — то я вроде бы таковым являюсь. Обычно фраза «на самом деле всё намного сложнее» часто выдаёт непонимание предмета преподавателем, а уж просьба куда-то не лезть — с моей точки зрения вообще для преподавателей категорическое табу. Если преподаватель не хочет что-то рассказывать (я и сам многое рассказывать не хочу), он по крайней мере должен отделываться от подобных вопросов фразами вроде «это можно посмотреть там и там, если очень хотите».
Ну а если хотите понимать — берите всякие источники и экспериментируйте с компьютером.
ответить
Верно сказано
И ведь в самом деле неудачный, местами даже вредный. Хотелось бы ещё отметить, что, изучая тот самый C++, из него берётся всё самое ненужное (iostream и iomanip), всё остальное идёт из C (тот же cmath, "C-строки" и т. д.). Поэтому смысла в этом цирке я не вижу. А у меня совсем не "программистская" специальность. На "программистских" во всю используют auto, лямбды и vector'ы. Я, конечно, обычный начинающий и любитель, но задаюсь вопросом: зачем изучать в таких условиях C++, и почему бы не взять что-то повыше.
ответить
На
На "программистских" во всю используют auto, лямбды и vector'ы.
Замечу, им повезло ещё меньше, чем вам. Из них там макак делают целенаправленно.
Ну, общий принцип тут простой: за использование C++ в качестве первого языка при обучении программированию надо убивать. Медленно и со вкусом.
ответить
☞ From Oliver (unverified) Fri Nov 1 05:58:00 2019 UTC
Дин массивы Паскаль
Добрый день, Андрей Викторович! Я решил освоить динамические массивы на примере Паскаля. Из той информации, которую я нашел, следует, что переменная дин массива на самом деле является указателем на динамически выделенную (под массив) область памяти. А освобождение выделенной под массив памяти происходит с помощью операциии arr := nil, где arr - имя переменной дин массива. В связи с этим у меня возник вопрос: а действительно ли эта операция освобождает память, или же на самом деле происходит то, что вместо того, чтоб освободить память, просто теряется к ней доступ? Спасибо!
ответить
Если вы не
Если вы не собираетесь писать на Паскале за деньги (а я очень надеюсь, что не собираетесь), то не трогайте динамические массивы вообще. Их реализация в Паскале тщательно скрывает их истинную суть и механику, лежащую под ними – и, в довершение, мешает освоению указателей, поскольку найти задачу, в которой нужны списки, а дин.массивы не годятся — намного труднее, чем найти такую задачу, в которой нужны динамические данные как таковые.
Я в книге не рассматриваю динамические массивы Паскаля, и этому, как видим, есть причина.
ответить
☞ From Anonymous (unverified) Fri Oct 18 11:38:00 2019 UTC
Список опечаток
Есть смысл публиковать на сайте список найденных опечаток?
Чтобы пользователям и вам не заморачиваться, если опечатка уже найдена.
ответить
Смысл, может, и
Смысл, может, и есть, времени нет.
ответить
☞ From Anonymous (unverified) Thu Oct 17 17:25:00 2019 UTC
Очепятка
Здравствуйте. Если не ошибаюсь, то на с. 253-254 вышла опечатка. Вызов происходит с числом 7583, а вот на выходе результат вызова при значении 5783.
ответить
Эту уже нашли,
Эту уже нашли, но всё равно спасибо :-)
ответить
☞ From Anonymous (unverified) Mon Sep 30 12:48:00 2019 UTC
Благодарнасть
Спасибо Вам, Андрей Викторович, за Ваш труд! Возможно, Вы меня спасли для программирования: в ВУЗе у меня был C#, что для меня (человека, не знакомого с программированием) казалось тяжело, и отпугивало меня от программирования. Взял Вашу книгу, и по карйней мере пока что программирование для меня - занятное время провождение: это меня интересует, мне интересно попробывать всякие варианты, поиграться в процессе обучения.
ответить
☞ From Anonymous (unverified) Sat Sep 7 07:03:00 2019 UTC
Ссылки vs указатели.
Добрый день! Почитываю книжку про С++. Так вот, никак не могу отделать от ощущения, что ссылки внутри устроены "внутри" также из указателей + модификаторов. Можете что-то посоветовать? Есть ощущения, что ссылки - это только визуальное улучшение + меньше текста писать.
PS я не программист. И даже не близок к этому. Но эти книги - единственные {В России}, которые внятно рассказывают мир IT.
ps. капча ужасна.
ответить
Каких ещё
Каких ещё "модификаторов"? Там тупо адрес хранится/передаётся, так же как и в указателях. И да, ссылки — это синтаксический сахар, не более того; но языки программирования вообще состоят из синтаксического сахара.
Мне вот другое интересно, если вы не программист, то за каким лешим вам сдался C++?
ответить
C++ незачем, но
C++ незачем, но вот ваша подача материала про ООП очень даже зачем (надеюсь).
ответить
Это зависит от
Это зависит от того, каков размер (например, тупо количество строк) самой большой из написанных вами практически применимых программ. Если меньше чем 2000 (ну, плюс-минус несколько сотен, как обычно в таких случаях), то ООП останется для вас пустым звуком, даже если ваши собственные ощущения говорят об ином.
ответить
☞ From Anonymous (unverified) Sat Jul 13 19:02:00 2019 UTC
Посимвольный ввод информации. Паскаль.
Очень непонятно как работает read c типом char в программе char2num.pas
ответить
Странный вопрос
Read работает точно так же, как и всегда: считывает из потока стандартного ввода (в просторечии -- с клавиатуры) значение заданного типа (того типа, переменная которого передана параметром) и считанное значение помещает в переменную. В данном случае переменная имеет тип char, поэтому считывается значение именно этого типа — то есть ровно один символ. Он же и помещается в переменную.
Мне довольно сложно понять, что конкретно вам оказалось непонятно. Могу посоветовать взять вот такую программу:
program CharInput; var c: char; begin while not eof do begin read(c); if c = #10 then writeln else write('[', c, ']') end end.и посмотреть, как она будет работать, ну там погонять её и так и эдак. Возможно, это вам поможет. Если нет — попробуйте всё-таки сформулировать, в чём состоит проблема.
ответить
Кажется, я понял, в чём могла быть проблема
Для читателя может быть не очевидно, что терминал отдаёт программе всю строку целиком, а не по одному символу. А в тексте об этом упоминается только через параграф.
ответить
Возможно, но...
К сожалению, всё сразу рассказать нельзя.
ответить
☞ From Sergei (unverified) Thu Jul 4 17:43:00 2019 UTC
Исполнение кода, сформированного динамически
В первом томе на страницах 190-191 утверждается, что невозможно сформировать машинный код в памяти, а затем его выполнить. Кроме того, это утверждается в этом комментарии. Насколько я понимаю, это не совсем верно, поскольку именно так работает Just-In-Time компиляция. Конечно, если защиту от исполнения данных таки включить, то JIT работать не будет, но, насколько я понимаю, на практике её включают разве что на серверах, где требуется усиленная безопасность. Во всяком случае, по умолчанию это вроде как выключено.
ответить
Про сервера и
Про сервера и усиленную безопасность -- это вы путаете с исполнением в стеке. Что касается исполнения в секции данных, то оно запрещено ВСЕГДА, в любой мультизадачной системе, и, кстати, точно так же, как модификация секции кода.
Чтобы сделать возможным JIT, нужно затребовать у системы новую секцию памяти с соответствующими флагами (одновременно доступную на чтение, запись и исполнение). В *nix-системах это делается с помощью системного вызова mmap. И да, это возможно сделать, в книге утверждение слишком категоричное. Во втором издании поправлю.
ответить