Эрик Реймонд: проприетарщине конец

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

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

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

Крайне слабо верю в серьёзную разработку на пАскале.

Прежде чем такое утверждать, надо сначала определиться с критериями «серьезности». Ибо прикладной софт на Паскале писать и поддерживать проще чем на Си. Лично видел немало всего написанного на разных версиях борландовского Паскаля.

Тут надо смотреть глубже – сейчас меняется сама концепция взаимодействия с компом. Нафиг какие-то анахронизмы в виде древних программ? Кому надо будет их ломать и переписывать? Разве что джастфофан. Я сейчас работаю в графических программах и ощущаю себя в роли какого-то прядильщика или кузнеца. Прямо чувствую, что это ветхие технологии. Увы. Эпоха фотошопов стремительно сменяется другой эпохой. Даже мемасики уже не делают в фотошопе.

Да. Место приложений массово займут AI агенты: https://venturebeat.com/ai/the-great-software-rewiring-ai-isnt-just-eating-everything-it-is-everything

Удручает то, что практически все доступные простым смертным AI-агенты - это по своей сути программы с закрытым исходным кодом (либо и вовсе онлайн сервисы).

А чем например deepseek harness недоступен простым смертным?

не тот отчёт отправишь. В здравом уме так рисковать никто не захочет.

Бизнеса без риска - не бывает. И «оптимизация налогов» - любимое занятие бизнесменов чуть ли не во всём мире. Для этого они в том числе и целенаправленно присылают правильно сделанные «не те» отчёты.

Вся эта шиза реально опасна для софтовых компаний

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

сделает в одно рыло фотошоп по мотивам, и начнет продавать за копейки.

В настоящее время «необходимость» фотошопа держится только на привычках пользователей, сидящих на нем не первый десяток лет. Им проще купить фотошоп чем затратить силы и время на переучивание на что-нибудь другое. Это тоже самое как виндовым пользователям трудно пересесть на линукс, и, совершенно внезапно, тем кто просидел на линуксе много лет - трудно адаптироваться к виндам если возникает надобность использовать их например на работе из-за отсутствия нужного прикладного софта под линукс (или упёртости начальства).

А есть люди, которым нужен реверс проприетарщины без перспектив поддержки?

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

А чем например deepseek harness недоступен простым смертным?

Agent harness - это лишь обвязка для БЯМ, инфраструктура для взаимодействия этой модели с внешними утилитами и пользователями. В вопросе открытости кода ключевую роль играет и открытость самой модели:

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

Нужной же обработки переводов строк в именах нет

А кто их туда может запихать? Нет, я понимаю, что чисто технически это возможно, но по-моему ни один вменяемый человек не станет это делать.

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

нанять тех кто будет поддерживать

Стоп, тут же ТС считает что ИИ сам сделает красиво

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

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

от привычек именования файлов его юзера.

А что, существуют юзеры которые привыкли запихивать переводы строки в имена файлов? По-моему это имеет смысл трактовать как ошибку и просить файлы переименовать в нормальный вид.

ТС считает что ИИ сам сделает красиво

Сделать-то он сделает, а кто потому будет сделанное поддерживать? Например если надо будет что-то в софте адаптировать под новые или изменившиеся старые надобности заказчика. Не ИИ же будет с представителем заказчика обсуждать что и как менять.

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

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

за ресурсы вздрючат

Нагенерить можно, не отличишь. А то и лучше будет. Чай не Герои2.

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

Ты бы сначала попробовал чего нагенерить чтобы оно на готовый скелет натянулось без артифактов.

Ты задом наперёд что ли читаешь? Я наоборот пишу что так нельзя делать.

«ваши файлы содержат переводы строк, а я не осилил обработать эту ситуацию»

«ваши файлы содержат переводы строк, с высокой вероятностью это вызовет ошибки при их использовании системой. Вы уверены что хотите продолжить? Y/N».

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

