Андрей Викторович Столяров: сайт автора

Открою один секрет: мне никогда не приходило в голову эту задачу решать через комбинации. Хотя ваше решение, несомненно, верное.

P.S. вы ещё глубже свой комментарий закопать не могли? Этот раздел гостевухи был закрыт почти два года назад.

С моей точки зрения все возможности CSS, находящиеся за пределами спецификации CSS1, являются недопустимыми. Что касается CSS3, то эта мерзость алгоритмически полна, то есть её использование недопустимо по тем же причинам, по которым недопустимо использование JS и любого другого исполнения на стороне клиента. А ещё, как мне кажется, вы ошиблись сайтом: здесь вам делать явно нечего.

Можно ли считать информационным насилием выступления певцов-музыкантов и продавцов мелочью в вагонах электричек?

Несомненно.

Есть ли разница между ними и теми, что выступают в переходах метро?

Разница если и есть, то чисто количественная:

в вагоне деваться некуда, да и лень пересаживаться на другое место, а в метро ты мимо проходишь, если не нравится.

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

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

Хуже всего то, что вопрос "а где граница?" не имеет однозначного ответа. Но если в принципе осознать проблему (чего пока что и близко нет) и перестать разглагольствовать о "свободе самовыражения" и прочих "свободах" в применении к местам открытого доступа, то, пожалуй, уж проблема коробейников и попрошаек окажется решена всерьёз и с концами.

Я никогда не пытаюсь никого учить тому, чего не умею сам.

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

Нет. В многозадачных системах секция кода доступна работающему процессу только на чтение, так что программа не может изменять свой собственный код в рантайме. Раннее фоннеймановское программирование славилось именно этим — пока не придумали косвенную адресацию, единственным способом работы с массивом была прямая модификация адреса в коде команды, осуществляющей к этому массиву доступ.

Что такое прерывание и почему вокруг этого термина нагородили много ахинеи?

Ответ на этот вопрос имеется во втором томе, параграфы 3.6.3 и 3.6.4. К сказанному там добавлю, что превращение программирования из инженерной дисциплины, доступной (и интересной) лишь узкому кругу, в явление массовое пришлось на 1980-е годы, когда господствующей "платформой" был MS-DOS. При программиовании под MS-DOS довольно часто приходилось упоминать так называемые "программные прерывания" (термин само по себе дебильный), и слово "программное" часто забывали, так что публика стала забывать изначальный смысл слова "прерывание".

Да возьмите какую-нибудь небольшую настольную игру и сделайте программу. Можно, например, те же крестики-нолики сделать.

Увы, я не видел вообще ни одного задачника по Си и тем более по Си++, которые мог бы рекомендовать. Да и вообще я настороженно отношусь к задачникам по программированию. Если вам нравится программировать, то заморочку вы себе найдёте сами, а если не нравится — то какой смысл мучиться?

Пардон, а что ж вы, будучи сыном учителя и всё такое прочее, "сходу" вместе пишете? :-) Я, впрочем, тоже так же писал, пока меня мой корректор от этой плохой привычки не отучила.

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

В общем, что-то делать надо, но что именно -- я пока не понял.

Честно говоря, очень давно собираюсь поставить gopher-сервер. Никак не находится время для этого, но, я надеюсь, рано или поздно найдётся.

Политика премодерации у меня очень простая: я раскрываю только те комментарии, которые по какой-то причине хочу видеть на сайте, либо такие, на которые мне (опять же по какой-то причине) интересно написать ответ. Все прочие — такие, на которые мне, к примеру, просто лень отвечать, и которые при этом, с моей точки зрения, сайт интереснее не сделают — остаются закрытыми.

Менять в этом плане я ничего не буду. Если не нравится — в Интернете есть много других сайтов.

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

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

Теперь по поводу софта. Когда речь идёт о "покупке" или "продаже" якобы "софта", на самом деле при этом вам ни в каком смысле не продают софт — вам продают эфемерную сущность, именуемую "лицензией". Эта сущность не имеет никакого (прописью: никакого) отношения к работе программиста, результатам его труда и т.д. Более того, к работе (и к зарплате) подавляющего большинства программистов вообще не имеет никакого отношения так называемое "авторское" право, поскольку примерно 99,99% всего софта в мире, если считать, скажем, по объёму исходников, пишется на заказ для одного конкретного заказчика, который, собственно говоря, всё и оплачивает.

Оставшиеся 0,01% — это так называемый "коробочный" софт, т.е. такой, который пишется не под конкретного заказчика/пользователя, а в инициативном порядке по принципу "ща наваяем, а потом кому-нибудь продадим". С таким же успехом можно выйти на улицу, выкопать яму 1x1x1 метр и требовать за это вознаграждения. И да, программистов, которые соглашаются в таких проектах участвовать, я, мягко говоря, не понимаю — они своими руками разрушают собственный мир.

Весь ваш бред про юристов, преподавателй и т.п., разумеется, никакого отношения к делу не имеет вообще ни с какой точки зрения: эти люди тратят своё время по заказу конкретного заказчика. Собственно говоря, в мире есть всего две категории сущностей, которые могут стоить денег: это (1) материальные предметы и (2) время, потраченное человеком по прямой просьбе/заказу/etc другого человека.

Про команды под root'ом: нажимаете Ctrl-Alt-F1, попадаете на текстовую консоль, там входите под root'ом (то есть вводите имя пользователя root и его пароль), получаете приглашение командной строки привилегированного сеанса работы. Собственно, в этом сеансе всё и делаете, что требует полномочий root'а (и это должно быть как можно меньше).

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

Так или иначе, я Паскаль рассматриваю уж точно не потому, что он "простой"; конкретные причины выбора языков программирования подробно расписаны во втором ("методическом") предисловии к первому тому. Что же касается бейсика, то его рассмотрение мозгам начинающего программиста может только повредить. Есть языки ещё проще, чем бейсик, и с ними часто бывает примерно такая же ситуация, хотя и не всегда.

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

Воспринимать ли это как аналог SystemD в системах BSD?
Если системный менеджер nosh будет являться аналогом s-d, то уйти от подобных «оптимизаций», поменяв ядро Linux на ядро BSD, будет весьма проблематично.

Во-первых, нет никакого единого "ядра BSD". Каждая из основных современных BSD-систем (OpenBSD, FreeBSD, NetBSD, DragonFlyBSD) имеет своё ядро, разрабатываемое отдельно.

Во-вторых, нельзя просто "поменять ядро Linux" на ядро, например, OpenBSD. Все BSD-системы, в отличие от Linux, это цельные системы, требующие для корректной работы не только своего ядра, но и своей базовой системы, также разрабатываемой отдельно. Теоретически подменить базовую систему какой-либо BSD на базовую систему из Linux возможно, но практически это сделать достаточно непросто. Не знаю, кстати, насколько жив сейчас проект Debian/FreeBSD.

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

Лично я ушёл с Linux на OpenBSD пару лет назад, чем очень доволен. Жалею только, что не сделал этого раньше (лет 10 назад возникала у меня такая мысль, но тогда я её не осуществил).

А чёрт его знает, как это воспринимать. Сон разума рождает чудовищ.

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

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

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

Ну хотя и сбежав сразу, в принципе, не особенно много потеряете :)

