Вышло издание 2,92 книги «Программирование: введение в профессию» А. В. Столярова

Это к вопросу о хостинге. Вот все гигабайты и хости.

Выше про left-pad и использование библиотек из Интернета уже обсуждали. И для компиляции ведь всё равно скачивать приходится.

но в общем-то всё тот же вопрос: какого хрена?

Чтобы можно было запускать скопированный файл, а не раскладыванием предварительно нужных файлов в /usr/share (или /usr/local/share или /opt/share/…).

на каждый чих (платформу, ОС) не напасёшься делать приложения, да и установка у пользователя отдельного софта для работы с каждым сервисом, где недостаточно возможностей чистого html+css хуже даже с точки зрения безопасности, чем js в браузере.

Лучше бы линукс в виртуалке для таких приложений запускали (придумали же docker). Браузер — программа для просмотра гипертекста. Представьте себе, что кто-нибудь решил бы писать программы на скриптах OpenOffice (а что? сразу переносимость всюду, где он запускается).

Да, надо признать, что написание корректных мультипоточных программ дело не совсем простое, но не всегда форки архитектурно легче делать, чем потоки.

Практически всегда.

ощущение, что у Столярова какой-то ограниченный опыт

Он просто проповедует аскезу.

То есть, например, по Столярову недопустимо уметь работать с текстами в utf-16? O_o

Вы много программ знаете, которые работают с текстами в utf-16 и корректно обрабатывают все ситуации с суррогатными парами?

В итоге всё-таки, а при чём тут написание программ на авось или не авось?

При том, что либо пишешь программу так, что понимаешь её поведение полностью. Либо «программа поддерживает юникод (авось разработчики библиотеки полностью реализовали поддержку), умеет работать с JSON (авось разработчики библиотеки …), умеет импортировать XML (авось разработчики библиотеки …), …».

Написать программу без «идеосинкразий» автора так, чтобы полностью отвечать за её поведение, почти нереально.

параметр -j часто почти линейно ускоряет компиляцию.

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

Одно ядро ждёт чтения, другое (или вообще несколько) - обрабатывают

Как же деды ждали окончания ввода-вывода без дополнительных простаивающих ядер? Конечно, у них были КАНАЛЫ, но речь-то о CPU.

Как же деды ждали окончания ввода-вывода без дополнительных простаивающих ядер? Конечно, у них были КАНАЛЫ, но речь-то о CPU.

Я может коряво выразился, но речь об ускорении обработки считанного за счёт нескольких ядер. Конечно, если даже одного ядра хватает для того, чтобы полностью обработать порцию данных, пока считывается другая, то ускорения не будет. Но как уже заметил, SSD, даже пользовательские, реально быстро работают.

И для компиляции ведь всё равно скачивать приходится.

Придётся. С другого сайта. Да, понимаю, зависимости могут бесить и вообще протухнуть, но и средства их хостить у себя не у всех имеются. Вопрос размера.

Чтобы можно было запускать скопированный файл, а не раскладыванием предварительно нужных файлов в /usr/share (или /usr/local/share или /opt/share/…).

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

Лучше бы линукс в виртуалке для таких приложений запускали (придумали же docker). Браузер — программа для просмотра гипертекста. Представьте себе, что кто-нибудь решил бы писать программы на скриптах OpenOffice (а что? сразу переносимость всюду, где он запускается).

Если бы OpenOffice был бы везде, как браузеры, то могло бы иметь смысл. Ты лучше представь, что для того, чтобы воспользоваться сервисом, вроде yandex maps с картой транспорта тебе обязательно надо было бы поставить в свою систему их приложение. Или, наоборот, тебе как разработчику сервиса непременно надо было бы наплодить вариантов для разных ОС и аппаратных платформ. Впрочем, яндекс может и наплодил, но у них свои соображения и возможности.

Вы много программ знаете, которые работают с текстами в utf-16 и корректно обрабатывают все ситуации с суррогатными парами?

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

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

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

P.S. Мне тоже многое не нравится в совремённой разработке, но я при этом понимаю, что это часто следствие более глубоких причин, чем просто вредные привычки. Поэтому попытки провозгласить табу тут ничем не закончатся, никакого rebuild world с хорошими и правильными программами не произойдёт.

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

Обучающийся подготовится к выпускным экзаменам по ИКТ

Куча людей теряет данные, например, в офисных программах, вроде Word при их сбоях, что-то никто не отсудил ничего.

Есть ссылка на решение суда или хотя бы номер дела? Крайне интересна аргументация судьи.

Он сам же утверждает, что параллельная работа часто упирается в I/O, а не процессор, в этом случае проще распределять работу по нескольким асинхронным потокам в рамках одного процесса.