То есть твой код вылетает от чиха влево-вправо?

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

Если копии, то за них засудят, а если не копии, то будут кривые.

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

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

ни про какую «систему» она писать не должна

Тем не менее как раз именно система скорее всего не сможет использовать файл обоев с сильно нестандартным именем.

речь была про файлы на компе общего назначения.

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

Какая ещё «система»? Кто файл обоев использует? WM? У него всегда название конкретное есть, вот если конкретный WM забагованный - пишешь «твой wm - хлам, не поддерживает переводы строки в именах файлов, так их ставить не буду». Никаких абстрактных «систем», виновник должен быть указан (либо ты сам, либо сторонняя прога от которой ты зависишь) и не надо пытаться выдать это за дефолтное и хорошее поведение.

Даже если что-то совпадёт «слишком» - за минуту делается патч, и ищи сиди дальше «слишком похожести» в миллионах полигонов одного и миллионах полигонов другого…

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

твой wm - хлам

Разных wm - много, их разных версий - еще больше. И я не могу заранее знать какой из них спотыкается на кривых именах файлов, а какой нет.

не надо пытаться выдать это за дефолтное и хорошее поведение.

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

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

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

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

Что ты несёшь? Юзер захотел поставить этот файл обоями, программа должна исполнить запрос. Юзер - главный, программа - исполнитель его указов и не более того. Можешь выдать варнинг или ошибку если заведомо знаешь что действие закончится неудачей, но причину неудачи надо корректно указывать (и это не «юзер, ты выбрал плохое имя», а «твой wm такое не умеет»).

Есть, конечно, этический и экономический моменты.

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

А бесполезное, потому что нафиг она нужна-то.

Во-во. Вы вон попробуйте-ка линукс отреверсить!

тебе всё равно придётся изучать каждый поддерживаемый wm

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

«юзер, ты выбрал плохое имя»

Вообще-то достаточно общепринято предупреждать юзера о потенциально некорректных/опасных действиях. Запрос «вы уверены что хотите сделать именно это» - очень распространенная практика. Файловые менеджеры обычно просят подтвердить удаление файлов, mc так вообще красную табличку посреди своего окна выводит. А например APT в Дебиане в случае действий которыми юзер может поломать систему вообще просит набрать на клавиатуре что-то типа «делай как я сказал»(по-английски конечно). Вот и тут надо предупреждать юзера о том что он выбрал плохое имя для файла.

Если система (ядро или libc) сами не проверяют имена файлов на использование потенциально опасных символов то это придется делать в прикладных программах.

предупреждать юзера о том что он выбрал плохое имя для файла.

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

Если система (ядро или libc) сами не проверяют имена файлов на использование потенциально опасных символов

Ещё чего не хватало. Авторы ядра как раз осознанно задали список разрешённых байтов в имени - всё кроме '/' и 0. Софт, авторы которого об этом не в курсе - глючный и плохой. Никто, кроме авторов глючного софта, в этом не виноват.

Кстати, вспомнилась история. Компилировал я sendmail, скачал его исходники в директорию dnl/ (от download), запускаю компиляцию, а она падает с какими-то левыми синтаксическими ошибками. Я лазил в их лапше, пытаясь понять что ему не так (учитвая что m4 я не знаю, это было мучительно). В итоге оказалось, что в языке m4, на котором написан её сборочный скрипт, «dnl» означает начало комментария (как решётка в шелл-скриптах), и, вследствие то ли убогости m4, то ли багов в build-скрипте, это dnl из названия директории парсилось синтаксическим анализатором m4 в тех местах где название директории использовалось (оно вроде применило realpath т.е. абсолютный путь везде был хотя я его явно не передавал), и всё портило.

Ну как кто, пользователь. Немного другое, но недавно сталкивался с реальной ситуацией. В БД для столбца с ФИО было установлено ограничение на пустое значение (NOT NULL). Обломавшись на нем, кто-то стал писать туда строку ‘null’, из-за чего ломалась утилита копирования БД. Самое смешное, такие таланты были не только у нас - зарубежные пользователи тоже поймали этот баг.