Как вы относитесь к продукции фирмы Apple?

Очень плохо отношусь.

Возможно ли изучать программирование в MacOS

Я сильно сомневаюсь, что при работе под MacOS вы сможете сделать командную строку своим основным интерфейсом для работы. Там оконные приложения ("родные" маковские) из командной строки вроде и запускаются, но через жуткую гадину.

Одно можно сказать в пользу MacOS: это всё же лучше, чем Windows. Но это не потому, что MacOS хорошая, а потому что придумать что-то хуже, чем Windows, вообще вряд ли возможно. Ну, это если про операционку как таковую говорить. А вот железки от Apple — это, я бы сказал, за гранью приличия; если у вас есть настолько лишние деньги, можно найти очень много способов их потратить с пользой, а не отдавать этим уродам.

Что-что, известно что: только массовые расстрелы спасут цивилизацию. Мне вот другое интересно, вы что вообще услышать ожидали? И с какой целью задаёте вопросы, ответ на которые заведомо очевиден?

Возможно, в контексте браузерного JS кому-то покажется интересным сей текст. Хотя такой эсперимент, разумеется, каждый может провести самостоятельно.
P. S. Андрей Викторович, если не секрет, что за софтина у вас генерирует такую лютую капчу?

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

let sortedArray = unsortedArray.sort((a, b) => a-b);

Казалось бы, в чём подвох? А вот "крутые разрабы" теперь, похоже, вообще забыли про ключевое слово function и лепят из "стрелочек и скобочек" такую лапшу, что небезызвестный Brainfuck обзавидуется (полюбуйтесь хоть на оф. документацию к Node.js, которую, по идее, не последние раздолбаи писали).
Но JS, всё же, не самый плохой язык, а с приходом ES2015 ещё и ставший довольно выразительным, если подходить к его использованию с умом и невысоким коэффициентом кривизны рук.
P.S. Из вашего комментария можно сделать вывод, что есть тут некоторое лукавство: в предмете вы все же разбираетесь, т.к. вопрос, по всему видно, не праздный и продиктован некой насущной потребностью. Зачем вам в таком разрезе спрашивать чьего бы то ни было разрешения на использование того или иного инструмента, не совсем понятно. Новичку вряд ли бы понадобился встраиваемый язык в сишном проекте. Ну а раз душа лежит к JS, берите этот самый Duktape и пользуйтесь, а уж пользователи вашей программы дадут ей оценку.

http://www.opennet.ru/opennews/art.shtml?num=50231
В более сложных ситуациях в контексте сайта запускается JavaScript-код, исправляющий проблемы с совместимостью.

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

Я тут недавно набрёл на термин «дихотомия Оустерхаута» (Оустерхаут — это, если что, автор Tcl). Вот тут описано, что это такое: Ousterhout's_dichotomy

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

Мораль: в роли языка общего назначения (вот эти всякие Node.JS и прочее) интерпретируемые языки не годятся вообще никакие и никогда. В роли языка для скриптинга... э... ну, может быть, но зачем, когда есть Tcl?

Я не использую Wine -- пока ещё ни разу не возникло в этом потребности.

По поводу "если альтернатив нет" — ну, так практически не бывает, это разве что всякие маргинальные случаи: например, из моей практики — вот для налоговой или ПФР нужно некие бумажки подготовить в определённом формате и для этого есть какая-то "бесплатная" программа, естественно, под Win. Для этой мерзости у меня есть ноутбук с WinXP :-) Включается в среднем раз в два месяца, остальное время выключен и завален бумажками.

Что же до варианта "проигрывают по тем или иным показателям" — это в принципе некорректная постановка вопроса. Программ, для которых недоступен исходный текст, просто нет, они не существуют. Сравнивать по каким бы то ни было показателям то, что существует, с тем, чего не существует — занятие исходно дебильное.

На сайте самые поздние даты, какие удалось найти — 2009 год; ссылка на репозиторий ведёт на дефолтную страничку апача, т.е. этой части сайта уже просто нет. Новости там без дат, так что когда эта их 10.0 вышла — непонятно.

Вот раз:

http://infoviolence.org/ru/vblog/ (если предпочитаете youtube, то вот: https://www.youtube.com/c/infoviolence)

Вот два: http://www.croco.net/croco/papers/stolyarov_philosophy_thesis_infofreedo...

А "что должно произойти" — ну это довольно очевидно: людей происходящее должно задолбать в достаточной для социальных потрясений степени.

Нет, не могу. Эта тема реально необъятна.

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

А вообще прикольный текст, спасибо :)

Это оказалось труднее, чем я думал. Держать свой кассовый аппарат для этой цели абсолютно бессмысленно, расходы на его содержание превысят не то что прибыль — скорее даже "грязную" выручку. Я хотел найти какой-нибудь действующий интернет-магазин для этой цели, но, к своему удивлению, не нашёл. Собираясь его искать, я не учёл одной простой вещи: те, кто торгуют бумажными книгами, нынче практически поголовно продают ещё и воздух в виде электронных книг, мне с ними сотрудничать религия не велит. Так что официальной возможности продавать книги физлицам у меня нет и не предвидится.

Не знаю как насчёт систем "вообще", но вот конкретно авторов CMake, а также тех, кто его использует в своих проектах, надо топить в бочках с дерьмом.

Предвосхищая вопрос "за что", вот: https://openwall.info/wiki/people/croco/crocos_lamp <-- искать по слову "cmake".

Вообще что можно сказать о разработчиках, которые решают какую-то там свою проблему, которая не факт что вообще существует, и при этом устраивают тонны геморроя майнтейнерам? Майнтейнеров-то побольше, чем разработчиков. Это даже не безответственность, это какой-то беспредел, и касается это не только cmake. Например, любая разработка на интерпретируемых языках, если предполагается неопределённый (неограниченный) круг пользователей, оказывается из той же серии. Вообще любые действия разработчика, которые налагают дополнительные требования на систему конечного пользователя (типа, надо, чтобы у вас там стоял интерпретатор, или библиотека, или ещё что-то), да и на систему сборщика пакетов тоже — это безответственность.

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

Стало интересно — прочитал википедию. Стало ещё интереснее. Распределённая система поиска P2P, никому не принадлежит, никому не подчиняется, ну просто класс. Сразу же возникли технические вопросы — а сколько она сгенерит трафика (ну не весь же веб она ко мне в локальный индекс притащит), а как там с действующими пирами, а... Ну, вы поняли. Аж захотелось попробовать.

Зашёл на сайт, и началось. С отключённым JS там тупо блоки друг на друга налезают, за такую вёрстку надо убивать просто сразу — это даже не техническая безграмотность, это какое-то дебильное и бессмысленное вредительство. Сама она написана на Java, ну спасибо, матерь ихнюю так. О возможности разделения на серверную и клиентскую часть — ни слова, во всяком случае с ходу; вот у меня есть сервер в датацентре, я бы ту часть, которая по вебу ползает и с пирами общается, там запустил, а с домашних машин уже бы к этому всему хозяйству обращался. Впрочем, даже если бы такая возможность была предусмотрена, я на своих серверах Java в любом случае поднимать не стану, это долго и не факт, что вообще получится. Под Openwall её придётся собирать из исходников, и в своё время с Erlang'ом у меня это не вышло, вот просто тупо не собралось с невнятной диагностикой, а Java пожирнее будет и уж наверняка покапризнее.