Практически одинаково.

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

Так делишь на интерфейс демон. Как mpc + mpd. В пределе они даже на разных языках могут быть.

Сейчас например серверы работают с десятками и сотнями докер-контейнеров, в которых крутятся виртуальные машины с сервисами

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

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

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

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

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

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

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

проще находить и использовать готовые решения?

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

Хотя вру. Есть TeX и qmail. Но эти обе программы написаны по заветам Столярова (без внешних зависимостей кроме операционной системы).

А почти во всём остальном выбор из нуля нормальных решений.

Потому что есть сложившаяся экосистема из библиотек

Вот именно. Не надо как лучше, а надо как принято. Поэтому вся эта экосистема и ухудшается на каждом этапе.

потому что есть сборщик мусора

Он ещё на лиспе был. Почему-то не пишут корпоративный документооборот на лиспе. Наверное, всё-таки дело не в нём.

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

Это опять про аскезу. Впрочем, к мультиядерным процессорам аналогично. Столяров эти вещи отрицает не потому, что вредно, а потому что «нет необходимости».

Придётся. С другого сайта. Да, понимаю, зависимости могут бесить и вообще протухнуть, но и средства их хостить у себя не у всех имеются. Вопрос размера.

Если их всё равно надо скачать для компиляции, значит место под них есть. Ведь компилятор прямо из Сети файл не возьмёт Зачем их удалять после компиляции?

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

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

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

На смартфонах так и есть. Всем удобно.

Или, наоборот, тебе как разработчику сервиса непременно надо было бы наплодить вариантов для разных ОС и аппаратных платформ.

Когда-то для этого придумали Java. Но потом что-то пошло не так и Java ушла на сервера, а пользователям вместо этого сделали среду выполнения в браузере. И из-за этого для использования сервиса вроде yandex map приходится ставить неподконтрольную программу, которая есть больше ресурсов, чем все остальные программы вместе взятые. Если использовать браузер, который только браузер, типа NetSurf, то эти сервисы работать не будут.

Сейчас придумали докер. Но опять что-то идёт не так.

В жизни на практике чаще нужно, чтобы программа смогла хоть как-то что-то сделать

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

Или надо отказываться от крупных библиотек и задач для которых они нужны.

Крупные библиотеки должны идти с гарантией работоспособности. Примерно такой: https://cr.yp.to/qmail/guarantee.html, но не про безопасность, а про соответствие заявленной функциональности.

Зато в GEdit работает Ctrl-Shift-U даже под Windows, что гораздо лучше альт-кодов.

Хуже отсутствием единообразия.

Есть ссылка на решение суда или хотя бы номер дела? Крайне интересна аргументация судьи.

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

Практически одинаково. Так делишь на интерфейс демон. Как mpc + mpd. В пределе они даже на разных языках могут быть.

Я не сомневаюсь, что можно, я о том как удобнее. Можно вообще сделать микросервисы. Да и async wait бывает, что прячут под капот.

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

Жуть не жуть, но многоядерные процессоры для сотен процессов по-любому нужны.

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

См. выше. Отдельное ядро не обязательно, я о том, что ускоряется вообще обработка пока I/O происходит

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

Такую, что повторюсь, Столяров, а за ним и ты делаете логическую ошибку, считая некий средний за 24/7 процент загрузки системы. А считать надо скорость исполнения задач пользователя. На одном ядре у меня программа компилируется полчаса, на 12 ядрах с make -j 12 - 3 минуты. Вот это и есть разница! На одном ядре fps в игре (ещё не всякая игра запустится) 10 fps, на 8 ядрах - 50 fps. Видеостриминг в видеоконференции в Zoom или аналоге на одном ядре заткнётся, на 8 ядрах спокойно тянет несколько человек. И тд. И тп. А не суперсофт для физических экспериментов.

Про скорость открытия гаража, то есть, разницу между ожиданием I/O и скоростью обработки данных, я выше уже кидал сравнение линейной скорости чтения. Она на топовых, но всё же даже консьюмерских SSD всего в 2-5 раз меньше скорости чтения из RAM.

Вылазьте со Столяровым из под коряги! Со времён Core2 Duo уже почти 20 лет прошло. Рассуждения в 2026-м году про удивительную малополезность и тем более дебильность многоядерных процессоров - это бред.

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

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

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

Хотя вру. Есть TeX и qmail. Но эти обе программы написаны по заветам Столярова (без внешних зависимостей кроме операционной системы).

На одну такую программу 1000 без его заветов. И не потому что дураки, а потому что часто сложность намного выше.