Ну и знаки препинания вполне себе встречались в именах схем, таблиц и столбцов реальных продуктовых БД. Что-то вроде «My.Schema».«cOOl!Table».«Column.2».

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

В именах таблиц кстати тоже перевод строки может быть. И обратный апостроф.

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

Я летом достаточно позабавился с ловлей багов в pgcopydb с экранированием одинарных кавычек в строках. Тоже из той же серии.

А есть люди, которым нужен реверс проприетарщины без перспектив поддержки?

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

Хм, мне кажется это как раз те, кому нужна поддержка. Может быть, от другого вендора, но все-таки.

это не имя файла плохое

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

Авторы ядра как раз осознанно задали список разрешённых байтов в имени - всё кроме ‘/’ и 0.

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

оказалось, что в языке m4, на котором написан её сборочный скрипт, «dnl» означает начало комментария

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

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

Да, это так. Тоже сталкивался с мусором в базах данных, а уж в именах файлов тем более.

Не просто так циркуляр Морского технического комитета Российской Империи N15 от 29 ноября 1910 г. гласил:

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

это как раз те, кому нужна поддержка.

Так в любом случае софт реверсить надо.

Ну недодумали к чему это может привести.

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

У тебя подход как у микрософта, держать юзера за идиота и оберегать его от «неправильных» идей. Осуждаю.

Вы еще бэкспейс предложите в имя файла запихать.

Почему бы и нет? Ну, я так файлы не называю, но ломаться от этого ничего не должно.

И подумайте как потом это имя вводить в хоть какой-нибудь программе.

touch `printf '\b'`

Вообще кстати странно, mc не даёт через Ctrl+Q backspace в имя ввести (а вот перевод строки даёт).

Но это не важно, юзер хочет значит надо.

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

Фотошоп только в качестве примера. Можно что угодно скопировать, любой коммерческий софт. И я тот ещё слоупок, уже оказывается нагенерили несколько фотошопов. Хоть оно и сырое всё пока, но кажется полярная лиса для коммерсов уже в пути. Жду, когда корпы побегут запрещать страшный ужасный ИИ васянам. Чтобы спасти человечество, ага.

юзер хочет значит надо.

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

Спецификации линуксовых файловых систем писались явно не раньше чем в 90-е

В то время линукс вообще никто не рассматривал всерьез, а только лишь как поделку для развлечения немногочисленных тогда IT-энтузиастов (не хочу употреблять слово «хакеры» так как оно сейчас имеет криминальный оттенок)

я так файлы не называю

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

ломаться от этого ничего не должно.

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

решили что не надо вводить глупых ограничений.

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

И подумайте как потом это имя вводить в хоть какой-нибудь программе.

touch printf '\b'

Я сказал «в программе», а не в командной строке. Как например сохранить файл с таким именем из любого редактора с GUI? Даже если найдется такой который позволит ввести в диалог сохранения \b (в чем я не уверен) - то пользователь с очень высокой вероятностью не знает как это сделать. Про тот же mc например я знаю что «как-то» спецсимволы там вводить можно но без заглядывания в ман не скажу как.

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

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

Вот именно - потому что вы понимаете чем это грозит

Это ничем в целом не грозит. Но я просто не вижу надобности.

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

Например производители самолётов только и делают что впихивают в них всё больше разных защит от неправильных действий пилотов.

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

Жду, когда корпы побегут запрещать страшный ужасный ИИ

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

кажется полярная лиса для коммерсов уже в пути.

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

Это ничем в целом не грозит.

А я не раз за 35 лет работы с компами убеждался что таки грозит.

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

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

пилоты самолётом не владеют

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

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

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

заявил в одной известной соцсеточке

Где ссылка?