Короче, разбег на рубль, прыжок даже не на копейку, а на грошик ломаный. В нынешнем виде это не взлетит.

Что нужно, чтобы она взлетела? Нужно говорить не о "программе", а о системе с открытым протоколом. Нужно подробно, вдумчиво документировать этот протокол, чтобы кто-нибудь мог сделать альтернативную реализацию хотя бы серверной части. Потом нужно найти того (тех), кто реально это сделает на чистом Си или хотя бы на C++. Вот после этого появится призрачный шанс, что оно хоть как-то взлетит.

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

Выглядит неплохо.

Что резко не понравилось -- unicode в языке. Работа с бинарными форматами данных -- забота библиотек, а не языка. И, увы, из приведённых примеров не видно, насколько там в действительности библиотека отграничена от языка. Термина "стандартная библиотека" эти ребята не избежали, а зря -- не должно быть такой сущности; с другой стороны, библиотека (в том числе стандартная) там импортируется в виде объекта, имеющего имя (притом заданное пользователем), что, в принципе, демонстрирует правильное отношение к библиотечным возможностям.

В общем и целом, посмотрим, что из этого всего вырастет.

1) Слово inline пришло не из стандарта, а из C++, где оно присутствовало изначально (то есть до того, как за C++ всерьёз принялись стандартизаторы). C99 лишь "согласился" с реальностью, в которой на тот момент жили едва ли не все компиляторы. Ответом на ваш вопрос, видимо, является то, что лично я слово inline использую, в том числе и в программах на чистом Си.

2) Не думаю, что для вас приходить на этот сайт было хорошей идеей.

У убунты есть несомненное достоинство — она ставится легко. На этом её достоинства заканчиваются.

Если не боитесть сложностей — берите вообще любой дистрибутив, лишь бы он не был чисто серверным или супер-замороченным вроде Gentoo. Ну, возможно, лучше выбрать какой-то без systemd.

Вопрос был бы корректен, если бы «решение» в виде JavaScript можно было бы считать хоть сколько-нибудь допустимым; но это не так, применение JS на сайтах по сути своей преступно. С тем же успехом подсудимый, которого отправляют в тюрьму за серию квартирных краж и разбойных нападений, мог бы требовать от судей указать ему «альтернативу кражам в плане быстрого получения большого количества денег, что особенно актуально, когда не хочется работать».

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

И, кстати, JS как средство экономии трафика — миф. Если бы кто-то реально хотел экономить трафик, мы не наблюдали бы (чуть менее чем везде) HTML-код, в котором собственно содержание занимает считанные проценты общего объёма. Зато именно с помощью JS хозяева сайтов со всякими видосиками и музончиками делают так, чтобы неискушённый пользователь мог посмотреть или послушать, но якобы не мог скачать (то есть сохранить себе локальную копию). Экономия такая экономия — как раз самые тяжёлые формы контента скачиваются по десять раз вместо одного.

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

С одной стороны, давно пора.

С другой стороны, большинство перечисленных по ссылке "альтернатив" лучше разве что тем, что они скромнее по масштабам. Вот никак люди не поймут — вся инфраструктура должна быть своя, а не «любезно предоставленная добрым дядей».

У Кернигана с Ритчи и const вообще-то не встречается.

Словом volatile вы сообщаете компилятору, что эту переменную может изменить кто-то, кто НЕ находится под контролем компилятора. Какой-то "внешний игрок", о существовании которого компилятор не в курсе. Реакция на это — компилятор перестаёт пытаться оптимизировать работу с такой переменной на основе собственного знания, что вроде бы сгенерённый им код эту переменную не меняет. Например, компилятор мог бы временно "слямзить" значение переменной в регистр — и если вроде бы менять её некому, то компилятор не будет переменную из памяти перезагружать в регистр каждый раз, когда она используется; а вот если она volatile — то будет, поскольку мало ли кто её там успел поменять в этой вашей памяти.

Вариант const volatile изрядно напоминает взаимоисключающие параграфы, но на самом деле встречаются ситуации, когда это может быть осмысленно. Такая область памяти запрещена к изменению _вашей_ _программой_, но при этом вы сообщаете компилятору, что эту же самую область памяти может внезапно поменять _кто-то_ _другой_. Элементарный пример: у вас есть кусочек разделяемой памяти, который вашей программе доступен только на чтение, но вы точно знаете, что есть какие-то другие программы, которые к той же разделяемой памяти обращаются на запись.

Вне контекста вопрос лишён смысла, но я попробую восстановить несколько разных контекстов. Итак, если вы пишете на чистом Си, то в роли i у вас или целочисленная переменная (не обязательно int, это может быть целое любого размера), или указатель. Поскольку речь идёт об итерации (по-видимому, цикла for), операция ++ используется ради побочного эффекта, то есть вас не волнует значение, ею порождаемое (то, чем как раз и отличаются ++x и x++). Так вот, в этой ситуации, можете быть уверены, в машинном коде окажется команда inc, причём переменную цикла ваш компилятор будет стараться разместить в регистре, так что это будет что-то вроде inc ecx. И это никак не зависит от формы, в которую вы облечёте вашу операцию, будь то ++i или i++. Или даже i+=1. Да напиши вы хоть i=i+1, машинный код получится тот же самый. Компилятор не дураки писали. При этом традиционно более популярен именно вариант i++; почему? а чёрт его поймёт.

Если даже вы пишете на Си++, но не пользуетесь мерзким подельем по имени STL, то ситуация в общем и целом будет ровно та же.

А вот если вы таки используете STL, в котором все так называемые итераторы за каким-то лядом реализуют обе формы ++, причём в сигнатуре, "соответствующей исходной семантике" (кто только эту хрень выдумал), то всё резко меняется. В форме ++i значением, возвращаемым из operator++, будет новое значение итератора, так что, как правило, этот operator++ имеет форму примерно такую:

class A::B::C::whatever_damn_iterator {

    const whatever_damn_iterator& operator++()
        { /* "двигаем" итератор */ return *this; }

};

Здесь "соблюдение семантики" ничего не стоит, ну подумаешь, возвращаем ссылку на свой собственный объект, к тому же оптимизатор это выкинет всё равно (если, конечно, метод останется inline'овым, что не факт).

Совсем другое дело -- i++. Тут нужно вернуть то значение, которое _было_, поэтому ссылка на себя не работает. Получаем вот такого монстрика:

class A::B::C::whatever_damn_iterator {

    whatever_damn_iterator operator++(int)
    {
        whatever_damn_iterator save(*this);
        /* двигаем итератор */
        return save;
    }

};

То есть приходится сделать копию самого себя (где? а на стеке, ну где же ещё), потом её возвращать по значению (а как ещё локальную переменную вернуть). В принципе оптимизатор с этим теоретически может что-то сделать, но на практике такое громадное тело уже не будет inline'овым, так что и оптимизации нам не видать.

В итоге STL-фаги и прочие маньяки "рекомендуют" в Си++ писать всегда ++i. Вообще. Просто вот привыкнуть так писать и никогда не писать наоборот. Чтобы случайне не вызвать "не тот" метод итератора.

Что по этому поводу можно сказать -- обычно на мой сайт STL-фаги не ходят :-)