Он ещё на лиспе был. Почему-то не пишут корпоративный документооборот на лиспе. Наверное, всё-таки дело не в нём.

Дело не в нём, но порог вхождения и надёжность повышается от того, что не надо дрочиться с управлением памятью. Так-то утечку памяти и у Самого в его Талассе нашли с поплпинка на LOR и потыкали в неё. Он банально после проверки условия и возврата из функции забыл, что надо перед return очистить выделенную в функции память. Качественный софт.

Это опять про аскезу. Впрочем, к мультиядерным процессорам аналогично. Столяров эти вещи отрицает не потому, что вредно, а потому что «нет необходимости».

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

Если их всё равно надо скачать для компиляции, значит место под них есть. Ведь компилятор прямо из Сети файл не возьмёт Зачем их удалять после компиляции?

Локально незачем. Но чтобы распространять свой проект, по Столярову, придётся и все внешние фреймворки распространять сколько бы они ГБ не заняли.

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

Ну и пусть сам аскетстствует. Но не надо его аскезу выдавать за правильный архитектурный подход.

На смартфонах так и есть. Всем удобно.

Можно и из браузера. На смартфонах.

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

Крупные библиотеки должны идти с гарантией работоспособности. Примерно такой: https://cr.yp.to/qmail/guarantee.html, но не про безопасность, а про соответствие заявленной функциональности.

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

Конечно, это не значит, что правильно всё говнять, но и мало кто мало для чего готов реально устраивать аскезу и тщательно вылизывать софт. Вот чего Столяров не поймёт ещё. И не потому что, те кто не готов «дебилы» или даже «мрази», а потому что у них другие интересы. Им интересно не qmail вылизать, а например, проект вроде Typealike запилить, в котором видеокамера распознаёт жесты рук и позволяет управлять компьютером. По Столярову такой софт никогда не будет написан или лет за 20 с его подходом и требованиями.

требовать ограниченной поддержки Unicode - маразм. То есть, например, по Столярову недопустимо уметь работать с текстами в utf-16? O_o

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

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

А вот тут автор как раз и пишет как это можно реализовать без всяких потоков.

А всякие компиляции — это многопроцессность, а не многопоточность. Ничего не мешает так же делать и в приложениях, делить их на процессы, а не потоки.

Обучающийся подготовится к выпускным экзаменам по ИКТ

А сможет он потом нормально программировать на других языках, хотя бы паскале/fpc или придётся переучиваться?

Жуть не жуть, но многоядерные процессоры для сотен процессов по-любому нужны.

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

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

И распухание требования ПО, думаю, для этого же.

На одном ядре fps в игре (ещё не всякая игра запустится) 10 fps, на 8 ядрах - 50 fps.

Там видеокарта важна, а не процессор.

Со времён Core2 Duo уже почти 20 лет прошло.

Реально все потребности пользователей были закрыты ещё пентиумом 3. Дальше некоторое время была безумная реклама про то, как «новый процессор ускоряет Интернет», а потом просто начали пихать алгоритмы Шлемиэля во все поля. Современная игра по воспринимаемому качеству почти такая же, как 20-летней давности, но требует новый процессор «а то не запустится». Про отрисовку клавиатуры, требующую ресурсов как хорошая ОС, я уже писал.

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

А если всё же хочется, то готовьте очень толстые кошельки.

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

На одну такую программу 1000 без его заветов. И не потому что дураки, а потому что часто сложность намного выше.

Если есть надёжные компоненты, сложность не проблема. Но предпочитают делать на авось. И поэтому спроса на надёжные компоненты нет (кому нужен надёжный daemontools, если есть модный systemd c QR-кодом и веб-сервером).

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

Тут соглашусь. Лично для меня любой язык с UB приемлем только если требования скорости принципиально не позволяют использовать Java.

Так-то утечку памяти

Утечку можно и в Java легко сделать. Достаточно складывать объект в какой-нибудь хеш и забыть его оттуда удалить. В Си опаснее порча памяти.

Качественный софт.

Столяров больше теоретик. Если нужны практики с такими же взглядами, то Кнут, https://cr.yp.to/djb.html, https://suckless.org/.

Столяров просто фриком уже выглядит за пределами темы обучения новичков программированию

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

Можно и из браузера. На смартфонах.

Если разработчик страницы соизволил. Иначе ползаешь по сайту как муравей по слону. А если сервис ещё и правую кнопку мышки использует, то вообще труба.

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

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