Это не "защита от копирования" — копировать файлы вы можете без технических ограничений (что не отменяет условий лицензии, но речь сейчас не об этом). Это защита от перевода в другой формат. Во всех PDF-файлах, представленных на этом сайте, намеренно сломан текстовый слой. Поиск при этом, естественно, невозможен, в файлах нет той информации, которую можно искать.

Стоит заметить, что отсутствие поиска в бумажных книгах и их отсканированных версиях (например, djvu) почему-то никому не мешает. PDF-файлы здесь выложены в открытый доступ, чтобы книги можно было прочитать, не покупая бумажный вариант. Эта цель достигнута. Целей сделать электронный вариант удобнее бумажного я себе никогда не ставил.

Из всех новшеств, появившихся в C++ "благодаря" стандартизаторам, относительно осмысленными и полезными можно назвать разве что enum classes, не вываливающие имена констант в объемлющее пространство имен. Причем пользы от них, имхо, было бы больше в чистом Си, ибо в C++ и без них можно было писать так

struct RainbowColors {
  enum { red };
};

struct RGBColors {
  enum { red };
};

и использовать RainbowColors::red и RGBColors::red без конфликта имен. Возможно, существуют где-то в природе ситуации, в которых оказываются полезными variadic templates, хотя мне доводилось наблюдать разве что "игры в функциональщину" на их основе.
Все остальное - как раз та самая одна сплошная глупость, делающая употребление стандарта невозможным не только, как вы изволили выразиться, по идеологическим убеждениям, но и по соображениям здравого смысла.

auto в значении "тип выводится из контекста" — это совершенно очевидный источник ошибок из тех, которые компилятор мог бы выловить при компиляции, если бы ему не мешали. Когда программист пишет тип переменной в явном виде, он тем самым указывает, чтО он имеет в виду; если инициализатор при этом имеет другой тип (мало ли, ошиблись в имени функции, или в количестве звёздочек, или ещё в чём), компилятор это поймает. Со словом auto компилятор молча введёт переменную того типа, какого получился инициализатор — например, молча сделает локальный (стековый) объект размером в пару мегабайт вместо указателя на такой объект. Ну а "неявные" шаблонные методы — это вообще за гранью добра и зла, они позволяют макакам делать то, чего они не понимают.

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

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

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

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

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

Если говорить о программистах (а не о веб-разработчиках, которые такие же программисты, как маляры — художники), то мозги для них обязательны, вопрос лишь в их уровне. Можно ли быть программистом, не имея высшего образования? Можно, я многих таких знаю. Можно ли быть программистом, не зная математики? Можно. Можно ли быть ХОРОШИМ программистом, не зная математики? Лично для меня этот вопрос открыт, я ни одного такого не видел пока.

А что знания "непосредственно не применяются" — это детский лепет тех, кто так и не понял, зачем нужно высшее образование. NB: знания (точнее, навыки) для непосредственного применения дают разве что в техникумах и прочих ПТУ.

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

Если речь идёт о базе, "без которой никуда" — ну, поставить незнакомый дистр линукса можете? А FreeBSD? А дальше с ними работать через сеть удалённо в терминальном режиме? А поднять на них веб-сервер? А почтовую систему поднять? А воткнуть в машину вторую сетёвку и превратить её в маршрутизатор? А сетку из десятка машин собрать? А NAT настроить? А порт статический пробросить (через NAT снаружи внутрь)? А бекапы автоматические заточить?

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

Этого материала нет не только в свободном, но и вообще в каком бы то ни было доступе. Чтобы он — материал то есть — был, его нужно написать, т.е. воплотить в виде текста. Надеюсь это в ближайшее время сделать, т.к. это планируется в качестве части четвёртого тома.

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

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

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

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

Не вижу ничего принципиально нового, во всяком случае на первый взгляд это обычная прокся. ACL'ы для того же squid'а, режущие рекламу, мне попадались ещё в конце прошлого века :-)

как в информационно свободном обществе начать личный диалог к примеру с Вами?

Вы сами дали ответ на свой вопрос:

Одно дело когда вы на сайте публично размещаете свой email для связи(тем самым давая согласие на получение по этому адресу писем связанных с тем, что Вы тут публикуете)

Именно так, причём открытая публикация адреса, да и вообще любое (не обязательно открытое) сообщение своего адреса ещё не означает, что таким адресом можно воспользоваться для чего угодно. Как правило, из контекста понятно, с какой целью адрес предоставлен, если же непонятно — следует исходить из наименее удобного для себя предположения.

другое дело, когда(теоретически) Вас встречаешь на улице и хочется задать вопрос лично(на что Вы получается согласия не давали)?

Совершенно верно, я согласия не давал ко мне на улице приставать с вопросами. Если кому-то "хочется", то это его проблема, не моя.

Правда ли что, к примеру, попытка просто побеседовать с незнакомым человеком на улице будет являться информационным насилием на ним?

Да, естественно. Заведомо. Я вам больше скажу, я глубоко убеждён, что в отдельных случаях (сильно не во всех, конечно) в ответ на попытку навязать коммуникацию на улице должно быть официально разрешено открыть огонь из огнестрельного оружия на поражение.

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

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

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

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

Что касается "почитать" — насколько мне известно, кроме меня никто информационное насилие не рассматривал в таком значении термина. Так что кроме своего диссера, пожалуй, мне нечего предложить на эту тему. Диссер, если что, тут: http://www.croco.net/croco/papers/stolyarov_philosophy_thesis_infofreedo...

Как мы знаем, в 1861 году в Российской Империи было отменено крепостное право; часто можно видеть, как этот (безусловно правильный) шаг вменяют в заслугу тогдашнему царю Александру II. К чему это я? А к тому, что не отменить крепостничество в России было объективно невозможно: промышленности требовались рабочие, ну и прочее в таком духе. Если там где-то и есть "заслуга" царей, включая Александра, то она разве что в том, что отживший и изживший себя феодализм продержался в России лет на сто дольше, чем ему объективно стоило.

Вот примерно такова же ситуация и с M$. Поддерживать своё проприетарное ядро ОС силами одной конторы в современных условиях невозможно, Apple эту фишку просекли на рубеже веков, так что MacOS X внезапно оказалась представителем семейства юниксовых. Вот теперь допёрло и до мелкомягких.

И нет, моего отношения к ним это не смягчает, даже наоборот. Билл Гейтс и его контора обокрали цивилизацию на пару десятков лет развития. Логика развития мира устроена так, что они должны были сдохнуть, но вместо этого они, чего доброго, уморят Linux. Всё, к чему эти мрази прикасаются, превращается в дерьмо, давно пора это понять.

Начать с книги Платта. Конечно, весь современный софт именно что sucks, только не факт, что именно по тем причинам, про которые говорит Платт. Если на то пошло, мне больше нравится книга Алана Купера "Психбольница в руках пациентов" (переведена на русский, в инете представлена в изобилии) — вроде она про то же (usability), но как-то более конструктивно, что-ли.

Заметим, следующая ваша ссылка — suckless — не только не про то, но даже наоборот. "Задолбал софт для идиотов, мы пишем только для умных". В принципе, это тоже весьма правильный подход: у меня временами складывается ощущение, что, не зная, как сделать софт удобным для сферического "конечного пользователя" в вакууме, софтописальщики считают своим долгом сделать софт НЕудобным для профессионалов и потом похваляться тем, что якобы их софт написан не для всяких там программистов, а для пользователей. Чушь, разумеется.

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

Harmful things that are so superfluous and useless that require no alternative:

вот тут я согласен с каждым из пунктов :-) то есть буквально с каждым.

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

По поводу "дистрибутива Unix" (гм...), ну в общем если интересно, то на серверах у меня Openwall, а на домашнюю машину последнее, что я взгромождал — Devuan. Я при этом совершенно не уверен, что Devuan сейчас прямо-таки правильный выбор, но на то, чтобы поставить десяток разных дистров без systemd, попробовать с каждым из них поработать и выбрать лучший, нужна реально прорва времени, а результаты таких "исследований" за пару лет устаревают (вот кто бы мог подумать, что CentOS скурвится — а поди ж ты, переползли тоже на systemd). Короче говоря, нету у меня такого количества лишнего времени.

Что касается сборки мусора, то мракобесием я считаю не её саму как таковую, а её сочетание с императивным программированием. См.тут: http://www.stolyarov.info/pvt/anti_c#comment-129 и тут http://www.stolyarov.info/books/programming_intro/vol2#comment-1171

Только ссылаться всё же лучше на оригинал, благо запрос Гуглу, дословно повторяющий заглавие статейки, эту ссылку выдаёт первой:

https://sly2m.livejournal.com/620353.html?nojs=1

Hint: перед тем, как кликнуть по ссылке, выключите в браузере JS. Тогда вы не увидите там рекламы.

А вообще спасибо — в поисках оригинала текста я обратил внимание на этот блог как таковой, так вот его можно читать не отрываясь, пока не кончится. Всем рекомендую. Жаль только, что он в ЖЖ. А автор, с одной стороны, в одном из постов возмущается, что реклама от СУПа добралась даже до платных аккаунтов, а с другой -- в каком-то старом посте превозносит Носика, а в более новом -- сокрушается, что тот помер.

Насколько я понимаю, это бывшая PLT Scheme, а переименовали её, чтобы дистанцироваться от дебильного R6RS. Ну, я в принципе против лиспов и схем ничего не имею, против дистанцирования от "стандартов" — тем более. С другой стороны, беглый взгляд на список "новых возможностей" заставляет подозревать, что на выходе получился очередной монстр.

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

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

И точка зрения далеко не нова, и SICP был на Схеме основан, и, больше того, у меня есть примеры студентов, которым императивщина покоряться не хотела, а рекурсивное программирование они осваивали с полпинка (и потом уже переходили на императивщину).

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

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

Лично для меня systemd в основном плох (фатально) ровно одним: это, я бы сказал, хрестоматийный пример ньюфажства. Любая "новая технология" имеет право на существование лишь при соблюдении определённых условий; в частности, она должна решать реально существующие проблемы, которые старая технология решить не может. В противном случае трата времени на освоение новой технологии бессмысленна; а бессмысленно тратить время я себе позволить не могу, жизнь для этого слишком коротка.

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

В принципе этим не только systemd славится, я вот тут потратил примерно час, чтобы понять, как в нынешнем X.org таки вернуть возможность убивать сервер по Ctrl-Alt-Backspace, и чтобы при этом не сломалось переключение регистров клавиатуры. Проблема, как выяснилось, была в том, что теперь, оказывается, xkb options берутся не из собственной конфигурации X.org, а от долбаного udev, у него свой отдельный конфигурационный файл для клавиатуры (/etc/default/keyboard, его я нашёл grep'ом, но не сразу понял, что это именно udev его использует), и потом ещё udev надо перезапустить, причём обязательно с помощью udevadm, поскольку обычный перезапуск на него не действует. Кто мне вернёт этот час?! Какого чёрта кто-то там решил, что "так будет круче", а я за это вынужден расплачиваться собственным временем?

Таки да, я противник не только systemd, мне и udev, и hal, и прочие подобные примочки тоже не нравятся. Они мне низачем не нужны, в том смысле, что они мне не дают никакого профита, а вот на борьбу с их изысками мне приходится тратить время и силы. Если говорить об init'е, то меня вполне устраивает (то есть более чем) классический system V init со всеми его скриптами, так что мне не нужны ни upstart, ни openrc, ни какие-либо иные потуги заменить якобы "старую" технологию, которая полностью справляется с моими потребностями.

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

... и Ubuntu в том числе. Dual boot, опять же, умеют и все известные мне дистрибутивы Linux, и FreeBSD.

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

Что, вот прямо под каждым? И прямо на все сайты? По-моему, это слегка перебор.

У меня страничка открывается без проблем и я для этого ничего не делал. Э?

К сожалению, пока есть только список частей, вот здесь вот.

Первая из этих частей уже готова, она лишь слегка отличается от содержания "Введения в язык Си++"; остальные части, напротив, я ещё не начинал не только писать, но и прикидывать, так что плана глав для них нет.

Честно говоря, не знаю, я не в курсе, что это за программа. Факультет большой, за всем не уследишь.

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

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

попробуйте ranger (выделение всех файлов там точно есть)

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

Так что вопрос я не изучал и ответа на него дать не могу. Ну то есть понятно, что существует, к примеру, Midnight Commander, о его существовании я знаю примерно с тех времён, когда вообще начал работать с *nix (то есть с 1994 года, вроде как раз тогда он и появился), но никогда его сам не использовал, ибо по-моему неудобно.

Я крутейший линуксоид -
Тукс-пингвин на попе виден,
И одно лишь беспокоит -
Столлман не был бы в обиде!

Дядя Столлман - тот суровый,
Ой, беды я с ним хлебну!
Зад оглядываю снова -
Где бы втиснуть ещё GNU?

Это будет мне не в минус,
Пусть дивятся моей силе,
Ведь меня не только Линус,
Но и Ричи изнасилил!

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

Что до меня, то я вообще не люблю татуировки как идею, хотя это уже не относится к обсуждаемому вопросу.

Спасибо, исправлено.

Вот чем вас этот ваш "старый-старый ноутбук" не устраивает, чем спектрум лучше? По мне так пусть лучше ребёнок вам этот ненужный ноут раздолбает, чем живой (пока) спектрум :-)

Игрушек простеньких, в том числе развивалок, для Linux имеется реально прорва.

У меня встречный вопрос, вы где этот спектрум откопали-то? И уж если откапывать непойми что, то почему бы не откопать какой-нибудь, таки да, ПК — ну, скажем, десятилетней давности, не поставить на него Linux и не начать ребёнка знакомить с чем-то более-менее живым. "Нет доступа к ПК" — это, по-моему, может быть обусловлено разве что финансовыми вопросами, но компьютер десятилетней давности можно найти бесплатно или за бутылку пива; живой спектрум сейчас, подозреваю, стоит (в качестве коллекционного экспоната) в десятки, если не сотни раз больше.