всёж стоит полистать(достаточно даже первые страницы) Хенеси_Патерсона 2026(27)г редакция по ахертектуре нонешних компов(качественный подход) - многоядерность обусловленна в частности что интеграция продолжается (не так муровски но всёж) а частоты упёрлись в материал (частоты можно и в ренгеновские докрутить тока там совсем другие обвесы потребны и пока? экономика не срастается - возможно(моя имха) если датаценты запулять в орбиты округ солнца там и частоты смогут до десятков гигагерц(если это ваще понадобится) ) - крч Хенеси_Патерсон качественный подход - очень вменяемо базу декларируют

Реально все потребности пользователей были закрыты ещё пентиумом 3

Обратись к доктору, пока не поздно.

Видел этот тред на 27-ми страницах.

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

Столяров ходит на такие сайты через ффокс 76 или palemoon, он же писал

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

Видел этот тред на 27-ми страницах.

Но их же 14

Хуже отсутствием единообразия.

Ладно, а какие ты символы вводишь через эти несчастные альт-коды? Почти всё доступно с клавиатуры. Контрол-коды вводятся через Ctrl-V Ctrl-Letter например.

  │ .0 .1 .2 .3 .4 .5 .6 .7 .8 .9 .A .B .C .D .E .F
──┼────────────────────────────────────────────────
0.│ ^@ ^A ^B ^C ^D ^E ^F ^G ^H ^I ^J ^K ^L ^M ^N ^O
1.│ ^P ^Q ^R ^S ^T ^U ^V ^W ^X ^Y ^Z ^[ ^\ ^] ^^ ^_
2.│     !  "  #  $  %  &  '  (  )  *  +  ,  -  .  /
3.│  0  1  2  3  4  5  6  7  8  9  :  ;  <  =  >  ?
4.│  @  A  B  C  D  E  F  G  H  I  J  K  L  M  N  O
5.│  P  Q  R  S  T  U  V  W  X  Y  Z  [  \  ]  ^  _
6.│  `  a  b  c  d  e  f  g  h  i  j  k  l  m  n  o
7.│  p  q  r  s  t  u  v  w  x  y  z  {  |  }  ~ ^?
8.│  Ђ  Ѓ  ‚  ѓ  „  …  †  ‡  €  ‰  Љ  ‹  Њ  Ќ  Ћ  Џ
9.│  ђ  ‘  ’  “  ”  •  –  —  �  ™  љ  ›  њ  ќ  ћ  џ
A.│ NBS Ў  ў  Ј  ¤  Ґ  ¦  §  Ё  ©  Є  «  ¬ SHY ®  Ї
B.│  °  ±  І  і  ґ  µ  ¶  ·  ё  №  є  »  ј  Ѕ  ѕ  ї
C.│  А  Б  В  Г  Д  Е  Ж  З  И  Й  К  Л  М  Н  О  П
D.│  Р  С  Т  У  Ф  Х  Ц  Ч  Ш  Щ  Ъ  Ы  Ь  Э  Ю  Я
E.│  а  б  в  г  д  е  ж  з  и  й  к  л  м  н  о  п
F.│  р  с  т  у  ф  х  ц  ч  ш  щ  ъ  ы  ь  э  ю  я

если по 1к месаг итого меньшее

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

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

Ладно, а какие ты символы вводишь через эти несчастные альт-коды?

« » – — 

Контрол-коды вводятся через Ctrl-V Ctrl-Letter например.

Ctrl-V = вставить из буфера.

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

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

А в компьютерных технологиях сплошь и рядом. Сначала из Emacs сделали ОС. Потом из Java серверный язык программирования. Теперь из браузера ОС делают с JavaScript в качестве ассемблера. Шифрование для обеспечения целостности сообщений (вместо подписи). Версионирование символом динамической библиотеки (вместо имени файла). Передача бинарных файлов через протокол передачи гипертекста или протокол удалённого управления (вместо протокола передачи файлов).

эффект безбилетника

паразитический payload

это всё очень биологично

почему в этой области настойчиво используют инструменты не по назначению

из хакерского интереса

Версионирование символом динамической библиотеки (вместо имени файла).

собственного имени файла может и не быть

из хакерского интереса

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

собственного имени файла может и не быть

Это как? У динамической библиотеки всегда есть имя файла.

Для Windows есть kbdasm (статья на хабре) по мощности почти эквивалентный Compose Key в полноценных ОС. Кроме того позволяет переключать раскладку CapsLock без установки дополнительного ПО.

Есть. Ради программы на Gtk системную раскладку клавиатуры ломать? По-моему, перебор.

P. S. Обход, конечно, есть: на уровне приложения отлавливать нажатие/отпускание Alt, но логичнее эту функцию выносить на уровень текстового виджета.

По-моему в некоторых версиях Gtk этот kbdasm всё равно не работает. Но ты проверь. И ломать не надо, просто копируешь в system32 и прописываешь в реестре, а потом выбираешь.

И ломать не надо, просто копируешь в system32 и прописываешь в реестре, а потом выбираешь.

Это и есть ломать. Для каждой программы/библиотеки по системной раскладке делать.

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

Я про подход. Передаёшь пользователю программу и инструкцию, как заменить раскладку.

Впрочем, у людей принято ради программы всю ОС менять, докер называется…

Ну см

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

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

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

Я был уверен, что libc и gtk придётся подкладывать.

Разработчики GNU libc специально поддерживают обратную двоичную совместимость. Это значит, что любая программа, слинкованная с libc определённой версии должна компоноваться и работать с любой более поздней версией libc.

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

Всё дело в том, что есть разные юрисдикции и есть даже такие, в которых в любых соглашениях обязаны быть прописаны компенсации. Потому, как я слышал, у M$ нашлось 2 варианта для обоих случаев, в случае без денежных гарантий она прописывала возврат денег за покупку, а в случае обязательной компенсации за порчу она прописывала денежную компенсацию в размере… $5.

Я даже когда-то (лет 35 назад) читал эти лицензии и ставил галочку «Согласен».

Так что у вас есть шикарная возможность получить за порчу данных на много-много денег в заявительном порядке компенсацию от M$ в размере $5.

Ты говорил, что это всё бесполезно, я опроверг.

Не-а, я говорил, что бесполезно то введение, что было по ссылке.

на самом деле это не настолько существенно

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

паскалефанбоями

Если вы внимательно посмотрите на предложенный ранее вводный курс от MIT, то поймёте, что в нём можно для иллюстраций взять любой ЯП «общего» назначения, поскольку после этого курса всё равно ни на одном ЯП программировать не сможешь. После столяровкого первого тома сможешь программировать на Паскале, а после второго – на Си.

Причём с половины первого тома можно начать параллельно изучать программирование на том же Питоне именно как программирование на Питоне. Или на Луа или даже Go, Пёрле или Котлине, Аде.

Единственная разумная альтернатива Паскалю в качестве иллюстративного ЯП при введении в программирование для будущих программистов не исключительно в web – это блок-схемы плюс ассемблер для базовой базы, а потом Си с переходом к С++.

программирование на том же Питоне

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

Не надо людей с улицы программированию учить.

Не-а, я говорил, что бесполезно то введение, что было по ссылке.

Опровергнуто, в любом случае.

Это существенно

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

что в нём можно для иллюстраций взять любой ЯП «общего» назначения

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

После столяровкого первого тома сможешь программировать на Паскале, а после второго – на Си.

Нет, не сможешь. Особенно это видно по @Xenius.

Единственная разумная альтернатива Паскалю… блок-схемы плюс ассемблер

Да ты же наглухо отбитый!

Это значит, что любая программа, слинкованная с libc определённой версии должна компоноваться и работать с любой более поздней версией libc.

Существует как минимум два контрпримера. qmail, слинкованный с libc-2.2, не работает с libc-2.3 и более поздними (нет символа errno). Программы, слинкованные с libc-2.12.1 (и хорошо с ним работающие), работают, но жутко глючат с libc-2.12.90 и выше.

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

Так что у вас есть шикарная возможность получить за порчу данных на много-много денег в заявительном порядке компенсацию от M$ в размере $5.

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

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

Поэтому обычно требуют вернуть деньги за некачественную программу (это доказать намного проще).

qmail, слинкованный с libc-2.2, не работает с libc-2.3 и более поздними (нет символа errno).

Это чуваки грубо нарушили самые базовые правила программирования и вместо glibc’ишного <errno.h> самостоятельно определили библиотечные символы.

работают, но жутко глючат

Это вообще классика с обосравшимся Торвальдсом - неправильное использование memcpy / memmove.

То есть, во всех этих случаях разрабы сами облажались.

Это чуваки грубо нарушили самые базовые правила программирования и вместо glibc’ишного <errno.h> самостоятельно определили библиотечные символы.

Так в старой версии был этот символ

https://github.com/gnutools/glibc/blob/5107cf1d7d27f17c6de68ec15a8e8d9dd5b471c1/include/errno.h#L47

В новой удалили. Поэтому если собрать со старой, а потом предоставить новую, работать не будет.

Это вообще классика с обосравшимся Торвальдсом - неправильное использование memcpy / memmove.

В старой работало? Работало. Обновление библиотеки сломало работающую программу? Сломало. Значит совместимости со старым поведением нет. Обе библиотеки соответствуют задекларированному API, но работают по-разному.