Си, конечно, в малом возрасте давать не надо, ну так Паскаль никто не отменял. Всяко лучше, чем спектрумовский бейсик. А про возраст и условия тут ответ, на мой взгляд, очевидный: если ребёнок хочет этим заниматься, то уже можно, и пофигу возраст, а если не хочет — то всё равно бесполезно, и тоже возраст никакого значения не имеет.

Простите, какое отношение ко мне имеет Черногория? Если что, ccTLD .me -- "национальный" домен Черногории, а точнее -- домен верхнего уровня, названный в соответствии с ISO Country Code этой вот самой Черногории.

Кроме .info, меня ещё устроил бы .net, но он на тот момент был занят, сейчас не знаю -- не смотрел.

На четвёртых пнях лучшей системой (из полутора десятков поставленных) оказалась Windows XP, которая ведёт себя на этих машинах достойно

А вот и неправда ваша, дяденька! Это не ХР работает "достойно", это просто вы ни черта не сделали для того, чтобы нормально работал ресурсоемкий на сегодняшний день Firefox. Фактически (полагаем у вас однопоточный Celeron), вы имеете "однозадачную операционную систему", все процессы которой предназначены для запуска и нормальной работы Firefox. Можно сказать, вернулись во времена славного чернодосья. Вам частоты в 2 ГГц мало? Да вам требуется всего лишь обеспечить работу этой самой одной-единственной задачи! То есть, отработать вместо не сильно интеллектуального диспетчера операционной системы, распределяющего ресурсы процессора. И в случае именно однопоточного процессора, сделать это куда проще, чем с процессорами, обеспечивающими ряд потоков. Там система усложняется коcмически. А здесь-то чего? Как совершенно правильно было показано, берете и меняете приоритеты. Только не надо ожидать, что на вас сразу же посыплются шоколадные конфеты с неба, как только вы произнесете волшебное "renice ... firefox" и убьете парочку ненужных процессов. По сути, скрипт, запускающий Firefox, будет выглядеть как длинная последовательность renice'ов, касающихся самых разных процессов и заканчивающийся словом "firefox". Ага, мы же обеспечиваем работу лишь одной программе! Остальные будут подождать. Сетка в 40 значений приоритетов в никсах (ну, реально несколько меньше) - довольно широкое поле для самых разнообразных настроек. Под любую программу. И все у вас будет работать.
А теперь попробуйте то же самое учудить под вашей ХР! Если вы давно не видели синий экран, то уже после изменения приоритетов 2-3 процессов (а этих приоритетов там штук пять, наверно, наберется - от реального до никакущего), мы будете приятно удивлены.
На самом деле, частоты однопоточного процессора за глаза хватает для нормальной работы браузера, хоть какого. Решили запустить другую ресурсоемкую задачу - по той же схеме. А моща современных процессоров и операционных систем просто в разы превышает то, что необходимо тому же браузеру. Конечно удобно, когда "включил и все"! Но и процов десятилетней давности тоже вполне достаточно. Просто нужно уметь использовать имеющиеся ресурсы. Чуть приложиться надо, только и всего... И уж сравнивать невесть что с нормальными операционными системами - совсем уж не дело!

"главные дураки занимаются вовсе не разработкой операционных систем, а именно браузеров"
Дык, "маркетинг", как всегда! Intel платит.

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

Что касается firefox, то тоже случается запускать его на процах Пентиум-4. Да, нездорово, тут не попрешь! Хотя сама система работает вполне годно. Все к чему пришел - ставить не самую последнюю версию (у меня получилось минимально - firefox 31), выделить 400 Мб в памяти под профиль, да что-нибудь навроде renice -5 -p `pidof firefox`. Это машины Celeron 2000(2700 разгон)Мгц, 1,2 Гб памяти, Debian 7(wheezy). Полностью проблему не решает, но уже поприличнее... И, разумеется, никаких ненужных, скорее всего, bluetooth, zeitgeist, modemmanager, networkmanager и т.п. быть не должно.

Вот её, родимую, и использую. Ну, точнее iceweasel :)

А так — да, всё именно так и плохо, и именно настолько.

Когда я на третьем курсе столкнулся с Лиспом, моим основным языком был Паскаль (да, я на нём деньги зарабатывал :) дело было осенью 1995 года). И я на тот момент был уверен, что умею пользоваться рекурсией. Так вот, реально я рекурсией пользоваться научился только после Лиспа. А программы-то, конечно, на Си работают шустрее, если их нормально писать. Вот только писать их на Си несколько медленнее.

Кстати, насчёт qsort -- на массивах примерно элементов на 20 (и меньше) тупой пузырёк, вручную написанный, рвёт этот qsort аки тузик грелку.

Не холивару ради, а токмо справедливости для, можно было бы "сишнику" предложить на пробу такой язык, как Tcl. Уж коли автор был неподалёку упомянут. В нём тоже есть нечто интересное. Во всяком случае, идея метапрограммирования, имеющаяся в нём, вполне может быть понята "сишником" быстрее, чем при изучении языков семейства Lisp. Мне, например, кажется, что некто Столлман в оценке этого языка был неправ абсолютно.

"Честно говоря, его практическая применимость выглядит для меня довольно мутной."

В общем, да! :) Понять могу. Примерно также полагаю, поскольку тоже не раз хватался и за Lisp, и за некоторые другие "нестандартные" языки. И если, скажем, Пролог находил у меня применение как некая достаточно удобная среда для органицации баз данных - очень своеобразный язык - сформулировал условия, ограничения, и тут же имеешь ответ, то задачи для Lisp'а не находилось вообще!

Я знаю только один приличный учебник Лиспа для начинающих (в смысле, начинающих лисперов). Хювёнен, Сеппянен. Мир Лиспа. Т.1. Вроде в инете где-то валялись djvu от него. Второй том не нужен, ибо лет двадцать как утратил остатки актуальности, а вот первый как был, так и есть.

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

Вот в чистом Си почему-то ничего никогда глаз не режет!

Бгг, а вы код openssl, например, смотрели?

Знаете, что ОНИ сделали с переменной errno? Она теперь не переменная, она теперь макрос. Примерно такой:

#define errno (*__errno_location())

Вот не знаю как вам, а мне макрос маленькими буквами ещё как глаз режет. И константы, вводимые enum'ом, но при этом набираемые капсом — тоже. И то, что если f — имя функции, то написать можно хоть просто f, хоть &f, хоть *f — и это всё будет одно и то же — режет-режет. А если вернуться к библиотеке, то как вам, например, мьютекс внутри malloc'а? Вот я, например, принципиально никогда — НИКОГДА — не использую треды и другим не советую, почему я должен терпеть мьютексы в библиотечных функциях? Хоть свою libc пиши.

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

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

Но вот дальше, гм... э...

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

Вы ведь пошутили, да? Хотя, похоже, не пошутили.

Ну так вот, в современных (читай — послеDOSовских) условиях операция выделения динамической памяти может кончиться неудачей в двух случаях: если процесс дошёл до максимального возможного размера виртуального пространства (обычно 3Gb на 32-битных системах, на 64-битных можно считать, что этого предела нет вообще) и если в системе реально кончилось пространство для свопа. О наступлении второго случая ваш процесс не узнает — в такой ситуации, во-первых, встаёт раком вся система, и тут уже не до какого-то там несчастного процесса, и, во-вторых, ошибка как таковая случается не при выделении памяти, а при обращении к ней, и выглядит это как прилетевший фатальный сигнал, а вовсе не как NULL из malloc'а и тем более не как исключение из new. Что касается первого случая, то ежели процесс дорос до 3Gb, то, очевидно, работать дальше он заведомо не сможет, так что даже если при этом система его не пристрелит (насколько я понимаю, это зависит от версии ядра), то он в любом случае сдохнет сам, причём прямо сейчас. И уж во всяком случае жалкая утечка памяти, случившаяся непосредственно перед полным армагеддецом — это самое последнее, что должно нас волновать.

(NB: да, я не проверяю значение, возвращаемое malloc'ом)

если использовать std::string в данном случае, то данная проблема исключена просто автоматически

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

Основная причина именно эта. Точнее говоря, сертификат не СТОИТ денег, за него ХОТЯТ денег. А стоить сгенерённые компьютером биты и байты не могут вообще нисколько, то есть принципиально — этим паразитам я не заплачу ни цента.

Если оно на русском было издано в 1997 или раньше, то на языке оригинала, скорее всего, вышло году этак в 1994. То есть до начала степановской эпохи.

Более поздние издания (которые как раз под именем "Айра Пол") я листал, не понравилось. Уже, к сожалению, не помню, чем конкретно не понравилось.

Сам я учился программировать примерно в 1989--1993 гг. Это, понятное дело, был совсем другой мир. Цапнуть любую книжку, в которой хоть что-то полезное есть, и немедленно пробовать, пробовать, а вдруг получится, а компьютеров дома тогда ещё ни у кого не было (понятное дело, когда несчастная 286-я, уже тогда безнадёжно устаревшая, стоила как два автомобиля), поди урви себе пару часов машинного времени, ещё и не сразу найдёшь.

Большую часть книг, которые я тогда прочитал, я уже просто не помню, то есть помню, как выглядели, о чём там было написано, но не помню ни авторов, ни заглавий. Да и не интересны они сейчас. Вот разве что помню, по какой книге изучал C++, тут всё просто: по второму изданию Страуструпа. Это такой двухтомничек был не шибко большого формата, кстати, если попадётся — готов купить за любые разумные деньги, чисто для коллекции. (UPD: всё, неактуально, нашёл :-))

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

Как вы себе это представляете?

Конспекты своих лекций, даже написанные студентками-отличницами, я неоднократно видел — это просто ужоснах и триллер. То есть от лекции как таковой не остаётся вообще ничего. Видео всякое я считал и считаю суррогатом и самообманом.

Мне известен только один способ доступа к "живой лекции" — находиться в аудитории во время её чтения. Никаких других способов лично я не знаю.

Поставьте IceWM :-)

Что касается fvwm2, то я его всю жизнь настраивал "по аналогии", там с ним идёт образец конфига, из которого более-менее всё понятно. Начать с ним работу можно и без кастомизации. Иной вопрос, что, пожалуй, это всё-таки не очень хорошая идея. Для меня fvwm2 -- дело привычки, но у вас-то привычек таких нет.

Одним словом у меня не получится, могу вот тремя: "чёрт его знает" :-)

Относительно того, каким должен быть идеальный язык, уже пара статей была написана, первая из них ещё в 2007 году:

http://www.croco.net/croco/papers/stolyarov_2007b.pdf

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

Да, я при написании этого примера решил, что высота, равная единице, представляет собой валидный частный случай, хотя и вырожденный. Не вижу в этом проблемы, программа работает вполне корректно.

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

Исходно было похоже, что ничего у Rust не получится, поскольку там тоже была сборка мусора и ещё много чего, но, говорят, к 1.0 от всего этого мракобесия избавились.

С другой стороны, говорят (сам не видел), что в Rust имеются высокоуровневые конструкции, реализация (то есть перевод в машинный код) которых неочевидна и может быть выполнена многими разными путями. Если это так, то на смену чистому Си этот язык не годится. Disclaimer: я не знаю Rust :-)

Есть такое, да.

Неужели это баг в Free Pascal?

Этот "баг" известен уже лет десять. И в документации на SeekEOF чётко написано:

The SeekEOF function can only be used on real textfiles: when assigning the file to other kinds of (virtual) text files, the function may fail, although it will perform a number of tests to guard against wrong usage.

Судя по тому, что strace показывает, эта штука убеждается, что на входе не терминал, и на этом основании решает, что можно использовать lseek. А на pipe это у неё, естественно, не получается. Руки бы поотрывать :-)

Императивный язык со сборкой мусора -- это нонсенс. Ну то есть оно может быть альтернативой для Java, поскольку там тоже сборка мусора, но это просто замена одного сорта дерьма на другой. Альтернативой C++ эта хреновина быть не может. К большому сожалению -- поскольку "плюсам" давно уже требуется замена.

Ну да, единица -- это исполнение, а не чтение; вы ведь это имели в виду?

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

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

Теперь к делу. Я требую извинений за слово "украл". Если таковых не последует, дальнейшие ваши комментарии на этом сайте премодерацию не пройдут.

Естественно, должно быть 80286.

Cisco — просто один из монополистов с задранными в космос ценами на железо. Заниматься изучением их "технологий" можно, на мой взгляд, в одном и только одном случае: если вам прямо здесь и сейчас необходимо срочно что-то делать с их железками. Такое бывает, если (1) вас УЖЕ взяли на работу и там надо дрессировать этих "кошечек" или (2) вам кто-то (буквально) подарил железку от Cisco (мне вот на день варенья недавно задарили старый каталист, чисто на поностальгировать) и вы хотите из неё извлечь какую-нибудь пользу.

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

А пока они вам не понадобились, не тратьте своё бесценное время на изучение чьих бы то ни было проприетарных бастардов. Изучайте лучше математику, накачивайте эластичность мозга. Оно всяко полезнее. Это можно выразить и иначе: своё драгоценное время очевидно полезнее инвестировать в себя, любимого, нежели чем в благополучие коммерческого гиганта, у которого, кстати, и так всё хорошо. Изучая технологии, которые являются чьей-то собственностью, вы попросту дарите собственное время владельцу этой технологии. У вас что, много лишнего времени? Я бы сказал, время вообще не может быть лишним, жизнь гораздо короче, чем хотелось бы.

Ах да, ещё один момент: если бы я сейчас строил провайдера, как в тогда 1997 году, то ни одной циски в моей сети бы не было. Это, замечу, несмотря на то, что обращаться я с ними прекрасно умею, там по моим наблюдениям почти ничего не поменялось за 15 лет.

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

Ну да, это проблема. В принципе, довольно типичная "первая сложная задача" — это какая-нибудь игрушка. Естественно, без графики и без GUI. Отсутствие графики само по себе вас смущать не должно, вон в Nethack люди десятилетиями рубятся, и ничего.

А ещё рекомендую глянуть здесь на сайте статью "Почему Unix".

Вот уж чего совершенно в упор не вижу, так это связи между исключениями с одной стороны и этими вашими сборкой мусора и единой иерархией — с другой. Auto cleanup и деструкторы никто не отменял, так что за высвобождением ресурсов контроль полный в любом случае, если работать аккуратно; ну а безалаберность надо лечить не средствами языка, а лишением премии и увольнением с работы, или ещё лучше электрошоком. С другой стороны, как сборка мусора, так и единая иерархия классов (и, как следствие, таблица виртуальных методов в каждом объекте, а то и, чего доброго, все вызовы методов оптом виртуальные) — это приговор языку сразу и без вариантов, то есть такие языки (вроде пресловутой джавы) использованию не подлежат вообще. Хотя, конечно, C++ после выхода новых стандартов хуже уже не станет, понятное дело, то есть мертвее уже не будет, но тут по крайней мере можно декларировать, что используется подмножество, и ещё некоторое время более-менее нормально жить.

У исключений C++ есть другие недостатки, и прежде всего то, что оно тянет за собой RTTI и вообще очень большой и жирный кусок рантайма, да плюс к тому в генерируемом коде возникает (в начале и конце каждой функции) ТАКОЕ, что в машинный код просто страшно заглядывать. Если бы, к примеру, исключения символизировались не типом объекта, как это сделано в C++, а, например, адресом в памяти (то есть делаем глобальную переменную произвольного типа, в ней же храним информацию об обстоятельствах исключения, а кидаем не "объект произвольного типа", а адрес этой переменной, и ловим исключение не по типу, а путём указания глобальной переменной, отвечающей за данный вид исключения), реализация стала бы проще в разы, и рантайм бы в разы уменьшился. Вон на уровне чистого Си есть setjmp и longjmp, они, по ходу, вообще ничего в программу не втаскивают, и, больше того, даже не являются средством языка, обычные библиотечные функции, правда их реализация зависит, конечно, от платформы и компилятора, но это уже детали.

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

Ну а за использование исключений для управления, то есть для штатного выхода из вложенных контекстов, надо убивать сразу. Желательно насмерть. Если в команде есть такие люди, то -fno-exceptions не более чем полумера, а правильная мера — гнать в три шеи. Хотя, конечно, при нынешнем дефиците программистов это не всегда реально.

Что-то мне вспоминается классика:

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

Если серьёзно — да пожалуйста, заходите ещё :-)

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

Что сходу не понравилось -- там на всех страницах javascript и мне не удалось найти ничего на тему его отстригания. Ну а второе -- конечно же, ruby on rails. На моих серверах везде Openwall GNU/*/Linux, для него соответствующих пакетов нет, а самому их делать меня совершенно точно заломает. Мораль -- свой pod мне не запустить. А на чужом я жить не стану, с меня достаточно.

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

Но так всё же лучше, чем никак.

Они не "уползли", они там [ http://www.stolyarov.info/guestbook/archive/1#comment-715 ] изначально и были — я забыл в своё время запретить на той странице новые комментарии, а вы свой вопрос зачем-то оставили там, а не здесь.

Ну а про плюсы — а фиг знает, что движет людьми. Вот как можно, например, на PHP писать? Я имею в виду, как можно себя настолько не уважать, что не брезговать ТАКИМИ инструментами? Но ведь пишут.

У меня возникает ровно один вопрос: а при чём тут я? К Ташкентскому филиалу я, к счастью, уже скоро пять лет как никакого отношения не имею, к курсу "физ.основы" — тем более.

Если попробовать ответить по существу вопроса, то под названием "Физ.основы построения ЭВМ" может скрываться всё что угодно; когда я был студентом, нам в рамках этого предмета рассказывали, как между собой надо соединять микросхемы памяти (и, кажется, всё - во всяком случае, я больше ничего не помню). Что будут вам читать в рамках этого курса, я не имею и не могу иметь никакого представления, это полностью зависит от лектора.

В общем, вы не по адресу. Совсем.

вы высказали свое недовольство

Начнём с того, что слово "недовольство" крайне превратно описывает то, что я сказал. Тут больше подходит словосочетание "крайняя степень возмущения", причём не самими STL и RTTI, а теми идиотами, которые их сначала создали, а затем протащили в стандарт языка.

что именно не так с этими вещами

С ними не так буквально всё. Впрочем, это либо очевидно, либо — если не очевидно — то любые объяснения, как правило, бессмысленны.

Вы предлагаете для каждого проекта каждый раз писать свое подмножество STL?

Разумеется, нет. Тогда уж лучше использовать STL, всё равно хуже уже не будет. Впрочем, можно предложить ещё "лучше": писать на PHP. Или на бейсике. Или на коболе. Чего напрягаться-то понапрасну, Си-плюс-плюс какой-то там, классы, методы, это всё слишком сложно. Берём вижуал васик и вперёд.

Если же PHP или бейсик не устраивает, то я не вполне понимаю, как может устраивать связка C++/STL. Контейнеры, очевидно, вообще нельзя использовать — сама идея таковых порочна. Структуры данных не бывают универсальными, за исключением самых простых (массивов и списков), но использование контейнеров для массивов и списков заведомо бессмысленно — за более чем сомнительный выигрыш во времени кодирования мы при этом вынуждены расплачиваться феерическими приключениями во время отладки и сопровождения, причём ставки там приблизительно неделя (проигрыша) за пять минут (экономии); ну а более сложные структуры данных должны, естественно, проектироваться под каждую конкретную задачу (не под проект, а именно под каждую возникающую задачу), и generic они быть не могут — как следствие, ни о каком применении шаблонов при построении сложных (проблемно-ориентированных) структур данных не может быть никакой речи. Это я уже не говорю о том, что list вообще-то двусвязный, тогда как в большинстве задач список требуется односвязный; или о том, что string в последнее время перестал быть copy-on-write, ну и так далее. То есть даже самые простые порождения STL'я вообще-то никуда не годятся.

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

Или есть что-то лучше, чем STL?

Конечно, есть: его отсутствие.

Если же имеется в виду "есть ли библиотека для решения той же задачи, что и STL, которая решает задачу лучше", то такие наверняка есть (можете поискать в гугле, если не лень), если только допустить, что "та же задача" вообще существует. Я утверждаю, что задачи как таковой попросту нет, поэтому вопрос о существовании аналога STL, который был бы "лучше", оказывается бессмысленным. Не нужен ни STL, ни какие-либо его аналоги. Тем, кто с этим не согласен, следует, очевидно, выбрать другой язык программирования, потому что тратить силы на работу на довольно сложном языке только для того, чтобы идиотская библиотека съела (причём с запасом) все его преимущества — со стороны выглядит как-то глупо.

В каком направлении должен развиваться С++ ?

Теперь уже, видимо, ни в каком. Нужен другой язык, который займёт нишу языка произвольного уровня, в отличие от существующих языков уровня низкого (asm/*, plain C) или высокого (всё остальное). C++ мог занять эту нишу до включения в него RTTI (STL, к счастью, свойством языка не является, так что он бы, в принципе, не смог всерьёз помешать — хотя размах подрывной деятельности стандартизаторов впечатляет, да). В нынешнем своём состоянии C++, особенно в связке с STL — язык, я бы сказал, уровня безнадёжно высокого, приближающийся к командно-скриптовым. Зачем такой нужен ещё один такой язык, не вполне понятно, их уже и так — как грязи.

поправлено