Комментарии 1135
Зачем нужен состав на этикетке продукта? Что бы знать что ты употребляешь в пищу. Мы можем его не прочитать, но найдется служба которая занимается контролем за этим процессом, что бы мы были уверены в своей еде.
Так же и с программами, не всем надо знать как они работают, но лучше иметь доступ к составу, иначе производитель может подмешать разной химии.
Пользователи windows и macos принципиально отличаются от пользователей linux
снобизм всегда был отличительной чертой линуксоидов. Но зачем же так прямо об этом заявлять
Программы невозможно изучить, изменить или доработать
плагины для экселя или ворда (в том числе платные) , трейнеры, читы, моды для игорей
Видимо это все не то
И так далее. На любой тезис из вашего поста, можно найти 100 аргументов его опровергающих
В общем, мне кажется Вам надо было с тем коллегой поговорит, чтоб уж совсем ерунду не писать
снобизм всегда был отличительной чертой линуксоидов. Но зачем же так прямо об этом заявлять
Дворянство, как правило, было граммотнее. Это отличало их от крестьян. Ключевой вопрос - на что знание в конечном итоге будет направлено.
плагины для экселя или ворда (в том числе платные) , трейнеры, читы, моды для игорей
Да, windows и macos и правда позволяют сделать данные доработки. Но фундаментальные изменения в системе позволяет делать только линукс.
причем тут дворянство?
фундаментальные изменения в ОС делают люди, которые пишут ОС. Обычный человек этим не занимается
Да и не сделать сейчас фундаментальных изменений. Сфера ОС по сути тоже стандартизирована. По пальцам посчитать направления типа x86. А интерфейс как был оконным, так и везде будет. Пока напрямую в мозг не начнут транслировать
А если по мелочи? ну так я в винде в реестр изменения вносил, чтобы настроить у ноута турбобуст
Было бы хорошо, если бы к тому моменту когда взаимодействие с операционной системой начнет напрямую транслироваться в мозг, что бы у пользователей была максимальная степень контроля над программами которые они используют.
В случае с macos и microsoft контроль над программами отдается на аутсорс, в то время как с линуксом есть возможность коллективного контроля.
такая возможность есть только в теории. А в реальности этим контролем занимается маинтейнер пакета и еще человека два-три, разбирающихся в происходящем, и не более. Есть огромнейшая разница между "теоретической возможностью" контроля и практической реализацией в существующем мире.
Очень зависит от пакета. У многих пакетов есть десятки контрибьюторов. И у них есть возможность публично высказываться о найденных проблемах. Если работник Microsoft нашел проблему, он не имеет права без согласования с начальством рассказать об этом всему миру.
И это принципиальное преимущество.
Молодости присущ максимализм/категоризм. Потому и "дворянство", и контроль пакетов, и другие фантазии.
Всячески поддерживаю автора с его юношеским пылом ! Пусть дерзает. Ну а жизнь сама все по местам расставит.
Насколько мне известно у детей современности проблемы с компьютерной грамотностью есть и похуже, т.к. их основное устройство это смартфон и многие из них даже концепцию файла и директории не совсем понимают.
Но это всё далеко не главное, самое жуткое — огромное количество информации в которую погружены дети с рождения. Перегруз по учёбе, тонны игр и развлекательного контента, агрессивная реклама, тиктоки\ютубчики, порнуха, многочисленные соцсетки и чаты, шумовое и визуальное загрязнение в городах. Вот это всё, вероятно, серьёзно сказывается на формировании мышления и способности оперировать с информацией.
порнуха
Вот на святое то не надо позаряться. ИМХО для подростка оно скорее будет во благо, чем во вред.
Перегруз по учёбе
Думаю, с этого и стоит начинать. Всё остальное [должны быть] в состоянии проконтролировать родители.
шумовое и визуальное загрязнение в городах
А это не только на детей влияет. Мне, как человеку, прожившему первые 20 лет вдали от цивилизации, а потом переехав в крупный город, очень знакомо всё это.
Вред порнухи очень недооценён. Некоторые призывают приравнять её аддиктивность и вред к наркотической зависимости.
Если кратко, стимулы однозначно обозначающие готовность к совокуплению у нас как у биологического вида, одни из самых сильных в жизни. Награда (оргазм) так же по силе удовольствия это одно из самых ярких и сильных эйфорических переживаний. Таковым нас сделал естественный отбор. Человек же в ходе прогресса научился эти символы экстрагировать, отделять от биологического партнёра.
Если их потребление не контролировать и потреблять в количествах сколько хочется то со временем наступает два, знакомых любому наркоману со стажем последствия:
1) Истощение
2) Появление толерантности
Пообщайтесь с заядлыми любителями порнухи на тему их потенции и влечения (а за одно жизненных амбиций и волевых качеств).
Я не из моралистов и сам смотрел, но кардинально пересмотрел отношение к ней со временем.
С одной стороны, всё это похоже на правду.
С другой стороны, лучше уж порнуха чем наркота или алкоголь. По крайней мере, я ни разу не слышал о бытовой поножовщине на почве просмотра порно...
Лучше, пожалуй, это ЗОЖ. Коварство порнухи в её однокликовой доступности, сейчас имея смартфон даже из под одеяла не нужно вылезать.
Наличие одной зависимости не отменяет другую, чаще всего они идут букетом...
Отлично, осталось обеспечить каждый одинокий личный кошка-жена или -муж.
Назначаетесь ответсвенным по этому вопросу.
Если через год не будет значительного улучшения показателей — расстрел.
Так порнозависимость делает человека нечувствительным к биологическому партнёру, у него там такая толерантность и планка насмотренности задрана до небес на тысячах лучших тел лучших представителей его вида.
А с кошкоженой\собакомужем нужно учитывать сотни факторов, находить индивидуальный подход, договариваться и так далее.
Так порнозависимость делает человека нечувствительным к биологическому партнёру
Ого, то есть, это не нечувствительность к биологическому партнеру приводит к необходимости сублимации через порно, тем самым формируя и закрепляя зависимость, а наоборот?
У вас телега впереди паровоза.
Отчего же. Есть мощная биологически обусловленная потребность. Есть путь реализации софтварный: быстрый, лишенный поведенческих рисков, беслатный, сверхстимулирующий — порно.
Есть старый, тёплый, ламповый и аналоговый — знакомиться и развивать отношения. А это всевозможные риски, негарантированный да еще и отложенный результат. Сплошные сложности, необходимость обучаться, рисковать.
Аналогия с наркотиками прямая. Либо достижения в реальной жизни и "природное" удовольствие от них. Либо прямая стимуляция рецепторов, со всеми печальными отдалёнными последствиями.
старый, тёплый, ламповый и аналоговый
это набежать и изнасиловать.
Ваш кэп.
Аналогия ваша — котенок с дверцей. Biased is not based.
Есть путь реализации софтварный: быстрый, лишенный поведенческих рисков, беслатный, сверхстимулирующийОн еще и не менее старый и ламповый.
Пообщайтесь с заядлыми любителями порнухи на тему их потенции и влечения (а за одно жизненных амбиций и волевых качеств).
Ну вот я заядлый любитель порнухи. Сейчас мне далеко за сорок, но любви и внимания как хотелось каждый день, так и хочется. Вот только супруге уже лень, к сожалению. Сколько мне надо порнухи ещё пересмотреть, чтобы потенция испортилась, волевые качества и жизненные амбиции завяли, и наконец в моей семье наступила бы гармония?
Вред порнухи придуман теми же шизиками, что и вред мультиков, компьютерных игр, а ранее кино и радио, а еще ранее - книг, а еще раньше - хз, что там в Риме с Грецией вредным объявляли. Т.е. все это манипуляции и шиза.
Ключевой вопрос - на что знание в конечном итоге будет направлено.
Очень правильная мысль. Можно направить его на устройство ОС, а можно - на решение прикладных задач.
Устройство ОС - тоже прикладная задача. Конечный инструмент пользователя должен хорошо выполнять его задачи, при этом не отнимая его права.
Прикладная задача это обычно то, за что платят деньги. Если человек работает разработчиком драйверов или разработчиков дистра, то ему за знание ОС деньги заплатят. А вот если уже разработчиком прикладного ПО, то ему за пересборку ядра линукса с уникальными рюшечками никто уже платить не будет, скорее всего.
Написание JS-фреймворков, компиляторов, дистрибутивов линукса, библиотек на разных языках - сложная работа. Наши программы, в большинстве случаев, базируются на фундаменте открытого ПО.
Для меня кажется естественным желание укрепить этот фундамент, даже если за это никто не заплатит.
Для меня кажется естественным желание укрепить этот фундамент, даже если за это никто не заплатит.
А когда вы жить планируете? Это я к тому, что с текущим уровнем абстракций никто не знает, как полностью работает компьютер.
В этом есть необходимость? Продолжать работать на своём уровне абстракций, постепенно расширяя границы фундамента свободных/открытых программ тоже хорошо.
Это хорошо, когда вы делаете это хорошо, а не когда вы просто делаете это. А механизмов отделить первое от второго в комьюнити просто нет. Я, например, не хочу расширения фундамента программ, у которых куча легаси-кода на С++, новый код на тайпскрипте под нодой, и ещё требуется пайтон. Потому что изначально писалась на плюсах, потом зашла пара современных мейнтейнеров, которые плохо знали плюсы, но хорошо знали тайпскрипт, и прикрутили его к старому ядру, а вон те три контрола, которые им понравились, были на пайтоне. Не надо их расширять, их надо хоронить. Но люди этим пользуются, потому что "жричодали" - основной принцип потребления софта юзерами, выбора-то нет. А раз пользуются, то эти обвешанные костылями монстры все равно развиваются.
А вы уверены что у вас хватит квалификации этот фундамент качественно укреплять?
И у вас есть на это время? Или вы готовы заниматься этим в свободное от работы время? Или у вас официально отводится сколько-то процентов времени на непроектные (технические) задачи?
Кроме того, любое изменение кода в любом мало-мальски серьезном проекте влечет за собой огромное количество регресс-тестов.
Иначе такое вмешательство чревато весьма интересными и далеко не всегда приятными последствиями.
Кроме того, если речь идет о каких-то изменениях я ядре ОС, то эти изменения должны делаться централизованно. Иначе следующее же обновление ядра ОС может вызвать конфликт.
А любое централизованное изменение должно быть согласовано с майнтенером.
А вы уверены что у вас хватит квалификации этот фундамент качественно укреплять?
Это должно решать сообщество. Мне не кажутся невозможным создание PR в открытые проекты, помощь в реализации уже существующих инструментов.
При этом даже направление квалификации не имеет значения, разные люди решают разные задачи.
И у вас есть на это время? Или вы готовы заниматься этим в свободное от работы время? Или у вас официально отводится сколько-то процентов времени на непроектные (технические) задачи?
Время есть.
Когда работал, занимался открытыми проектами в личное время (с чайком и музыкой по-вечерам).
Официально у меня не было возможности заниматься открытыми проектами, хотя на мой взгляд от 80% практически любой кодовой базы можно открывать (если функциональность хорошо разделена на компоненты).
Прикладная задача это в браузере хром серфить интернет
Я понимаю, что это некорректно, но не могу удержаться: допустить орфографическую ошибку в слове "грамотнее" - это какой-то новый уровень.
Да, windows и macos и правда позволяют сделать данные доработки. Но фундаментальные изменения в системе позволяет делать только линукс.
порог вхождения в "фундаментальные изменения" в ОСи неприемлемо высок.
Смотря что рассматривать, как фундаментальные изменения. Я имел в виду возможность замены любых компонентов на пользовательской машине, вплоть до ядра системы.
Сколько людей в мире могут заменить ядро линукс на свое?
Поскольку в мире линукс собрать свои ядра принято у гентушников да LFS, то результирующая цифра будет стремиться к 100%. Потому что там где так принято — так делают практически все.
У остальных же гораздо актуальнее установка пакета со свежим или, наоборот, LTS ядром из того что есть в доступности. Как ни удивительно, но установка пакетов делается пакетным менеджером, в наше прогрессивное время уже четверть века как гуевым. Что автоматически дает опять близкую к 100% цифру.
Ваш кэп.
По первому абзацу вопросов нет, но среди "людей в мире" этих товарищей очень немного.
По второму - это именно что апдейт ядра до самого актуального из доступных для этой ветки. Это не "замена на своё". Понятно, что вокруг определения "своего" можно хороводы водить, но всё же предположу, что исходный вопрос подразумевал что-то, что лежит вне дефолтного репозитория дистрибутива.
То есть у людей использующих готовые пакеты - пакетное мышление? Пакетное мышление ставится в противовес коробочному мышлению?
Поскольку в мире линукс собрать свои ядра принято у гентушников да LFS, то результирующая цифра будет стремиться к 100%. Потому что там где так принято — так делают практически все.
Я так понял, что вы перепутали "сделать свое ядро" или "пересобрать уже готовое Линукс ядро даже не с собственными изменениями, а просто с другими параметрами, уже известными и документированными", например просто отключив/включив какие-то модули или драйвера в ядро.
А в винде это делать не нужно, потому что ядро не монолит с драйверами, и они просто устанавливаются или удаляются.
Да почему ж перепутал, когда вы высказались максимально неясно. Настолько, что если пытаться понять вас буквально, в лоб, то придется придти к самым неутешительным выводам…
потому что ядро не монолит с драйверами, и они просто устанавливаются или удаляются
Ви таки не поверите, но:
- отключать модули, в том числе вкомпилированные в ядро, давным-давно можно просто передав параметры ядру
- чтобы подключить произвольный модуль при старте системы, вроде модулей ФС, придумали initramfs. Тоже давным-давно
- модули, ВНЕЗАПНО, хранятся прямо в файловой системе, а не составляют одно целое с ядром
- модули легко и непринужденно загружаются и выгружаются прямо в рантайме
Ваши представления устарели на четверть века
Возможно, автор того комментария хотел пожаловаться на stable API для модулей в сервисы ядра и наоборот.
То есть вы просто включаете/отключаете что-то в ядре Линукса, а не заменяете ядро Линукса СВОИМ ядром, которое написали самостоятельно.
Так в чем собственно смысл? Отключить опции в реестре, или отключить опции при пересборке ядра? Второе звучит круче?
Значит, все-таки, неутешительные.
Ну, ожидаемо.
Disclaimer: я не топлю ни за Windows, ни за Linux. Каждому удобнее своё. Я просто попробую описать почему Linux для некоторых людей может быть удобнее.
У меня на днях был квест отключить Windows Defender. Комп достаточно слабый, он используется только для просмотра трех сайтов в Chrome, в антивирусе нет нужды. Я так и не осилил выполнение этого квеста. В инете много рекомендаций как это сделать через реестр, политики и т.д. Большая часть рекомендаций не работает. Как я понял, у части ключей в реестре владелец Trusted Installer и так просто эти ключи не изменишь. В гугле рекомендуют скачать стороннюю утилиту, которая позволяет запустить редактор реестра под этим пользователем. Вопрос на сколько этой утилите вообще можно доверять. В итоге я вроде что-то отключил, но только частично. Всё это выглядит как какое-то шаманство, штатной документации и штатных утилит на этот случай нет.
Дело не в крутости. Многие задачи в Linux решаются чтением документации, поиском подходящей утилиты, пусть и гуглением тоже. Если мне что-то не нужно, то я относительно легко могу это отключить или удалить. ОС не чинит мне искусственных препятствий.
Или, например, мне нужно найти все файлы по какому-то критерию, массово переименовать их, массово преобразовать svg в png с нужными параметрами и т.д. В Linux я ищу для этого подходящую утилиту, изучаю документацию. А в Windows в большинстве случаев ищу готовую программу, возможно проприетарную, возможно с рекламой, возможно с меньшими возможностями, возможно с не удобным ограниченным графическим интерфейсом, в котором ещё разобраться нужно.
В Linux унифицированный интерфейс для поиска и установки программ через пакетный менеджер, без визардов, без галочек "Установить до кучи ещё какой-нибудь браузер или антивирус". Унифицированный интерфейс у утилит (в виде командной строки), обычно с большим количеством возможностей, которые было бы сложно уложить в GUI. Унифицированная документация, которая одинаково открывается для большинства программ, одинаково оформлена. Относительно унифицированные конфиги, журналы работы и т.д., которые лежат в соответствующих каталогах и всегда знаешь где их найти. Для меня это банально удобнее.
Ещё мне последние версии Gnome визуально нравятся гораздо больше, чем интерфейс Windows. Но это очень субъективно, как и всё остальное перечисленное здесь.
Плюс, раз статья про образовательный процесс, то на мой взгляд всё это способствует приобретению знаний (по крайней мере для разработчиков и админов). Когда ты разбираешься с командами типа find, grep, sed, а не просто ищешь программу с GUI, которая решит узкую задачу, то явно обучаешься, узнаешь что-то новое.
Но, ещё раз, у меня такие запросы, поэтому мне это удобнее. У дизайнеров, например, другие запросы, им нужна куча специфических программ, которые есть только в MacOS. Другим людям нужны специфические программы, которые есть только под Windows.
Унифицированный интерфейс у утилит (в виде командной строки)
Вы просто не видели реально унифицированного интерфейса...
Где команда - это не какая-то программа с именем, которое ей придумал обкурившийся гик, а вполне внятная мнемоника типа:
CLRMSGQ - очистка очереди сообщений (что делаем - чистим - CLeaR, что чистим - очередь сообщений - MeSsaGe Queue)
или
WRKOBJLCK - WoRK with OBJect LoCKs
и т.п.
Все имена команд интуитивно понятны - WRK - работать с... DLT - удалить ... CRT - создать... и т.п.
И если вы ввели недостаточно параметров для команды, вам выведется формочка (текстовая) где будет предложено ввести недостающее
И тут вы увидите и параметры которые должны быть введены обязательно и дефолтные значения для необязательных параметров...
Ну и нет нужды писать командные строки в километр длиной
Где это так продумано?
IBM i (AS/400)
Но это вообще система, построенная на совершенно отличных от Win/*nix принципах. Там полностью другая идеология - это объектная ОС - там "все есть объект". У объекта есть имя, тип (из списка заранее определенных) и атрибуты (присущие данному типу). Тип и атрибуты задаются при создании объекта и не могут быть изменены.
С каждым объектом можно производить только те действия, которые определены для данного типа. Например, если в винде вы можете открыть файл .exe в hex редакторе и поправить там несколько байтиков (ну чтобы регистрацию не проверяла, например), то тут такое не пройдет - для объекта типа *PGM (программа) такая операция запрещена на уровне системы.
Там и файловая система своя - нет файлов, есть объекты (есть объект типа *FILE, но это просто один из типов объектов). Нет папок, есть библиотеки (библиотека тоже есть объект типа *LIB). Нет PATH как в винде, есть LIBL (Library List) который уникален для каждого задания (JOB - все, что делается в этой системе, делается в рамках какого-либо задания - запустили терминальную сессию - создалось новое задание, программу можете запустить прямо из терминала в том же задании, а можете запустить в новом фоновом задании командой SBMJOB - Submit Job) и может динамически изменяться командами ADDLIBLE (Add Library List Entry) или RMVLIBLE (Remove Library List Entry) по мере текущей необходимсти.
В общем, это совершенно другая система. Как писал Френк Солтис (один из отцов-основателей AS/400) во вступительной главе своей книги "Основы AS/400" (там много интересного как про историю ее создания, так и технических подробностей как она устроена внутри):
Я был в Буэнос-Айресе на встрече с группой пользователей этой системы. По окончании встречи молодой репортер газеты «La Nacion» спросил меня: «Сформулируйте, пожалуйста, коротко причины того, почему в AS/400 столь много новшеств?». И я ответил: «Потому что никто из ее создателей не заканчивал MIT.» Заинтригованный моим ответом, репортер попросил разъяснений. Я сказал, что не собирался критиковать MIT, а лишь имел в виду то, что разработчики AS/400 имели совершенно иной опыт, нежели выпускники MIT. Так как всегда было трудно заставить кого-либо переехать с восточного побережья в 70-тысячный миннесотский городок, в лаборатории IBM в Рочестере практически не оказалось выпускников университетов, расположенных на востоке США. И создатели AS/400 — представители «школ» Среднего Запада — не были так сильно привязаны к проектным решениям, используемым другими компаниями.
Если кому-то интересно - в сети есть достаточное количество ресурсов (гуглить IBM i, AS/400) по этой системе. Можно даже самому попробовать - есть публичный сервер PUB400 - можно зарегистрироваться бесплатно и поработать (все что для этого потребуется - эмулятор терминала IBM5250, он есть в составе бесплатного пакета Access Client Solutions от IBM).
Я к чему все это... А к тому, что когда слышу яростные холивары на тему Win-Linux, хочется спросить - "ребята, а вы что-то иное пробовали?". Просто потому что мир очень многообразен. И есть другие системы помимо этих. Да, специализированные, да малораспространенные. Но там могут быть заложены очень интересные концепции, принципы и решения, которые могут оказаться несравнимо удобнее того, что мы видим в винде или линуксе.
У меня вот сейчас два рабочих компа. Один под виндой, второй под линуксом. А пишу я сейчас под AS/400 (и, естественно, провожу много времени в терминале на сервере). А до этого жизнь сталкивала (правда, достаточно кратковременно) с QNX - это такая юникс-подобная система реального времени построенная на микроядерной архитектуре...
Например, если в винде вы можете открыть файл .exe в hex редакторе и поправить там несколько байтиков (ну чтобы регистрацию не проверяла, например), то тут такое не пройдет — для объекта типа *PGM (программа) такая операция запрещена на уровне системы.
Ужас какой… Ну то есть я понимаю что это может быть полезной фичей в отдельных сценариях. Но в контексте того как я пользуюсь компьютером это было бы катастрофой.
Это гарантирует устойчивость системы в целом.
Вообще, все это начиналось как платформа для серверов для малого и среднего бизнеса (middleware), для тех, кому мейнфреймы S/390 (сейчас это платформа IBM z) дороги и избыточны. Но получилось настолько удачно и масштабируемо, что теперь широко используется и в крупном бизнесе.
Там еще все очень изолировано. Есть, например, т.н. SLIC - System Licensed Internal Code. Это уровень ядра ОС. Туда нет доступа никому кроме разработчиков самой системы.
Там нет ассемблера. Т.е. он есть, но только на уровне SLIC. Обычным разработчикам недоступен. Для обычных разработчиков есть язык машинных инструкций (нечто среднее между ЯВУ и ассемблером). Причем, эти инструкции не зависят от конкретной машины (т.н. TIMI - Technology Independant Machine Instructions). Более того, компилятор (любой) там генерирует этот самый TIMI код который потом переводится в исполняемый, но при этом хранится в программном объекте наряду с исполняемым кодом для данного процессора. И если вы собрали программу и установили ее, скажем, на машину с Power8, исполняемый код будет оптимизирован под Power8. А потом переносите ее в виде программного объекта на Power9, система при первом запуске увидит что код сгенерирован под другой проц и по TIMI коде автоматически перегенерирует исполняемый код под Power9.
Там еще есть т.н. "уровни безопасности". На разных уровнях разные ограничения. Например, есть объекты в домене *SYSTEM и есть объекты в домене *USER. На уровнях безопасности до 30-го включительно вы можете работать с объектами в домене *SYSTEM на низком уровне - через машинные инструкции и системные указатели. А вот на 40-м и 50-м уровнях безопасности такое разрешается только с объектами в домене *USER... А в *SYSTEM вся работа с объектами только верхнеуровневая, через системные API.
Очень много всяких специфических типов объектов. Например, User Space (*USRSPC) - что-то типа memory mapped file. Некое персистнтеное хранилище на диске, на которое вы можете получить указатель и работать с ним как с областью памяти.
Или очереди. Данных (Data Queue - *DTAQ, User Queue - *USRQ) - что-то типа mailslot в винде, но мощнее кратно. Или очередь сообщений - Meaasge Queue, *MSGQ - очень удобно для вывода всяких трейсов при отладке. Программа работает, а вы можете смотреть чего она в очередь пишет в реальном времени.
Смотреть можно хоть скулем
select message_timestamp, from_job, message_text from qsys2.message_queue_info where msgq_lib = 'ALIBD09' and msgq_name = 'CPOSTATUS';
хоть в терминале (DSPMSGQ MSGQ(ALIBD09/CPOSTATUS)
Вообще очень мощная, надежная и устойчивая система с очень широкими возможностями.
Это гарантирует устойчивость системы в целом
Это может быть. Но какой смысл в устойчивой системе если она не даёт нормально работать?
Что значит "нормально работать"? Ковырять хексом исполняемый код не есть нормальная работа.
Здесь "нормальная работа" есть выполнение неких бизнес-задач с максмальной эффективностью.
И есть очень много средств, характерных именно для этой системы, которые позволяют эту максимальную эффективность получить. В том числе и для разработчика.
Ковырять хексом исполняемый код не есть нормальная работа.
Для вас может быть и нет. Для кого-то другого да.
Здесь "нормальная работа" есть выполнение неких бизнес-задач с максмальной эффективностью.
Ну так я же не отрицаю что такого подхода может быть своя ниша. Но мне такое точно не подойдёт. И подозреваю что я точно не один такой. Мягко говоря.
> Ковырять хексом исполняемый код не есть нормальная > работа.
Для вас может быть и нет. Для кого-то другого да.
По определению ковырять исполняемый код хексом - не есть нормальная работа. Потому что норма - это поведение большинства. А большинство пользователей ПК вообще не имеют представление о том что такое хекс.
Тогда и писать программы это не нормальная работа. Потому что большинство пользователей ПК этого не делают :)
Абсолютное большинство программистов, то есть нормально, пишут код в IDE на разных языках программирования. А исполняемый код хексом ковыряет абсолютное меньшинство =)
Ну так ваше "абсолютное большинство программистов" является явным меньшинством на фоне всех пользователей ПК. То есть любое программирование это уже не нормальная работа.
А если мы начинаем смотреть что является или не является нормальной работой для какой-то более узкой выборки, то почему вы считаете что именно "все программисты" это единственно допустимая выборка? И для каких-то "подразновидностей" программистов ковырять хексом исполняемый код будет вполне себе нормальной работой.
Ну так ваше "абсолютное большинство программистов" является явным меньшинством на фоне всех пользователей
Большинство пользователей ПК могут и не заниматься работой вообще. Давайте брать все-таки профессиональное использование.
Ну и если вы уж так хотите копнуть поглубже - расскажите общее название программиста, для которых ковыряние исполняемого файла хексом - нормальная работа.
Я таких не знаю.
Безопасники? Вряд ли, есть дебаггеры.
Те, кого 30 лет назад называли cracker, ломающие жизни и патроны в игрушках? Тоже устарело, сейчас есть всякие читенжин, что заменяет все эти хекс ковыряния.
Кто остается? Попов?
Давайте брать все-таки профессиональное использование.
И это ничего не изменит. Куча людей работает за компьютером и программисты однозначно не большинство таких людей.
Ну и если вы уж так хотите копнуть поглубже — расскажите общее название программиста
Зачем? Главное что они есть и для них это нормальная работа.
Для вас может быть и нет. Для кого-то другого да.
Можно пример такой работы за исключением реверс-инжиниринга? Гугол когда-то вставлял метки в PE-заголовки установщика Хрома, но это тоже хак и вряд ли кто-то редактировал их руками.
для объекта типа *PGM (программа) такая операция запрещена на уровне системы
Авторы Юникса считали это страшно неудобным и одной из их мотивацией как раз было сделать все ортогонально.
Не смог сходу найти цитату, там было что-то вроде "а вы можете пропустить результат работы компилятора Фортрана через форматировщик"?
Не смог сходу найти цитату, там было что-то вроде "а вы можете пропустить результат работы компилятора Фортрана через форматировщик"?
Не совсем понятно что имеется ввиду и зачем это может быть надо...
Авторы Юникса считали это страшно неудобным и одной из их мотивацией как раз было сделать все ортогонально.
Ну как бы юникс был раньше чем появилась АС-ка (в это году, кстати, ей 35 лет).
Вообще, я с ней 6 лет работаю и чем дальше тем больше нравится. И идеология и возможности для разработки...
Не совсем понятно что имеется ввиду
Возможно, там речь шла о листинге. В общем, им не нравились произвольные ограничения и они сделали файлы бесструктурным потоком байтов без всякого привязанного типа.
/Ну как бы юникс был раньше чем появилась АС-ка
Такие ограничения были типичны для доюниксовских систем и дожили до советского "Эльбруса" в виде разных типов файлов.
AS/400 в плане интерфейса четко следует традициям IBM. Мне ваш снимок экрана сразу напомнил VM/VMS.
В общем, им не нравились произвольные ограничения и они сделали файлы бесструктурным потоком байтов без всякого привязанного типа.
Тут как раз от этого ушли. И это не просто "разные типы файлов". Это разные типы объектов. Как в ООП. Каждый тип объекта обладает своим набором свойств и определенным набором действий над ним.
Более того, внутри там тоже все есть объект. И те же машинные инструкции оперируют тоже с объектами. Т.е. любая переменная в программе с точки зрения системы тоже объект с определенными свойствами и разрешенными операциями.
Например, внутри любой процедуры, если задать в ее определении соотв. опцию, на каждый параметр можно получить его т.н. "операционный дескриптор" в котором будет и тип объекта на который этот параметр ссылается и и его физически размер в памяти.
Например, передаете в С-шную функцию указатель на char, внутри получаете операционный дескриптор и видите физический размер буфера на который этот указатель ссылается.
Так что там все немного сложнее чем просто разные типы файлов.
Ну и безопасность - никакая вирусяка не сможет "встроится" в программу. Это просто запрещено на уровне системы.
хочется спросить - "ребята, а вы что-то иное пробовали?"
Очень верная мысль. Жаль, Лисп-машины умерли. Думаю, там было, чему поучиться.
Но там могут быть заложены очень интересные концепции, принципы и решения, которые могут оказаться несравнимо удобнее того, что мы видим в винде или линуксе.
Вот после командной строки 5250 а-ля WOP ASID144401 ZCMSMB0P я в упор не могу вспомнить там несравнимо более удобных концепций и решений, которые хотел бы видеть хоть на линуксе, хоть на винде.
Все имена команд интуитивно понятны - WRK - работать с... DLT - удалить ... CRT - создать... и т.п.
"- Что у нея... гм... у нея внутре за лэпэчэ... Лэпэчэ... Кэпэдэ, наверное? Что еще за лэпэчэ? - Лампочка, значит, - сказал старичок, хихикая и потирая руки. - Кодируем помаленьку."
А в винде это делать не нужно, потому что ядро не монолит с драйверами, и они просто устанавливаются или удаляются.
Вообще-то точно такое же монолитное ядро, с точно такими же драйверами-модулями, работающими в кернелспейс.
Для себя - пожалуйста, собирайте.
Но если речь идет о крупной компании, где от работоспособности центрального сервера зависит прибыль, измеряемая шести- и более значными числами... Никто вам просто так пересобрать ядро на боевом сервере не даст.
И дополню: сколько из них могут внятно объяснить, зачем они это делают?
*так-то я с матами и манами, пожалуй, сдюжил бы, но ни одной причины для этого не вижу
Сложность сборки ядра преувеличена. Если проявить минимальную аккуратность (например взять те же самые сорцы, что у дистрибного ядра и накатить ту же самую конфигурацию), то сборка и рабочесть гарантированы на 100%. Пожалуй, это наиболее просто заменяемый компонент дистрибутива, и во многом потому, что не зависит от других компонентов системы и апгрейд ядра не ломает юзерспейс примерно никак.
Теперь насчёт "зачем": ну например один раз я отлаживал неработающий сериальный порт. Начал с ядра (вставлял печать стектрейсов), дорыл до какого-то левого скрипта, который при старте системы зачем-то переписывал базовый адрес сериального порта.
Иногда нужна поддержка свежего железа, которое на дистрибной версии ядра глючит, например медиатековская вайфайка в asus vivobook не работала примерно никак в дистрибном ядре от убунты 20.04.
Иногда ещё ядростроители любят ломать поведение вафли касательно выбора регионов и разрешенности каких-то каналов (отвалился 13ый канал в древнем ноуте), опять пришлось патчить (патч тривиальный) и пересобирать.
Из самого эпического, заставлял работать условно свежую вайфай-карточку на крайне протухшем дистрибе (еще с ядром 2.6.хх) путём хакинга сорцов. Таки заставил, правда тут была сборка модуля, а не пересборка ядра.
У этого есть обратная сторона, когда все подразумевают наличие исходников и просто понять состав модулей без конфига в падающем vmlinuz превращается в нетривиальную задачу.
Я сейчас решаю квест по переносу ОС с неисправной железки в ВМ и чтобы отключить модули для отсутствующих устройств надо пересобрать ядро в идентичной конфигурации без них - blacklist там ещё нет, зато с диска подгружаются другие модули от производителя.
сколько из них могут внятно объяснить, зачем они это делают?
слышал что оно круче/быстрее/потюнено — достаточная причина, разве нет?
так-то я с матами и манами, пожалуй, сдюжил бы, но ни одной причины для этого не вижу
Этот разрешает вам материться, устанавливая zen или xanmod через pamac, synaptic, ubuntu software center, yast2 — но не видит ничего сложного в нескольких щелчках мышью.
Исходная тема - необходимость Linux в общем образовании. Вопрос, от которого отпочковалась эта ветка комментариев - "сколько людей в мире?"
Причина-то в общем случае вполне валидная, но даже я, знающий слово "ядро", положа руку на сердце, обновлюсь только на стандартное ядро дистрибутива и только когда меня software center напоминаниями задолбает.
А что говорить о тех, кому само понятие ядра столь же близко, как мне - чемпионат Новой Зеландии по... да по чему угодно?
Вопрос <…> "сколько людей в мире?"
И для ответа на него, хотя бы примерного, надо узнать, какую причину вы считаете достаточной… )
обновлюсь только на стандартное ядро дистрибутива
В роллинге вы обновитесь достаточно быстро, в стейблах можно не апать мажорную версию до следующего релиза, если не задаваться такой целью.
Кстати, насчет стандартов: убунтовские hwe-ядра достаточно стандартны?
Сам факт того, что ядро обновляется как обычное приложение говорит о том, что его могут установить неограниченно большое количество людей. Будут ли они этим заморачиваться — вопрос уже другой.
Не так уж важно, сколько. Главное, что такая возможность существует. Это снижает порог входа на многие порядки. Да, он всё равно катастрофически высок, но сделать конкурента windows ещё сложнее, чем конкурента linux. А возможность конкуренции принципиально важна.
И замена скучных обоев на нескучные?
Дворянство,
Это вы намекаете, что в 2023 году монолитное ядро смотрится пережитком феодализма ??
Дворянство, как правило, было граммотнее. Это отличало их от крестьян.
Это вы себя записали в аналоги дворян, а пользователей неугодных OS - в крестьян?
Очень интересная теория, что думают о ней ваши 0 друзей?
Пользователи windows и macos принципиально отличаются от пользователей linux. Красивый интерфейс и базовое удобство рабочего процесса ставится выше, чем понимание принципов работы операционной системы.
Это утверждение неверно. Как следствие, никакие последующие выводы рассматривать нет смысла.
Признаю, был в корне не прав! Внёс корректировки. Спасибо что сказали.
Windows и macos принципиально отличается от linux. Красивый интерфейс и базовое удобство рабочего процесса ставится выше, чем понимание принципов работы операционной системы.
А лучше-то не стало.
Вы не понимаете простой вещи: чтобы системой массово пользовались, нужно, чтобы базовое удобство стояло выше понимания принципов работы. Идеальный пример этому - естественный язык.
Спасибо! Буду всегда учитывать это в своей работе, внесу корректировки в текст.
Да всё он понимает. Знает человек, что учить детей линунксу будет просто некому, нет преподов под операционку с 3% рынка на десктопах. Зато пропиарился.
У детей есть много источников для получения информации.
Более благоприятная для обучения среда делает лучше процесс обучения.
Линус Торвальдс начал программировать в 10, возможно в какой-то степени потому, что к этому располагала среда. Сейчас среда тоже не должна ограничивать возможности к познанию.
Более благоприятная для обучения среда
Линукс очень далёк от благоприятной для обучения среды. Он не сделает обучение лучше, он превратит и так в лучшем случае посредственное преподавание в битву преподов с малознакомой ОС.
Сейчас среда тоже не должна ограничивать возможности к познанию
Сейчас главная проблема в школьном ИТ-образовании – существенный дефицит вменяемых преподавателей даже по той программе, что есть. А вы предлагаете этот дефицит не просто ухудшить, а создать полный вакуум.
битву преподов с малознакомой ОС
А разве это не процесс обучения? То что преподователи тоже узнают что-то новое можно считать бонусом. В школах используется не так много программ, чтобы ни сделать под эту задачу дистрибутив.
не просто ухудшить, а создать полный вакуум
Главное русифицировать документацию, что бы у всех был доступ к необходимой информации.
Главное русифицировать документацию
Интересно, с какой целью в школе изучают иностранный язык? Для Лондон is the кєпитєл оф?
Читать дети умеют в первом классе, а английский на приемлемом уровне для чтения документации у них будет классу к десятому, если повезёт.
Так что документация и справка на родном языке — это очень важно для обучения.
Шта? В документации не используются сложные языковые конструкции. Словарный запас - минимальный. Есть онлайн переводчики.
Да, какая документация нужна? Какой мануал до сих пор не переведен на все популярные языки?
Шта? В документации не используются сложные языковые конструкции.
Дети в школе изначально не знают и простых языковых конструкций.
Словарный запас — минимальный.
Специфичный.
Есть онлайн переводчики.
Угу:
man — системный пейджер. Каждый аргумент страницы, переданный man, обычно является именем программы, утилиты или функции. Затем будет найдена и отображена страница руководства, связанная с каждым из этих аргументов. Раздел, если он есть, направит людей к поиску только в этом разделе руководства.
Я бы не назвал это переводом, понятным начинающему пользователю, который не знает контекста.
Да, какая документация нужна?
Для детей. В стиле книжек про профессора Фортрана.
Дети в школе изначально не знают и простых языковых конструкций.
Дети изначально и писать не умеют. Ни ручкой, ни в горшок ;)
Словарный запас — минимальный.
Специфичный.
Минимальный. Можно не отличать past indefinit от present simple, не помнить неправильных глаголов и спокойно понимать о чем текст. Конечно, можно вспомнить канонического гуртовщика мышей ;) Но если человек совершенно не различает, имеется в виду драйвер (программа), драйвер (водитель), или драйвер(человек-скотовод с мышиным уклоном), он на любом языке ничего не поймет.
Для детей.
Это называется учебник. Не вижу препятствий написать учебник про bash но с картинками ;) Про проффесора получилось же?
Дети изначально и писать не умеют.
Правильно, их этому учат с нуля. И английскому в школе тоже учат с нуля. Но далеко не всегда с первого класса. И далеко не всегда английский — есть и французский, и немецкий. А вот русский дети всё же уже до школы знают более-менее.
Не вижу препятствий написать учебник про bash но с картинками
Конечно. Помнится, у MS была брошюрка для детей на тему "папа принёс домой сервер".
Но для башей почему-то всё пока что ограничиваются манами. И гуглом.
Специфичный
И что? Я английский язык первоначально учил по словарям, компьютерным играм и учебникам по программированию.
В результате я даже близко не говорил на английском, но при этом без особых проблем понимал игры и учебники. Именно потому что словарный запас был нужен не особо большой и очень многое было понятно из контекста.
Я английский язык первоначально учил по словарям, компьютерным играм и учебникам по программированию.
Ну так вот это и есть тот самый специфичный словарный запас. Тем более, что язык вы учили сами, а не вас ему учили в школе два часа в неделю на тему "ландон из зе капитал".
Ну да. Для того чтобы изучать программирование "настоящий" английский совсем не обязательно нужен. И дети вполне себе могут обойтись без него.
Лично мне кажется, что "настоящий" английский детям гораздо полезнее, чем программирование и программистский пиджин.
Да и вообще, не уверен, что в основной школьной программе надо программирование изучать. Про какую-то базу рассказать не помешает — всякие там системы счисления, форматы данных, алгоритмы и циклы, но не более. Лучше про прикладные задачи рассказывать. Только не на базе одной программы, а в плане общих принципов. И давать самостоятельные задания вида "На прошлом уроке мы учились, как оформлять документ со стилями в ворде. А теперь вот вам либра — сделайте то же самое." Чтобы дети видели разнообразие и умели сами искать пути решения, пользоваться справкой, гуглом и т.п.
Как мне кажется, от подобного будет гораздо больше пользы, чем от умения гонять робота с чертёжником и писать хелловорлд на паскале.
А кому же хочется именно программировать — добро пожаловать на факультатив.
Лично мне кажется, что "настоящий" английский детям гораздо полезнее, чем программирование и программистский пиджин.
Даже не собираюсь спорить. Но речь была не об этом :)
Да и вообще, не уверен, что в основной школьной программе надо программирование изучать. Про какую-то базу рассказать не помешает — всякие там системы счисления, форматы данных, алгоритмы и циклы, но не более.
"База" детям скучна. Детям скорее хочется что-то делать. Но изучать программирование в школе совсем не обязательно на примере ассемблера. Можно водить каких-нибудь роботов по лабиринтам, картинки алгоритмами рисовать или ещё что-то в этом роде.
Даже не собираюсь спорить. Но речь была не об этом :)
Примерно об этом. Там же не последовательно учат "сперва английский, потом компутеры". Там всё параллельно идёт.
"База" детям скучна. Детям скорее хочется что-то делать.
Школа детям вообще скучна. Но там должны вбивать фундамент. Пусть не очень глубокий, но какой-никакой должен быть.
Можно водить каких-нибудь роботов по лабиринтам, картинки алгоритмами рисовать или ещё что-то в этом роде.
Ну так КУМИР с исполнителями. Можно черепашку в лого гонять. Для понимания всяких там логических операций была простенькая игрушка по имени LOGIC (где бомбочку надо было вниз опускать).
А на факультативе, если кому "настоящего" программирования хочется, можно леговских роботов гонять (Mindstorm которые).
Впрочем, дитям не хочется программировать, дитям хочется машинок и майнкрафта...
Примерно об этом. Там же не последовательно учат "сперва английский, потом компутеры". Там всё параллельно идёт.
Ну так одно другому не мешает. Более того можно поначалу просто выучить написание операторов на английском и при этом не понимать что эти слова означают.
Школа детям вообще скучна. Но там должны вбивать фундамент. Пусть не очень глубокий, но какой-никакой должен быть.
Ну так если фундамент можно "спрятать" во что-то интересное, то почему это не сделать?
Впрочем, дитям не хочется программировать, дитям хочется машинок и майнкрафта...
Ну так тот же майнкрафт можно великолепно использовать для обучения. И насколько я знаю куча школ в мире так делает.
можно поначалу просто выучить написание операторов на английском
Так речь идёт про то, чтобы документацию читать. А на каком там языке операторы пишутся — действительно не особо важно.
Ну так тот же майнкрафт можно великолепно использовать для обучения
Можно. Но это школьную программу надо переделывать. Ну и линукс тут уже никаким боком. А началось ведь всё с предложения изучать линукс и баш. :)
Так речь идёт про то, чтобы документацию читать. А на каком там языке операторы пишутся — действительно не особо важно.
Это 30-40 лет назад для этого надо было обязательно английский знать. Сейчас, как это уже написали выше, есть куча альтернатив.
Можно. Но это школьную программу надо переделывать.
Ну так по хорошему и надо.
Ну и линукс тут уже никаким боком. А началось ведь всё с предложения изучать линукс и баш. :)
Однозначно никаким. То есть опять же когда я учился в универе, то у нас всё было на линуксе. И не сказал бы что это что-то особо дало.
То есть опять же когда я учился в универе, то у нас всё было на линуксе. И не сказал бы что это что-то особо дало.
Когда я учился, у нас были и дос, и линукс, и винда разных версий. Но это всё не имело никакого отношения к тому, чему мы в итоге научились. Кому было интересно — тем было пофиг, что стоит в универе, они самообразованием занимались. А кому не было интересно, тем тем более всё было пофиг — пройти бы обязательную программу и отмучиться.
Если ты не учишься на линуксопрограммиста, то нафиг тебе нужны эти ядра и прочие баши. А на чём запускать обучающие и прикладные программы — особой разницы нет.
почти с всем согласен кроме кумира или лого. https://codecombat.com/ и аналоги а не скукота древняя
Нужен ли вообще нынешним детям компьютер? Они с ним сталкиваются разве что только в играх, да и то далеко не все.
В общем случае нужен.
Меня задолбали практиканты-первокурсники, которые кроме телефона ничего в руках не держали.
Это и доказывает, что до сих пор он им нужен не был. Геймеры-задроты прекрасно компьютер знают - и софт, и железо. В пределах своих интересов, разумеется.
Им много что не нужно из школьной программы. Но это не повод этого не изучать.
А в институте подразумевается, что студент должен обладать каким-то набором навыков. И если его приходится обучать включать компьютер и запускать программы, то это отнимает ценное время. Когда я учился, у нас в провинциальном университете было обучение на бакалавра не четыре, а пять лет. Потому что набирали всех подряд и на "первом" курсе вдалбливали ускоренно школьную программу по математике и английскому. Кто всё это знал (сдал экзамен), то поступал на "второй" курс (по факту первый).
Ну и с компьютером там, кстати, учили обращаться — студенты хотели в чятик, чятик тогда в основном был irc, доступ к интернету более-менее свободный был только со студенческого линукс-сервера — потому даже девочки-блондинки умели поставить терминалку, прикрутить к ней koi-шные шрифты, зателнетиться на сервер и чятится через bitchx. Транслитом, правда — поставить ещё и koi-раскладку уже мало кто справлялся.
разве это не процесс обучения?
Для кого?
То что преподователи тоже узнают что-то новое можно считать бонусом.
А пока не узнали, то пусть просто что-то рассказывают? Неважно что?
Ну есть altlinux, там довольно большой пласт документации переведен. Из минусов, там могут быть старые версии пакетов. У них как-то долго свежая версия пакета попадает в дистрибутив.
А разве это не процесс обучения? То что преподователи тоже узнают что-то новое
Вам, уважаемый, точно сначала имеет смысл поинтересоваться как в самом деле в школах дела. Хоть сколько нибудь вменяемые преподаватели при попытке навялить им очередную херню просто увольняются.
Главное русифицировать документацию
А сейчас то её нет русифицированной чтоли? И что, популярнее от этого линух на десктопах стал?
Обычные люди сильно отличаются от задротов типа нас с вами, у них ОС это "нечто с кнопочками", позволяющее им выполнять их задачи. Восприятие ЭВМ без благоговейного восторга, как бытовую электронику.
У человека, банально, ограничен ресурс мозга на то, чтобы ковыряться и разбираться с чем-то, обычные люди потратят время и силы на занятия связанные с межличностными взаимодействиями, налаживанием соц связей или же просто тупо на удовольствия от потребления.
Мне кажется, что у вас представления о людях немного оторваны от реальности. Я согласен с тем, что многих людей можно превратить в отлично разбирающихся в технике специалистов но при выполнении условий:
1) У них родители должны "гореть" и интересоваться ИТ.
2) У них должны быть учителя, интересующиеся ИТ и хорошая программа обучения.
3) У них окружение должно быть таким, чтобы в нём одобрялся гиковский образ, а не высмеивался.
4) У них должно быть полноценное питание и привиты навыки информационной гигиены, чтобы мозг привыкал строить сложные цепочки умозаключений, а не скроллить тикток формируя мозаичную картину мира, основанную на образах и эмоциях.
Вывод: чтобы повышать уровень культуры и технической грамотности нужно заниматься "скучными" и базовыми вещами, по сути создавать благоприятные условия для жизни и развития людей.
Мотивация человеческих существ это удовольствие (например от удовлетворения любопытства) и социальное поощрение. Если взрослые смогут показать детям как получать удовольствие от программирования то тогда ребёнок станет интересоваться программированием. Если общество одобрит занятие, поощрит то люди будут программистами.
Человек гибко подстраивается под окружающую среду и перенимает повадки и ценности общности в которой он вырастает. И это потом формирует его поведение на оставшуюся жизнь. Формирование ценностей и воспитание общества это комплексная задача требующая финансовых, политических, организаторских ресурсов. В каком-то смысле это задача направления и контроля культурной эволюции человечества. Одной заменой ОС с винды на GNU\LINUX мало что можно изменить.
Не думаю, что преподаватели информатики в школе глубоко знают Windows. Я не видел, чтобы преподавали именно устройство ОС, это все таки дисциплина ВУЗов. А обучать основам программирования, работы в офисном пакете и базовой компьютерной грамотности - практически любой преподаватель информатики сможет.
Проблема в перестройке курса на новые программы. И в том, чтобы дома был компьютер с линукс. С последним как раз проблем может быть куда больше, так как далеко не все родители обладают навыками установки ОС. Да и часть бюджетных решений нельзя будет рассматривать, так как может не быть поддержки аппаратной части со стороны дистрибутива линукс. В основном это камера, wi-fi модуль, может и сетевая карта, ну и могут быть проблемы с дискретными видеокартами, особенно когда их есть в паре ещё и интегрированная. Т.е. у родителей нет возможности купить уже полностью готовый ПК для учебы ребенку.
А ну и дистрибутив надо будет выбрать один, так как малейшее отклонение от того что в учебнике и на школьном компьютере может вызвать ступор у ребенка. Далеко не всем нужно и интересно возится с этим. С этим чуть проще, можно взять отечественный дистрибутив, тот же altlinux, его без покупки лицензии можно использовать дома.
Да, статья - пиар дистрибутива автора.
обладают навыками установки ОС.
Windows Subsystem for Linux/Cygwin - запретили Личным Указом Путина ?? PS По моему скромному мнению как раз нет ничего удобней чем win машина cygwin ...
WSL дает представление о работе с командной строкой, но не для погружения целиком в дистрибутив. В идеале, в случае с линукс/*BSD показать несколько окружений рабочего стола. По моему опыту люди теряются при виде чего-то непривычного и просто не будут этим пользоваться. А так им GUI будет более привычен. Показать что искать, чтобы поменять какие-то настройки, как минимум управление сетями.
В случае со школьным образованием, мне кажется, важно показать разнообразие интерфейсов, тогда будет проще разобраться с каким-то новым. По удобству, потом каждый выберет для себя сам. Есть организации где на компьютерах стоит линукс их еще не много, лично не видел, но в интернетах читал, что перевели всех пользователей на линукс. Так что пруфов не будет.
"Полное погружение" в линукс актуально, если есть какая-то глобальная цель у государства снизить зависимость от продуктов Windows, если такой цели нет, то и мучать детей этим особо смысла не вижу. Можно просто в виртуалке или с Live носителя с линукс показать, что есть альтернатива Windows. А кому надо, тот потом сам разберется.
А что касается удобства... Ну тут у всех свои предпочтения, мне больше нравится линукс, кто-то предпочитает мак, вы винду. Если бы меня поставили перед выбором для дома или мак, или винда, то выбрал бы винду. К счастью, меня никто не ставит перед таким выбором. А в работе предпочитаю то, чем пользуется большинство, чтобы не собирать уникальных граблей. Да и линукс реже предлагают, в основном выбор между виндой и маком, а то и просто без выбора.
В естественных языках тоже нужно понимать принцип работы.
Я знаю много людей, которые языком пользуются, но принципа не понимают.
Ну дык у них есть волшебные слова-плейсхолдеры, вроде б..., х... и п....
А вы-то понимаете принцип работы языка? Т.е. именно не знание, в какой падеж поставить существительное и какой предлог использовать, а именно как так получается, что такое сочетание звуков/знаков означает одно, другое - другое, а третье может означать разные вещи в зависимости от контекста.
А "принцип работы" простой: так исторически сложилось. Вот почему русский человек называет, скажем, ксерокс ксероксом? А потому что 50 лет назад побывал человек в какой-нибудь стране первого мира, увидел бандуру, в которую местные пихают документы, а оттуда выходят копии, а на ней надпись — XEROX. Приехал домой — рассказал другу: "видел у них там такую машину, что копии делает, XEROX называется", друг пересказал своим друзьям — "Вася за бугром копировальную машину видел, как он там сказал? А, ксерокс" — и всё, так и пошло. И с флешками та же фигня: "What is this?" — "Flash card" — "ага, понятно, флешка".
И вот так практически всё. Просто большинство слов сложилось задолго до нашего с Вами рождения, а потом обросло приставками, суффиксами и т.д. В некоторых случаях — наоборот: Zonnedoek → зонтик → зонт.
Всё же есть разница между "знать в общих чертах" и "иметь полное представление о деталях работы".
В естественных языках такого навалом:
"щ" всегда мягкая (потому что для твёрдой есть "ш") - но в концах слов женского рода она... ещё мягче?
фразы "я сегодня плотно пообедал" и "сегодня плотно пообедал я" имеют одинаковый смысл и набор слов, но вторая выглядит гораздо поэтичнее (в смысле "более вероятно встретить в поэзии") - почему мы не говорим так в повседневной жизни?
раньше по правилам можно было только "мой кофе" (хотя на "-е" оканчиваются слова только среднего рода, но вы не понимаете, это так исторически сложилось), теперь можно ещё и "моё кофе". А вот если сказать "моя кофя остыла" - вас примут за неграмотного, потому что два рода - это максимум (почему?)
Я не могу ответить ни на один из этих вопросов (то есть не понимаю как язык работает, лишь "сердцем чувствую, что надо так") - но пользоваться, похоже, могу. Иногда даже без опечаток и прочих ошибок по невнимательности.
И в программах/ОС так же: я знаю, что если я щёлкаю левой кнопкой мыши, то объект под стрелочкой нажимается (что происходит примерно во всех графических интерфейсах). Этого достаточно, чтобы пользоваться графическим ПО, для этого не надо знать ни как про нажатие кнопки узнаёт ОС (аппаратное прерывание или регулярный опрос?), ни как это передаётся программе (выставляются флаги в специальных регистрах процессора, кладётся сообщение в очередь, или ещё как-то), ни чем это действие отличается от нажатия клавиши на клавиатуре.
Когда я использую конструкцию вида find . -name '*.jpg' | sort | head -n 10 | rm - мне не важно, как find определяет какие файлы подходят под маску, какой именно алгоритм используется в sort, используется в head цикл или рекурсия со счётчиком, какие системные вызовы выполняет rm.
Потом пришла волна безграмотных, начался вечный сентябрь. Эти люди были неспособны произнести слово «кофий» и написать его. Махнув рукою, учёные интеллигенты были вынуждены согласиться, что можно писать и говорить «чёрный кофе», хотя это — безграмотно и вульгарно. Приличный человек не будет говорить «кофе», потому что правильно говорить «кофий».
Ну, а потом пришло новое поколение, для которого «чёрный кофий» уже не имело смысла, а «чёрный кофе» было материнской традицией. Новое поколение не понимало, что оно унаследовало упрощённый и бескультурный вариант, поэтому и решило, что так — прилично и культурно.
Теперь мы второй раз проходим через то же самое колесо, только не со словом «кофе», а со словом «чёрный». Теперь вместо «чёрный кофе» будет «чёрное кофе». И точно так же, как ругались в прошлый раз — так же будут ругаться и в этот раз.
А помните, ещё было такое грамотное и приличное слово — козак, через о? Почему теперь казак стал через а?
А помните, ещё было такое грамотное и приличное слово — вакация? Не какие-то собачьи каникулы, а настоящая, приличная, культурная вакация! А ещё были не какие-то лаунжи, а рекреация! Видел бы адмирал Шишков, докуда мы провалились…
Наи хирувалиэ Валимар?
Допустил ошибку.
В моём окружении линуксом пользуются преимущественно программисты (возможно, некоторые лучше понимают принципы работы операционных систем). Надо адаптировать систему для всех.
Красивый интерфейс и базовое удобство рабочего процесса ставится выше, чем понимание принципов работы операционной системы.
С точки зрения обычного пользователя - зачем знать как работает ОС? ему нужно что бы работало, а как там что внутри ему глубоко до лампочки. Это как с автомобилем - пока едет - всё ок, ну сломалась - отвез в автосервис. Ну можешь сам починить конечно, но зачем? Мы же не лезем в устройство ТЭЦ что бы узнать как получают электричество для дома? Если хочется узнать - это уже обычное любопытство.
С течением времени люди в принципе больше узнают. Откуда нам знать, что смогут придумать пользователи, если у них даже не будет возможности узнать про систему? Если нет возможности изучить программы, то пользователи 100% ничего не придумают, а если такая возможность будет, то смогут найтись те, кто что-нибудь улучшит.
какая разнице условной бухгалтерше Марии Ивановне на каком уровне модели OSI отсылается ее отчет/накладная/договор в 1С? Работает - ок, не работает - пусть админы веселятся с этим. Ей главное работу во время сделать.
Если программа, в которой пользователь делает работу открыта, то можно удостовериться в том, что она не делает ничего лишнего. Например, что этот отчет/накладная не отсылаются кому-нибудь еще. И пусть не все пользователи могут разобраться как работают программы, найдутся те, кто смогут и захотят этим заниматься, что бы защитить тех кто не может от вредоносного ПО.
вот это вот Ваше "найдутся"- оно совершенно негарантированое. Кодовая база с каждым годом растет. Ядро линкуса под 30 лямов строк кода- любая его подсистемка- от нескольких тысяч строк, это несколько сотен страниц текста. просто чтобы их прочитать и понять, что там происходит- нужно несколько недель погружения в тему. Сможет ли Марьиванна из бухгалтерии подправить драйвер принтера? нет. В маршрутизаторах под ОпенВРТ при подключении SSD-дисков через контроллер JMicron580 по USB3 диск не стартует- какая-то ошибка в инициализации питания контроллера, багу скоро пять лет, про него знает куча программистов, и все знают, где он лежит. но до сих пор не смогли починить. Я пробовал- но бросил затею, потому что разобрать по исходникам, как там происходит инициализация этого контроллера и как передернуть питание диска- невозможно без плотного погружения в детали работы USB3.0 и программной и аппаратной части- это требует слишком много времени, которое ни я, ни другие причастные не готовы тратить на этот диск. И с каждым годом вероятность "найдется" падает и падает еще ниже.
Если не секрет, сколько открытого кода лично вы проверили, чтобы убедиться в его безопасности?
Были случаи когда я пытался проверить некоторые открытые проекты на наличие потенциальных уязвимостей.
Много раз приходилось смотреть исходники зависимостей, которые я использовал.
Это не целенаправленный поиск уязвимостей, но увеличивает вероятность их найти, на контрасте с использованием закрытых решений.
Нашли?
Насколько вы себя лично считаете более грамотным пользователем, чем среднестатистический пользователь линукса?
Сможет ли сеньор фронтендер найти уязвимость в опенсорс программе или ядре написанном на С/С++?
Не сможет. Но на 8 миллиардов человек достаточно пары тех, кто сможет и захочет. Да, могут не найтись и пара человек. Но мы не знаем заранее, найдутся ли, поэтому оставить для них дверь открытой крайне важно.
А если более практично - в большинстве опенсорс программ баги чинятся десятками. То есть люди находятся. И пользоваться софтом, который кто-то со стороны может проверить, более комфортно (лично мне, другим не навязываю).
Нашли?
Смог убедится в том, что её нет. В случае если получилось бы найти, то написал бы письмо, и уязвимость можно было бы закрыть.
Смог убедится в том, что её нет.
Я посмотрел на звездное небо - чайника возле Марса не наблюдается. Шах и мат, Рассел, нет там никакого чайника ;)
в опенсорсном openssl десятилетия тысячи профессионалов не замечали heartbleed баг. Это не означало, что его там не было.
heartbleed не самый простой баг, был же печально известный баг в дебе, когда они опенссл собирали с отладочным ГПСЧ, и ни у кого ничего не дрогнуло при несравнимо меньшей сложности обнаружения.
В виндовой самбе тысячи профессионалов M$ не замечали баг, из-за которого ее первую версию пришлось отключить насовсем.
В Sun, а потом и в Oracle тысячи профессионалов не замечали выстреливший пару лет назад CVE в логировании.
Справедливого мира нет, волшебных корпоратов нет, магии нет тоже — есть матстат и тервер.
тысячи профессионалов M$… В Sun, а потом и в Oracle тысячи профессионалов
Не тот аргумент. Тут же как раз речь про то, что проприетарный софт забагованный, потому что там исходники не почитать и багу не найти. А у опенсорса — "миллионы внимательных глаз".
По факту же особой разницы нет, и там и там за годы разработки столько накручено, что может быть вагон багов прятаться и иначе как случайно на него не наткнёшься.
Ну и вот хардблид-то исправили, а судя по до сих пор существующим рекомедациям не выставлять RDP голой ж.. в интернет -- все баги там не исправили и даже не собираются.
Вообще-то, голым задом ничего не рекомендуется в инет выставлять. Но RDP с нормальными паролями и чем-то типа fail2ban нормально живёт в инете. Не уверен, что направленную атаку переживёт, но от ботов нормально отбивается.
Конечно, через VPN ходить было бы секьюрнее, но юзеры не всегда хотят дополнительных сложностей.
ssh голым задом вполне себе живёт, ну проблемы могут быть только со слабыми паролями (и против них даже fail2ban слабо поможет, при распределённом переборе), кардинально лечится полным запретом входа по паролям. А вот рекомендациями ни в коем случае не выставлять rdp голым задом полон весь интернет.
рекомендациями ни в коем случае не выставлять rdp голым задом полон весь интернет.
Рекомендациями отключать обновление file access time в NTFS и не размещать файл подкачки на SSD тоже весь интернет полон был.
А уж в наше время, когда большая часть интернета превратилась в SEOшную копипасту…
Да, хороший тон — не светить внутренние сервера наружу. Но, при соблюдении гигены (нормальные пароли, бан ботов, отключение устаревших протоколов, установка обновлений вовремя), ничего особо страшного не произойдёт.
Это примерно как переход дороги без пешеходного перехода. По хорошему стоит дойти до него, но, при соблюдении правил безопасности, можно дорогу в любом месте переходить.
Тот, тот.
Это вопрос не фракциональности, а матстата и тервера.
Если исходники открыты — их видит больше людей и больше людей может их проверить, их проще анализировать чем выхлоп дизассемблера, даже такго продвинутого как IDA; в их разработке принимают люди из других команд с другими сложившимися практиками.
Все — каждый из пунктов повышает вероятность поймать баг, это значит, что чисто статистически открытые исходники позволяют выловить больше багов, включая опасные.
Я бы чуть по другому спросил, сколько программ не было проверено, из тех которыми автор пользуется. Ведь тут нет смысла проверять одну-две, если еще пара десятков не проверено..
Некоторые программы не были проверены. Большая часть из официальных репозиториев, часть из AUR.
Попрошу прощения за высказанную фантазию, но есть шанс, что алгоритмы машинного обучения смогут проверять исходный код на наличие уязвимостей (учитывая прогресс языковых моделей последних лет).
Это, наверное, глупый аргумент, но я бы сделал ставку на потенциальную возможность использования таких алгоритмов для обеспечения будущей безопасности пользователей, по крайней мере в качестве дополнительного инструмента.
Ключевыми в таком случае станут 2 фактора - открытость всех компонентов и удобство использования.
Если уж фантазировать, то ИИ смогут и откомпилированную программу проверить. В целом, я не согласен с тезисом о безопасности. Кто в состоянии и с желанием побеспокоится о безопасности, тот и сейчас это делает. Остальные же, у них другие заботы..
Но я согласен с основной идеей, что образование должно быть оторвано от окон и яблок, и быть более глубоким, чем есть сейчас.. Писать скрипты обрабатывать вывод программ хотя бы в общих чертах должны учить в школе, как часть общеобразовательной программы.
Десять лет назад я учил пару студентов программированию. Знаете, с чем вышел главный затык? Они вообще не понимали, что такое консоль и перевод строки. Они никогда не видели черного экрана с курсором.
Это было десять лет назад. А вы предлагаете скрипты писать и обрабатывать вывод программ.
Согласен с тем, что нельзя привязывать к какой-то одной ОС, в идеале дать навыки работы с несколькими. Показать как систему (пере-)устанавливать, как сделать так, чтобы данные не потерять.
А вот писать скрипты и обрабатывать вывод - ну разве, что в совсем общих чертах, что смотрите так можно делать и какую пользу из этого можно извлечь. Большинству это ни в работе, ни в жизни не нужно. Да и просто не интересно будет.
Здорово, конечно, в школе дать все полезные навыки, которые могут пригодиться, но это просто не возможно. Так что лучше показать возможности и научить работать с информацией, чтобы можно было получить необходимые умения самостоятельно.
Лично вам не нужно уметь виртуозно управлять инвалидной коляской и регулярно применять этот навык, чтобы понимать необходимость в доступной инфраструктуре.
Лично вам не нужно уметь проверять софт на уязвимости и активность и регулярно применять этот навык, чтобы понимать необходимость в доступности такой проверки.
Лично вам не нужно уметь проверять софт на уязвимости
Лично я проверял сколько байт пропатчено в трех раздачах %software_name% на рутрекере по сравнению с установками из оригинального дистрибутива :)
То есть, преимущества открытости вы понимаете и даже прочувствовали на личном опыте, но гнусно троллите?
Гнусно демонстрирую паранойю в некоторых вопросах.
Поиск закладок в исходниках и сравнение бинарников из доверенного и недоверенного источников - разные вещи. В случае бинарника из доверенного источника предполагаем, что закладок там нет.
В случае предположения о возможности закладки в исходном коде - нет отправной точки, которую можно считать безопасной. Закладка может быть где угодно, она может быть неочевидной. Вручную реально внимательно проверить несколько тысяч строк кода, может десятков тысяч (если код простой). Проверить безопасность миллионов строк кода самостоятельно невозможно.
Проще пытаться поймать закладку по косвенным признакам (сетевой траффик) или запускать подозрительный софт на изолированной/виртуальной машине.
Трагедию общин Фигню вы демонстрируете, если честно. И вот почему.
Одному — невозможно, да. Но пользователь у открытого кода не один, их десятки миллионов, среди которых — тысячи высококлассных специалистов.
И если будет повод заглянуть внутрь и распотрошить код — с исходником это сделать неимоверно проще.
А для этого нужно иметь те самые открытые коды, даже если лично тебе они как собаке пятая нога, и всех их ты проверить не сможешь никогда.
Опять мы приходим к одному и тому же; порадуйте каджита, скажите что-нибудь новенькое.
Я знаю, что для линуксойдов что "опенсурс = безопасность" это мантра не требующая подтверждения. Но мне как нужны доказательства этого утверждения, есть исследования на эту тему? Есть доказательства того, что открытость не облегчает внедрения закладок? Есть доказательство того, что открытость не позволяет не компетентным людям делать такую полнейшую глупость как Heartbleed? И есть объяснение, почему военные когда им нужна безопасность не берут опенсурс, а делают свои "корпоративные" разработки?
есть исследования на эту тему?
Данные для них лежат в закрытых багтрекерах, а публике доступны как мы там шото исправили.
Если, конечно, вы хотите исследование, а не биас покормить )
Из публичных данных можно вывести только не слишком релевантные баги на штуку софта в год.
Но есть такой нюанс… на сегодня, если не брать хелловорды разной степени упоростости, огромная часть опенсурсного софта написана, сюрприз, корпорациями.
Причины к тому, в первую очередь, экономические.
И тут или, с ваших слов, выходит что корпорации объединяются чтобы вместе осилить неподъемный для каждой в отдельности кусок и намеренно платят деньги чтобы их сотрудники писали говнокод, который потом пойдет им же на прод, или что вы смололи херню.
Ну, не первый раз, когда диванный специалист готов рулить хоть корпорацией, хоть миром )
Берут и опенсорс, просто делают аудит и, да, возможно, свои доработки, отрезая им не нужное, чтобы не тратить ресурсы на аудит этого. Это если есть подходящее решение опенсорс решение.
Ну это если не считать компиляторов и различных библиотек. Да и ОС линукс военными используется.
Да и ОС линукс военными используется.
А можно конкретные примеры использования военными Линукса? Какой дистрибутив, где именно?
Раньше был МСВС (мобильная система вооруженных сил), сейчас Астра Линукс используется.
Для последнего, можно купить лицензию и использовать дома.
Раньше ещё Солярис на Эльбрусах использовался для управления разными системами. Но Солярис все таки не опенсорс, покраснел мере не opensolaris использовался.
Так где именно? Писарями в штабах или в системе управления РВСН?
Насколько знаю, в иных ВС для всяких серьезных вещей используются серьезные системы - QNX, VxWorks, LynxOS и подобные. Но это все ОСРВ весьма специфические и весьма недешевые. Еще и обвешанные кучей сертификатов (безопасность и т.п.)
Из линуксов для подобных вещей знаю только Wind River Linux. Но это тоже не совсем тот линукс который в широкораспостраненных дистрибутивах. Хотя бы потому что оно реального времени.
Например, система управления и мониторинга оборудования РЛС наземного базирования. Там как раз использовался Солярис и в планах, насколько я понял, был переход на что-то типа линукса.
Не все задачи требуют жесткого реального времени и соответствующих ОС.
Бортовые навигационные системы, которые Транзас делал и они использовались так же и военными. Часть точно работала под управлением линукс, но что конкретно за дистрибутив - не знаю, скорей всего так же Астра.
Да и те же данные накапливать и обрабатывать где-то надо, аналитику и тому подобное, да и писарям в штабах тоже за чем-то работать надо. Но там винда скорей всего, не знаю, не видел. В военкоматах, вроде, винду видел.
для всяких серьезных вещей используются серьезные системы
Это очень-очень серьезные люди, и только у них используются очень-очень серьезные системы.
А этот ваш линукс, который используется в миллиардах серверов, баловство такое. Ах да, еще линукс в умной винтовке используется.
Правильно говорить специфические нишевые системы с определенной сертификацией.
С течением времени люди в принципе больше узнают.
С течением времени люди создают всё больше и больше уровней абстракций. И средний человек всё меньше и меньше интересуется тем что происходит на "нижних" уровнях.
Если нет возможности изучить программы, то пользователи 100% ничего не придумают
А вот это просто неверно. Я бы сказал что уже сейчас даже среди айтишников приличная часть людей не особо понимают как "физически" работают компьютеры. Или как это всё выглядит на уровне машинного кода. Но это не мешает им придумывать всякие разные вещи.
Да и вообще времена "универсалов" в науке и технике уже давно прошли. Сейчас практически все открытия делаются "узконаправленными специалистами".
Ну так без этой "магии", то есть новых абстракций и прогресс не особо возможен.
Вы лично до конца понимаете всю современную физику, химию и математику? Или вы просто выбрали себе какой-то "пласт" абстракций и тоже хорошо разбираетесь только в нём?
Меня расстраивают люди, позиционирующие себя как "программисты", но при этом умеющие только гуглить и копипастить примеры в надежде что что-то заработает.
И даже если, то если это так работает, то в чём проблема?
Я считаю, что я достаточно эрудирован в вопросах физики, астрономии и математики.
То есть всё-таки до конца не разбираетесь. Я уверен что найдутся люди, которых вы расстраиваете :)
Ну я и не позиционирую себя как физик/математик/электронщик.
Да, но вы пишите программы для железа и при этом не до конца понимаете как это железо на самом деле там работает. И даже не работает, а просто существует.
мне такой "специалист" не нужен.
Ну так вас никто и не заставляет их на работу брать. А кому-то и их достаточно и они их на работу берут.
Я могу объяснить все процессы до необходимого в работе уровня
Угу. "До необходимого уровня". Об этом и речь. Вы один уровень считаете необходимым, другие люди другой.
К сожалению не сразу можно понять.
То есть вы ещё и в этом не до конца разбираетесь? Людей, которых вы расстраиваете, становится всё больше и больше :)
До необходимого В РАБОТЕ уровня
И? Вы считаете что один уровень необходим для работы, кто-то считает иначе.
А если ещё учитывать что и работа у разных людей может разная быть...
Конечно.
Непорядок.
Но я учусь на ошибках. В этом разница
Вам ваше белое пальто не жмёт? :)
А почему вы этот самый необходимый вам лично уровень не попытались прощупать у "молодого сотрудника" на этапе собеседования в вашу контору? Может быть ваше описание вакансии целиком и полностью состоит из названий фреймворков, которые необходимо было "знать" для прохождения отбора по резюме?
ну если не знаете плис то как можете себя программистом называть)
а если серьезно - я тоже программист уже 10+ лет. Начинал с асемблера для микроконтроллеров в универе, потом С++ потом ПХП и уже 10+ лет на С#. Сидел и на линуксе какое-то время поначалу. И даже было прикольно поковыряться и потыкаться. Но сейчас я уже взрослый мужик, много чего знаю и я хочу только одного - что-бы то что я хочу чтобы работало как я хочу и не доставляло проблем. С этой точки зрения винда меня полностью устраивает. Меня так же устраивает маджаро на виртуалке чтобы не засорять винду разными фрэймворками. Вот недавно купил макбук эир в качестве мультимедийного и... пришлось привыкать и плеваться. Но вроде притерся, но до сих пор не выбрал бы как рабочую среду)
И по поводу тоны абстракций. Знаете, все все люди в этом мире технари. Есть большое количество людей, скажем так, владеющим словом, или умеющим рисовать. И.... я рад (думаю они тоже), что такие люди могут открыть анрил энжин и просто на блюпринтах наваять игру (да с гуглежом и осваиваниям простых алгоритмов) но им совершенно не нужно для этого знать С++, OpenGL(D3X), работу с пакетами UDP для сетевой игры например. Так что абстракции - не есть зло.
Я понимаю такую боль и принимаю. Я тоже не утверждал что надо городить лишь бы городить. И повзрослев постарев стараюсь выбирать проверенные и знакомые решения.
А когда был молод - я бы тоже с удовольствием прикрутил бы эластик)) Вот серьезно! Мне опыт, задача бы закрылась. Косяк произошел, что за такими молодыми нужны мудрые которые дают поиграться но не заигрываться. (Ну и перед задачей надо создавать спайк на ресерч чем лучше и быстрее решить проблему, но это уже скучный управленческий разговор про процессы)
Мы же не лезем в устройство ТЭЦ что бы узнать как получают электричество для дома?
Ви так говорите, как будто это что-то хорошее.
А я вот в детстве слазил. И в устройство ТЭЦ, и ГЭС, и даже АЭС. И даже модели сделал (как сейчас помню, роль реактора выполняла жестяная банка от болгарского зелёного горошка, в которую были вбиты гвозди-сотки — "топливные" и "регулирующие" стержни).
Передовой линукс дистрибутив
Посоны, кажись Денис вернулся.
Давайте поговорим, все мы люди и можем заблуждаться в чем-то. Какие тезисы вам показались ошибочными?
linux должен быть единственной системой в образовательном процессе
Я бы сделал упор на Unix, включая linux.
В 1987 году в журнале "Техника и наука" была опубликована статья "Операционные системы: зачем они инженеру". Она хорошо согласуется с посылом автора.
Не стоит обходить и стороной другие системы. Школа все такие дает базовые основы, чтобы не теряться в многообразии и не впадать в панику при виде чего-то нового.
Далеко не все станут инженерами, ещё меньшему числу пригодятся какие-то глубинные знания об ОС.
Так что изучение как работает ОС, лучше оставить в программе вузов, техникумов, а не тащить в школьную программу.
Мне кажется, что базовое умение работать с командной строкой вряд ли кому-то повредит.
Мне кажется, что базовое [впишите любое умение по вашему вкусу] вряд ли кому-то повредит :)
Базовое - да, как и в случае с Windows и Mac OS, но базовое - это на уровне, вот командная строка, вне можно запускать программы. Справку о команде чаще всего можно получить так и так. Ну и базовый набор команд типа cd, ls, dir, pwd. Вот на такому уровне - да. Глубже смысла нет, так как забудется.
Так базовое умение работать с командной строкой можно освоить в любой ОС
Принцип работы ОС для юзера не важен вообще, так же как для забивания гвоздей не нужно знать металлургию (как эти гвозди делались), для поедания колбасы - животноводство (как вырастить корову на мясо), для вождения не нужно знать машиностроение и тд и тп. "Машина должна работать, человек-думать".
Отдельно по командной строке - ненавижу! В любом софте. В принципе ненавижу - потому что для работы в ней надо знать и держать в памяти кучу команд, вместо того. чтобы найти пункт в меню. Удачи вам с командной строкой и к примеру, с солидворксом. Умение пользоваться командной строкой для обычного юзера - такой же архаизм, как умение затачивать гусиные перья для письма.
Каждый раз man не назипускаешься. Недаром существует даже отдельный tldr, потому что документацию того же tar можно использовать как чтиво не на один вечер
Да-да, прям как в старой шутке :-)
Нужно выполнить всего три команды, чтобы поставить Gentoo
<@insomnia> Нужно выполнить всего три команды, чтобы поставить Gentoo
<@insomnia> cfdisk /dev/hda && mkfs.xfs /dev/hda1 && mount /dev/hda1 /mnt/gentoo/ && chroot /mnt/gentoo/ && env-update && . /etc/profile && emerge sync && cd /usr/portage && scripts/bootsrap.sh && emerge system && emerge vim && vi /etc/fstab && emerge gentoo-dev-sources && cd /usr/src/linux && make menuconfig && make install modules_install && emerge gnome mozilla-firefox openoffice && emerge grub && cp /boot/grub/grub.conf.sample /boot/grub/grub.conf && vi /boot/grub/grub.conf && grub && init 6
<@insomnia> это первая
ИСТОЧНИК: https://linux.ru/forum/topic/170141-нужно-всего-три-команды-чтобы-поставить-gentoo/
зачастую это превращается в полчаса чтения мана вместо трех нажатий мышки, и это явно не самый нужный навык для большинства пользователей
зачастую это превращается в полчаса чтения мана
Но ведь эти полчаса — они нужны только один раз. Вас же не раздражает, что, скажем, за руль автомобиля пускают только после сдачи экзамена,
а не как у Незнайки?
— Дайте мне поездить на автомобиле! Я тоже хочу рулить и дудеть.
— Тут дело не в том, чтоб рулить и дудеть, — сказал Винтик. — Прежде всего машину изучить надо, понять, что и как работает.
— А чего там ещё изучать! — ответил Незнайка. — Дёргай за ручки да верти руль — вот и вся наука. Сел — и поехал.
Оно обычно как бывает - понадобилось сделать что-то с программой, загуглил/почитал мануалы, все понял, разобрался, заработало... И в следующий раз эта задача возникает через полгода, когда уже все аргументы забылись и снова идти ковыряться в манах и тратить время. Вместо того, чтобы кликнуть какой-нибудь очевидный File->DoSomething.
Проблема, в том что пользуешься ты этим раз в год, а читаешь документацию полчаса, а для пользования приложением на гуи, зачастую читать документацию не нужно. Я надеюсь не нужно доказывать, что в PartitionMagic можно разобраться впервые его увидев, впервые увидев DiskPart, придётся очень долго вникать. А разбивать диски, среднему пользователю придётся как раз в лучшем случае раз в пятилетку.
Я надеюсь не нужно доказывать, что в PartitionMagic можно разобраться впервые его увидев
Хотел вот в PartitionMagic отформатировать один раздел размером в 3 TB под FAT — почему-то не получилось. Пришлось разбираться!
Ясное дело, что какие-то знание для пользования программы нужны, и с такой-же проблемой вы бы столкнулись и DiskPart. Я о том, что увидев любое гуи для разбивки диска я потрачу пару минут на освоение и на необходимые мне манипуляции. А каждый раз сталкиваясь с DiskPart я гуглю как им пользоваться и курение мануалов занимает все десять двадцать минут, хотя я не единожды с ним уже работал.
Но ведь мы в итоге и пришли к ситуации "сел и поехал". ТИповому водителю совершенно не нужно знать, что и как работает. Ему достаточно запомнить относительно несложные правила пользования - осмотреть машину перед поездкой, заводить вот так, прогреть до температуры такой-то, заправлять таким-то топливом, вот сюда лить омывайку, раз в две недели посмотреть уровень вот в этих бачках и померить давление в колесах. Регламентное обслуживание по сервисной книжке. Если что-то не так - обратиться в сервис. А дальше - опциональные знания для тех, кто хочет на этом сервисе экономить (и которые со временем всё равно придут).
Если что-то не так - обратиться в сервис
Если Вы миллионер — то, конечно, да.
Смотрю на свой ланос 2012-го года, который вчера забрал из местного "сервиса" в гаражах, где мне аж за 500 рублей и полчаса поменяли колодки (с чем я бы сам возился полдня, угваздавшись по уши и задолбавшись на неделю вперёд), и понимаю - да я миллионер!
Ну извините, не все живут в гребенях, где дядя Вася за бутылку при помощи кувалдометра и известной матери может починить проблему в контроллере зажигания. В цивилизованных локациях тот же сервис может легко вылиться в несколько сот (а то и тысяч) вечнозелёных.
Живу в Москве, чиниться ездил в ближайшее Подмосковье. Не, ну, наверное, это тоже можно назвать гребенями; гребеня - вообще категория плохо формализуемая.
Но вы тогда сразу ставьте граничные условия. А то сначала "сервис - это для миллионеров", а теперь вон какие-то "цивилизованные локации" появились. Это какие, кстати?
А вообще изначально речь шла о том, что современный GUI похож на современный же автомобиль - надо знать несколько базовых действий, а что там под капотом - вообще неважно; если что, помогут специально обученные люди. И вот с этим как раз трудно спорить)
если что, помогут специально обученные люди
Так и я про то же говорил: конечно же, помогут. Конечно же, за мзду малую немалую. Потому что бабло, заплаченное за специальное обучение, надо отбивать.
Вы к врачам ходите? Деньги немалые отдаете. Учитесь и оперируйтесь сами. И еду сами на полях выращивайте. и дома сами из камней да бревен стройте. И машину покупать ни в коем случае нельзя - вы так переплачиваете. сделайте ее сами из металлопроката. А металлопрокат покупать тоже нельзя - самим руду копать, домну строить и плавить. Ату этих дармоедов всех... Вперед, в пещеры, к охоте и собирательству.
Ну так примерно и есть. Что могу — делаю сам. Что не могу — нанимаю. А могу я мнооооогое...
P.S. О врачах — больная тема.
Лучше бы не ходил, потому как за большие деньги прошёл кучу анализов и обследований с финальным ответом "а хрен его знает, что у вас там такое — все анализы в порядке", в то время как подруга детства (тоже врач) мельком взглянула на МРТ-скан и совершенно забесплатно посоветовала взять подушку пониже — и, йокстель, именно это и помогло!
Да ради бога, пусть берут. Если я могу вместо ползания под машиной в лужах масла ( = ковырянию в реестре/конфигах/компиляторе) отдать стоимость примерно пары часов своего рабочего времени, а сам попить кофе и получить работающую машину ( = программу) - это ж хорошо! Затем и работаю, чтобы мне было удобно и приятно.
Затем и работаю, чтобы мне было удобно и приятно.
Угу, сначала "лучше заплачу грузчикам, пусть они мне перегрузят всю мебель", а потом "чтой-то я жирком оброс — пойду заплачу за тренажёрку".
Или когда у Вас машина заглохла в непонтяных гребенях, где до ближайшего автосервиса (да и вообще цивилизации) 100 км по буеракам — лучше, конечно, не знать, как самому починить, а кому-нибудь заплатить, ага.
Если б всё в жизни можно было предусмотреть заранее — это было б восхитительно. Но увы. Поэтому чем больше я знаю — тем из большего количества задниц я смогу выбраться в рекордно короткие сроки. И не потому, что я смогу сделать это лучше признанного специалиста — а потому, что мне не придётся ждать признанного специалиста.
чем больше я знаю — тем из большего количества задниц я смогу выбраться в рекордно короткие сроки
А зачем вы в эти задницы попадаете?
когда у Вас машина заглохла в непонтяных гребенях
Значит вы за машиной не следите. Вызывает сомнение, что вы сможете починить ее в гребенях, если у вас не получилось сделать, чтобы она не глохла, в гараже.
:D
А зачем вы в эти задницы попадаете?
Ну, как бы, справедливого мира нет — дерьмо не просто случается, оно обязательно случится с каждым, и не раз.
Крайне здравый подход.
А зачем вы в эти задницы попадаете?
Сколько я ни просил окружающий мир не загонять меня в задницы — он ни разу не послушал.
Значит вы за машиной не следите.
Ну вот тут недавно парни за машиной следили-следили, а она раз — и сломалась. "Титаном", кажется, звали.
За Титаном парни как раз не следили. Поверили в то, что ихний автоматический контроль целостности поможет, и всякая рентгеноскопия им не нужна А может просто поверили что это Toyota, она не ломается.
За Титаном парни как раз не следили.
Ну это Вы так считаете. А они считали иначе. Регулярно лобовуху протирали и по шинам стучали.
И даже запасные батарейки к джойстику в бардачке были ;)
Но шансов на выбирание из задницы это не добавило ..
Регулярно лобовуху протирали
и по шинам стучали.
То есть что-то знали об обслуживании ;)
Ну, допустим, залили вы в свой жып, будучи в диких гребенях, ослиной мочи, и он больше не едет. Вы всегда с собой возите ультразвуковую промывалку?
Это называется специализация. Один из факторов прогресса.
Незнайка писался в 50-х годах, когда для вождения автомобиля требовалось знать его устройство, потому что он мог легко сломаться где-то посреди дороги, а эвакуаторов еще не придумали.
Если не путаю, тогда и экзамены по устройству сдавали. Сейчас это не нужно.
В милой доброй гуёвой 1С ERP 300+ документов и 300+ справочников (плюс столько же настроечных констант, но в них хоть не каждый день лазить надо)
Да, каждый отдельный пользователь (если их 10+) работает с 20 видами объектов, не больше. Но я как служба поддержки 3 уровня всё это достаю через поиск по строке в полном меню "технического специалиста" (офф название в платформе).
То есть фактически из командной строки. Так как ветвистые меню + отдел двигания кнопки убивают все ваши мечты о трех нажатиях.
Запускаем man узнаем, что нужной информации там нет или не актуальна или же количество опций 100+ и это прямо томик войны и мир.
Отдельно что при любой опечатке можно долго и упорно не понимать где проблема.
Общение между программой и пользователем должно быть строгим с нормальным интерфейсом, проверкой ввода и наглядным
Как будто нужные команды не различаются между версиями/дистрибутивами...
По поводу команд - залоченные по фьюзам AVRки передают привет - ведь в одном программаторе прошитый фьюз - 1, а в другом - 0. А уж если взять что-то посложнее фьюзов, ну например среду прошивки от Altera, там констрейны вообще свой синтаксис имеют, да, в командной строке, но я вот, например на этом застрял и забил.
Ну и количество менюшек в одной программе конечно, в отличие от того. что можно набрать в консоли.
а что нужно изучать заново при минимальном изменении интерфейса? По-моему, вообще ничего не нужно.
Есть софт, где от версии к версии очень любят перекладывать кнопки в менюшках. Но это скорее экзотика
Не понимаю каким образом админ, которому был непривычен новый интерфейс и "многие", для которых был "болезненным" переход с менюшек на ленту в офисе иллюстрирует "объем того, что "нужно изучать заново при минимальном изменении интерфейса" (я так понимаю, что такой формулировкой вы намекали на то, что изучать придется очень много). Т.е. похоже, что большинству людей особо ничего заново изучать и не придется.
Я задрался в разных виндах искать куда они переменные среды перепрятали. Точнее финальная кнопка то в одном окошке, но его двигают — только в путь. Уж не говоря о том, что это вообще не логичное окошко для этой кнопки.
ну так делайте через cmd. CMD всегда в одном и том же месте.
В "новых" виндах такие вещи относительно просто находятся через поиск.
Пуск — sysdm.cpl, дальше путь вам должен быть известен )
Со времен винтукея работает везде одинаково.
sysdm.cpl это точно вы меня гую учите?
Гуй это правой по "мой компутер"-Свойства — дополнительные параметры системы-переменные среды. на моей актуальной.
На не актуальной то ли по свойствам сразу окно "свойства системы" открывалось и надо было на вкладку "дополнительно" идти, толи не помню как.
Гуй это правой по "мой компутер"-Свойства
Точно так же гуй это нажимаем на иконку с увеличительным стеклом -> вводим "переменные среды" -> выбираем нужное в списке(у меня даже сразу в самом верху) ->профит.
И конкретно в этом случае максимум что надо "переучивать" это местонахождение иконки.
нажимаем на иконку с увеличительным стеклом -> вводим "переменные среды"
И чем это отличается от "нажимаем на иконку с надписью CMD, вводим...."?
Вот дополнительные параметры системы — это sysdm.cpl и есть
можно даже сразу начать вводить environment. Откроется нужно окошко, открытое на нужной вкладке. Правда, подсвечена неправильная кнопка, к сожалению.
Есть же просто кнопка Win на клавиатуре.
Win => печатаем "Env" => получаем результат.
Это если у вас винда англоязычная. В русской надо печать "пере..."
Иначе только в инете поискать предложит.
Но есть и обратные примеры
Hidden text
Ну тут какая картинка была, такая и была. Да и по роду деятельности ffmpeg команды мне чаще приходится городить, чем awk использовать
без filter_complex оно конечно проще, но и много чего не сделаешь без этого ужаса
так awk же простой на самом деле
ну регулярки то точно простые. Их просто неправильно учат
В регулярках неудачный синтаксис. Сравните со Сноболом, который делал то же самое гораздо понятнее.
Не соглашусь.
В регулярках вполне логичный синтаксис, во всяком случае любому, кто знаком с ассемблером или различными парсерами, - понятно почему он такой.
В то время как Снобол, это не паттерн, это просто целый отдельный язык с функциями обработки текста. Тогда можно уже и просто с перлом сравнивать, или с полным набором substr, index, sort.
Встроить в любой язык PCRE все же дешевле чем встроить Снобол или какой-нить lua.
В регулярках вполне логичный синтаксис
Он логичный, но это не мешает ему быть неудачным и выглядеть визуальным мусором без структуры.
просто целый отдельный язык
Именно как язык Снобол устарел уже к 70-м годам даже в глазах авторов. Но вот та часть, что обрабатывает строки, до сих пор выглядит куда лучше РВ.
Интересно, а в гуи такое возможно сделать в принципе?
Можно, но сначала его придется написать ))
И вот, в скором времени, вместо одной просто программы надо установить полсотни оберток, каждая из которых умеет часть возможностей дергаемого под капотом оригинала…
Нет, на самом деле, продвинутый оберточный софт позволяет указать опции командной строки. Но это из серии даже не знаю, что хуже.
можете посмотреть любые гуи к ffmpeg. эта команда, в целом, выглядит гуманнее.
а что эта команда вообще делает?
я совсем не настоящий ффмпегер, но сдается мне, этот фильтр "накладывает" четыре видео друг на друга, чтобы получилось - на заднем фоне видео 1280x720, на нем по центру 640x360, еще сверху - 480x270, ну и самым "верхним" - 270x180. еще и чтобы появлялись не одновременно, а с задержкой в секунду.
омг. почему-то мне кажется, что в гуе это накручивается как минимум не медленнее.
А вот для каких-то простых задач, типа отделения видео от звука или создания скриншота на определенном таймкоде в куче файлов подряд — это как раз проще в ffmpeg. У меня под него даже целая папочка с bat-никами лежит на разные случаи жизни.
Операции с кучей файлов — это к нему.
Ну есть же разные инструменты. Одни используешь каждый день, другие раз в неделю, а третьи - один раз в год или вообще один раз.
Первые нужно знать досконально. Команды, опции, особенности, баги... Можно в консоле как хакер десятипальцевым печатать, можно в гуях шоркаты настроить или выучить. Точнее не можно а нужно.
А вот со вторым типом, а тем более с третьим - такое не прокатит, все шоркаты команды и опции тупо забудутся. И нормальный UI здесь просто незаменим. Особенно если и разработчики UI понимают что их программой пользуются нечасто, и дают пользователю достаточно инфы в процессе.
У майрософт кстати была где то статья по индуктивным интерфесам, где они это все примерно так и описывали
Зачем нужен состав на этикетке продукта? Что бы знать что ты употребляешь в пищу. Мы можем его не прочитать, но найдется служба которая занимается контролем за этим процессом, что бы мы были уверены в своей еде.
Так же и с программами, не всем надо знать как они работают, но лучше иметь доступ к составу, иначе производитель может подмешать разной химии.
В идеале оно так, а на практике состав не всегда детализуют, особенно у не-пищевых продуктов. Запросто может быть написано "добавки" без пояснений. Опять же, можно ли гарантировать, что состав на этикетке полностью честный?
К сожалению, это уже давно не работает так со сложными программными продуктами. С какой-то простой софтинкой, да, это всячески полезно. А вот опенсурс для сложных продуктов имеет и минусы, которые уравновешивают его плюсы. Увесистость кодовой базы позволяет вредному мейнтейнеру упрятать в нём аккуратный эксплойт и не ожидать, что его сколь-нибудь быстро обнаружат. И даже если мейнтейнер был не вредный, а сделал это нечаянно - с одной стороны, любой желающий может посмотреть, проверить и найти уязвимость, а с другой стороны, любой желающий может посмотреть, проверить, найти уязвимость и использовать её в своих целях. И самое неприятное, что вторым платят за это больше. Первые в основном делают это из любопытства и волонтёрских побуждений, вторые - целенаправленно и на профессиональной основе.
Это пока все ваши задачи такие же, как у всех остальных пользователей. Шаг влево или вправо и идёшь лесом.
Мне не так двано одна инспекторша пожаловалась, что ей понадобилось рассортировать фотоотчёты за несколько лет по объектам, а поскольку геопозиции в большинстве фоток нет, то ориентироваться можно только по датам из списка в Excel. Она сначала несколько дней расспрашивала по форумам о подходящей программе, а потом ещё несколько дней мышью сортировала свои фото, пользуясь только поиском в проводнике.
Я бы эту задачу в PowerShell сделал за час-два. И то только потому, что я в нём не очень. Командная строка - если правильно спроектирована - позволяет комбинировать инструменты способами, о которых их разработчики даже не задумывались. В этом их сила. Но при этом пользователь нихрена не сможет сделать в коммандной строке, если будет вспоминать о ней только когда всё остальное не поможет.
Так это потому что Вы знаете павершелл
А если чел знает питон, он бы питоном этот вопрос решил.
а если знает VBA, то с помощью VBA
а если чел преподает у школьников или студентов, то этих "муравьишек" можно было напрячь и они за урок рассортировали (главное, правильно распределить усилия)
список можно продолжать и дальше. В целом, кому как удобнее, так и делает. И тут нет какого-то единственно правильного решения
/ Удачи вам с командной строкой и к примеру, с солидворксом.
Кстати, да! СолидВоркс ни на Маке, ни на Линуксе не работает. Да и вообще на Линуксе КАД-систем, как говорится, днём с огнём. Как они пласт инженеров собираются обучать, которые и мышку, и клавиатуру им проектируют. Создавать с нуля математические ядра... годы и годы, если кто-то группой из уникальных математиков мира согласится взглянуть на Линукс, но за бесплатно этого точно не будет.
Так проблема не только в САПРах, а ещё и в куче проектов и всей документации, которая в них сделана. Кто это всё будет переносить и за чей счёт?! Кто и за чей счёт будет писать новые САПРы, когда и сейчас очень тяжело идёт стыковка реальных пользователей из конструкторов и программистов, поскольку последним тяжело даже поверхностно понять процессы проектирования?! А главное, кто будет обучать всему новому, если этого не организовать за год-другой?! А кто будет поддерживать уже существующие проекты?!
Вопросов много, но идеологам не до реализации.
к примеру, с солидворксом
а вот в автокаде прям царская командная строка, очень удобно
Поучавствуйте в хоть одном турнире спидмоделинга, тогда поймёте, что АвтоКАД даже часть задач решить не может, не говоря о том, что в построении моделей он никем в здравом уме пользоваться не может, а главное, самой AutoDesk не нужно было бы выпускать свой Inventor вслед за поездом SolidWorks.
Отдельно по командной строке - ненавижу! В любом софте. В принципе ненавижу - потому что для работы в ней надо знать и держать в памяти кучу команд, вместо того. чтобы найти пункт в меню.
Для поиска нужной фичи в меню надо пролезть половину меню и прочитать все что там есть и так каждый раз, когда что-то ищешь, а в командной строке достаточно сделать что-то типа ls --help | grep author чтобы вспомнить нужный ключ моментально. Что-то найти, например, в либре/мс офисе получается подавляющем большинстве случаев только загуглив. Т.к. очень часто нужного нет в меню, а есть оно в окне, который открывает весьма неочевидный пункт меню.
потому что для работы в ней надо знать и держать в памяти кучу команд
А кучу гуевого софта с их кучей меню, окон, окон открывающихся из окон держать в памяти не надо, ага..
Удачи вам с командной строкой и к примеру, с солидворксом.
В автокаде была встроенная консоль и с ней часто быстрее получалось работать. Про солидворкс не в курсе, но практически уверен, что там тоже есть.
потому что для работы в ней надо знать и держать в памяти кучу команд, вместо того. чтобы найти пункт в меню.
...и именно поэтому я побеждал на олимпиадах: пока остальные искали пункты меню, я успевал вбить с пяток команд в комстроку — в результате у меня чертёж готов, а остальные всё ещё ищут.
Удачи вам с командной строкой и к примеру, с солидворксом.
В своё время строил довольно сложную геометрию (компрессорная лопатка авиадвигателя) в ANSYS, пользуясь встроенным языком. То есть, по сути, закидывая файл с пачкой команд в командную строку.
Когда речь о каких-то простых моделях, где надо несколько раз менять геометрию до достижения оптимального результата - или, наоборот, модель настолько сложная, что графического интерфейса не хватает - командная строка до сих пор актуальна.
Вот например у меня есть код для расчёта развесовки двигателя на опорах. И таких тел - несколько от разных заказчиков, при этом компоновка похожая (эн опор в ряд, на некотором расстоянии от них второй ряд). Я смотрю габаритный чертеж, читаю с него расстояние между опорами и положение центра масс относительно них, забиваю эти числа в свой код, туда же вношу данные по жёсткости опор - и через минуту у меня есть данные о нагрузке на каждую опору. Ещё минута - и собственные частоты с формами колебаний на этих опорах. В графическом интерфейсе это будет дольше, проверено.
Да, можно сказать, что это не командная строка как таковая, а скорее выполнение программы. Соглашусь. Но и командной строкой пользовался регулярно. Потому что различных команд ОЧЕНЬ много, и найти нужную в графическом интерфейсе зачастую дольше, чем забить руками. Например, создание точки: k,n,x,y,z создаёт вам точку с номером n и указанными координатами. Это быстрее, чем продраться через дерево Preprocessor>Modeling>Create>Keypoints>In Active CS и всё равно вбивать руками номер точки и координаты. А уж когда вам надо создать десять точек, расположенных по известному закону - то проще написать цикл (в notepad++ и закинуть в командную строку), чем вбивать 40 чисел. Разумеется, работает это только в случае, если часто пользуешься какой-то командой и помнишь её наизусть. Но именно при частой работе с командой экономия времени на каждой операции и получается значительной.
В графическом интерфейсе это будет дольше
А что, вы в графическом интерфейсе какие-то другие кнопки нажимаете, чем когда в командную строку печатаете?
и помнишь её наизусть. экономия времени на каждой операции и получается значительной
Если посчитать время и деньги на это «наизусть», обычно в итоге не экономия получается, а слёзы. Если б было иначе, gui не вытеснил бы командную строку практически повсеместно.
А что, вы в графическом интерфейсе какие-то другие кнопки нажимаете, чем когда в командную строку печатаете?
В графическом интерфейсе их нужно нажать больше, чем при наборе команды в строке. Я работал и так и так, мне есть что сравнивать.
Если посчитать время и деньги на это «наизусть», обычно в итоге не экономия получается, а слёзы.
Так их не надо специально учить. Любая сколь-нибудь сложная модель (говорю сейчас за классический ANSYS Mechanical) всё равно создаётся и исправляется набором команд, а не через графический интерфейс. Поэтому команды со временем заучиваются сами, и когда вы таки работаете в графическом интерфейсе - их можно быстро вспомнить и вбить, а не искать по дереву.
Далеко не повсеместно. В программировании, например, не вытеснили не вытеснит.
Поэтому чем больше задача похожа на программирование, тем командная строка удобнее.
Это континуум, зависящий от задач.
То есть вы ваш код прямо в командной строке набираете? Или всё-таки пользуетесь хотя бы редактором, а может даже и IDE? :)
Боюсь про однострочные редакторы типа EDIT.SAV или EDLIN.EXE мало кто из них знает.
А это не фоточки сортировать :)
Вы немного не уловили аналогию. Программирование по-прежнему остается текстом. Командная строка - тоже текст и тоже разновидность программирования.
Ну во первых нет. Программирование совсем не обязательно остаётся текстом. По крайней мере не больше чем "программирование по прежнему остаётся набором нулей и единиц".
А во вторых с таким же успехом тогда "компонование" команд в графическом редакторе(тот же LabVIEW например) это тогда тоже разновидность программирования. И я посмотрю как вы будете создавать модули под LabVIEW в командной строке :)
Графическое программирование существует. Но это именно что узкая специализированная ниша (или даже ниши).
Сегодня ниша, завтра не ниша. Когда-то вон на перфокартах программировали и ваш "командная строка" нишей была.
Идеи графического программирования периодически реанимируются уже лет тридцать как. И так же периодически пропадают. Так что я бы особо на них не рассчитывал.
Зато IDE используется всё больше и больше и имеют всё больше и больше "графических элементов" и всевозможных редакторов.
А командная строка и терминалы скорее наоборот используются всё меньшим процентом людей.
Иде это такое? я пока все больше обратный поток вижу: plantUML всякий со товарищи. То есть то, что раньше было графикой или бинарником — становится кодом. А решения типа Rational Software Architect Designer как появились в конце 90х, так и остались нишевыми продуктами.
То есть то, что раньше было графикой или бинарником — становится кодом.
Так а код то откуда берётся? Его весь пишут ручками в командной строке?
Где хотят, там и пишут. Мы вроде обсуждаем текстовое управление компом против графического. Текстовое рулит.
А вот удобный вывод информации — в рамки терминала не помещается. Даже если он будет текстом — удобнее разложить его на несколько окон.
Где хотят, там и пишут. Мы вроде обсуждаем текстовое управление компом против графического
Мы обсуждаем "командная строка/терминал" vs "графический интерфейс". В принципе.
То есть если совсем грубо, то либо всё в через командную строку, либо всё через GUI.
П.С. И да, логичнее использовать и то и другое. Но спор не о том :)
ИДЕ - это ведь не язык, а лишь костыль к языку, слегка нивелирующий сложность программирования на последнем.
Сегодня ниша, завтра не ниша. Когда-то вон на перфокартах программировали и ваш "командная строка" нишей была.
Неудачная аналогия. Графическое "программирование" существует уже достаточно долго чтобы обнаружить и достоинства, и недостатки. Для мало0мальски сложных проектов недостатков оказывается больше. Но для "примитивной" автоматизации — почему бы и нет.
Хм. А командная строка она часто используется для "мало0мальски сложных проектов"? Или в основном тоже для "примитивной" автоматизации? :)
Так это вы замахнулись в этой ветке на программирование, а не примитивную автоматизацию.
А по сути — да, пока интерфейс помещается на экране, край разворачивается в подменю один раз — графика выигрывает. С ростом сложности — не скейлится, текст становится проще в понимании.
Так это вы замахнулись в этой ветке на программирование, а не примитивную автоматизацию.
Ну так тут идёт сравнение "графического программироаания" и "командной строки".
С ростом сложности — не скейлится, текст становится проще в понимании.
Не вижу принципиальной разницы. В том же LabVIEW вы можете запихать всё что помещается на экране в отдельный блок и потом уже использовать его. Точно так же как с текстом.
С ростом сложности — не скейлится, текст становится проще в понимании.
Но́ при чем тут командная строка? Простыню исходников в IDE вижу, командной строки и консоли не вижу ;)
А командная строка она часто используется для "мало0мальски сложных проектов"? Или в основном тоже для "примитивной" автоматизации? :)
В основном для примитивной автоматизации, конечно. Когда админу надо именно что склеить кучку существующих команд в одно целое. Если нужно что-то совсем сложное, синтаксис того же bash'а начинает мешать, и проще написать код на нормальном языке программирования.
Но, как вы понимаете, претендовать на эту нишу графические языки не могут.
Как раз на эту нишу великолепно претендуют всякие LabVIEW/Teststand и иже с ними. И вполне себе успешно.
Особенно учитывая что они без особых проблем поддерживают интеграцию различных скриптовых языков, библиотек, исполняемых файлов и так далее и тому подобное.
На нишу системной автоматизации, которая зачастую проводится вообще без графического режима (потому что серверу он не нужен)? Ну-ну.
Вообще, идея у Labview интересная, но то ли реализация подкачала, то ли сам подход графического программирования нежизнеспособен. Например, сложно свой "код" показать другому человеку, сложно использовать системы контроля версий, невозможно охватить весь код взглядом (приходится кликать по вкладкам switch'ей), сложно создавать функции и комментарии. Я когда-то составлял целый список недостатков Labview.
Слепить десяток приборов чтобы не-программист мой что-то автоматизировать — да, годится. Но когда нужно что-то более сложное, увы, нет.
оторая зачастую проводится вообще без графического режима (потому что серверу он не нужен)? Ну-ну.
Ну во первых так графический режим во время собственно исполнения не обязательно нужен.
Но да, они в основном используются в лабораториях и для автоматизации различных тестов. Например в автоиндустрии .
Слепить десяток приборов
Вот именно что он позволяет с железом работать.
Ну во первых так графический режим во время собственно исполнения не обязательно нужен.
Насколько я знаю, его вообще скомпилировать возможно, там не то что графика, там даже среда интерпретации не нужна. Но как вы отлаживать-то будете или подстраивать под конкретное железо?
Но да, они в основном используются в лабораториях и для автоматизации различных тестов.
Ну да, у нас в лаборатории эта штука и используется, я с нее постоянно плююсь: крайне неудобная среда. А уж что с ней не-программисты вытворяют… как вам десяток sub-vi для записи результатов измерения: отдельно для таблицы из 2 столбцов, отдельно для таблицы из 3, 4 и так далее. Терпения хватило до 11-столбцовой, если я правильно помню.
В общем, недостатки Labview я могу перечислить без проблем. Что объективные, что субъективные, что фундаментальные.
Ну так и недостатки консолей/терминалов тоже уже немало озвучили. Что субъективных, что объективных.
И самое интересное что графический интерфейс вполне себе может включать в себя и терминал/консоль. И это встречается сплошь и рядом. А вот чтобы наоборот я пока ни разу не видел :)
Ну так и недостатки консолей/терминалов тоже у
Стоп. Мы сейчас программирование обсуждаем или интерфейс CLI/GUI? Потому что сравнивать Labview с терминалом это все равно что сравнивать барашка с нотами.
И самое интересное что графический интерфейс вполне себе может включать в себя и терминал/консоль. И это встречается сплошь и рядом. А вот чтобы наоборот я пока ни разу не видел :)
Ну, я видел. Во-первых, дурацкая мода учить школьников рисованию поверх окна cmd. Во-вторых, всякая ASCII-графика вроде hasciicam или vlc. Но это, конечно, для фана, а не для повседневного использования. Ну и вывод картинок в framebuffer прямо поверх консоли. vlc так, кстати, тоже умеет.
Другое дело, что если уж у пользователя возникает необходимость в GUI (а она возникает почти всегда), и он все равно работает в оконной среде, так проще не плодить сущности.
Стоп. Мы сейчас программирование обсуждаем или интерфейс CLI/GUI
Ну я так понял изначально речь шла о программированнии при помощи командной строки:
Поэтому чем больше задача похожа на программирование, тем командная строка удобнее.Командная строка - тоже текст и тоже разновидность программирования.
Ну, скрипты это ведь запись тех же команд, которые запускают руками, в файл. Ну то есть надоело вам раз за разом вбивать какую-то последовательность команд — завернули в скрипт и вызываете его.
Но Labview на такой механизм не ложится: это ведь не интерфейс управления операционкой. Сюда уж скорее кликеры подошли бы. Но, думаю, понятно, почему они неудобны.
"Заворачивать в скрипт" можно уже и в IDE :)
При чем здесь "можно и в IDE"? Вы же не IDE в скрипт заворачиваете, а консольные команды.
Ну так я и не IDE обычно запускаю, а написанные в нём программы.
Но и в том и другом случае я использую графический интерфейс вместо консоли.
Да и запускать скрипты и программы можно при помощи графического интерфейса. И даже прямо в IDE часто можно.
Что-то я совсем потерял вашу мысль. Вы что опровергнуть-то пытаетесь?
Что работа в консоли это программирование что ли? Так с этим бесполезно спорить.
Что программирование это работа в консоли? А такого никто особо и не утверждал.
Вот это:
Поэтому чем больше задача похожа на программирование, тем командная строка удобнее.Командная строка - тоже текст и тоже разновидность программирования
Здесь два тезиса. Что чем больше задача похожа на программирование, тем удобнее командная строка. И что работа в командной строке является разновидностью программирования. Вы оба опровергнуть хотите?
И что работа в командной строке является разновидностью программирования.
Примерно настолько же, насколько работа в UI является разновидностью 3D-моделирования.
То ли у вас весьма экзотическое представление о программировании, то ли о 3D-моделировании...
Любая работа в современной консоли является программированием, но не любое программирование — работой в консоли.
А вот что общего у 3D-моделирвоания и управления системой я не знаю. Даже наличие UI обязательным не является, модель можно и аналитически задавать.
Любая работа в современной консоли является программированием,
То есть если я кликнул на батник и он выполнился в консоли, то это уже программирование? Тогда у нас в бухгалтерии например одни программисты сидят :)
А в батнике по-вашему что записано? Программа для шелла.
Ну и работа в консоли это все же несколько больше, чем запуск одной программы без параметров.
Так что да, если у вас в бухгалтерии народ регулярно пишет батники, они в некоторой степени программисты.
А в батнике по-вашему что записано? Программа для шелла.
Но записать то её может кто-то другой.
Ну и работа в консоли это все же несколько больше, чем запуск одной программы без параметров.
Тогда можно точное определение "работы в консоли"?
Так что да, если у вас в бухгалтерии народ регулярно пишет батники, они в некоторой степени программисты
Они их не пишут. Они их запускают.
Более того пару человек даже научили отдельные команды напрямую выполнять. Как обезьян научили. Без понимания того что они делают. Это по вашему программироаание? С моей точки зрения нет.
Тогда можно точное определение "работы в консоли"?
Вот изобретать определения не возьмусь.
Они их не пишут. Они их запускают.
Тогда при чем тут работа в консоли?
Ну и работа в консоли это все же несколько больше, чем запуск одной программы без параметров.Более того пару человек даже научили отдельные команды напрямую выполнять. Как обезьян научили. Без понимания того что они делают. Это по вашему программироаание? С моей точки зрения нет.
Мне точно надо повторять ответ?
Тогда при чем тут работа в консоли?
В смысле? Они запускают батник в консоле и тем самым выполняют свою работу. То есть работают в консоли.
Мне точно надо повторять ответ?
Да. Потому что тут мы уже имеем запуск разных программ и иногда даже с параметрами.
И вроде бы даже некоторые это наизусть выучили, а не с бумажки списывают. Но тут уже ручаться не буду.
В смысле? Они запускают батник в консоле и тем самым выполняют свою работу.
Я там чуть ниже уточнил, что скорее всего возникло непонимание из-за терминологии. Я под "работой в консоли" в данном контексте понимаю не запуск одной программы и работы в ней, а именно работу в консоли операционной системы. Там весь принцип работы в вызове разных утилит и объединении их хотя бы в конвейер, а то и в более сложные структуры — циклы, рекурсии.
Я под "работой в консоли" в данном контексте понимаю не запуск одной программы и работы в ней, а именно работу в консоли операционной системы
А чем одно отличается от другого? Ну то есть как границу проводить?
Для меня если человек что-то делает в консоли, то он в ней работает.
Там весь принцип работы в вызове разных утилит и объединении их хотя бы в конвейер, а то и в более сложные структуры — циклы, рекурсии.
Неа, там весь принцип работы в вызове разных утилит. И всё. Самое сложное, что используется более-менее часто некоторыми пользователями, причём ИТ-шных специальностей, это грепнуть чей-то вывод или там пропустить его через море. Циклы, рекурсии, это уже узкопрофессиональная специфика. А в остальном консоль - это просто запуск софта и эпизодический файловый менеджмент для тех, кому лень ставить мс или фар2л, и не более того.
Ну вот грепнуть вывод уже более-менее похоже на программирование.
Циклы… ну я их использую достаточно регулярно если надо что-то сделать с кучей файлов. Или вот интереса ради смотрел сколько строк кода у меня в одном проекте.
find . -maxdepth 3 -name "*.[chS]" -exec cat '{}' \; | wc -lЧто, не похоже на программирование?
Что, не похоже на программирование?
Чуть ближе, но вот смотрите: знаете, сколько раз я в жизни запускал find с exec для пакетной обработки чего-либо? Ноль. Т.е. вообще, никогда. Я не могу представить даже, зачем мне это когда-либо понадобилось бы. Пакетная обработка файлов, это чисто профессиональное применение, когда вы там или что-то единообразное в свою коллекцию каталогизируете, или какие-то рабочие данные выкатываете. И знаете, чуйка подсказывает, что среднестатистический пользователь консоли, это я, а не вы.
знаете, сколько раз я в жизни запускал find с exec для пакетной обработки чего-либо? Ноль.
То есть вы утверждаете, что практически не работали в консоли операционной системы?
То есть вы утверждаете, что практически не работали в консоли операционной системы?
-Я не ем квашеную капусту
-То есть, вы утверждаете, что практически ничего не едите?
Вот как-так вы мне возразили.
И я, честно говоря, не понял вашей логики тут. Или вы так намекаете, что find+exec - это сколь-нибудь часто востребованная комбинация команд? Нет, это очень специфическое применение, для пакетной обработки файлов, которым пользуются единицы из легионов - в основном, те редкие чуваки, у которых умение пользоваться командной строкой сочетается с серьёзным занятием фотографией или ещё каким-то хобби или профессией, которая генерирует много единообразного контента... ну, не знаю, музыка, может быть, исследования какие-то, даже сложно придумать.
find+exec — это сколь-нибудь часто востребованная комбинация команд?
Ну вы же привели ее в пример. Хорошо, пусть не эта конкретно, а любая другая комбинация для пакетной обработки. Если из всех возможностей консоли использовать только вызов одиночной программы — это не работа в консоли, это работа в той самой программе.
Хорошо, пусть не эта конкретно, а любая другая комбинация для пакетной обработки
Какая, например? find + exec предложили вы, я просто принял это как один из немногих консольных кунштюков, где присутствует настоящий цикл. А так, единственные повсеместно встречающиеся пакетные обработки - это что-то вида "перенести файлы из одного каталога в другой", или там "удалить файлы по маске". Но это тоже не программирование :)
это не работа в консоли, это работа в той самой программе.
Ну, тогда в консоли практически никто не работает :) Для меня запустить какую-то программу и узреть её результат в консоли, это вот оно и есть. Ничего другого среднестатистический пользователь там не делает, даже будь он ИТшником.
Какая, например? find + exec предложили вы, я просто принял это как один из немногих консольных кунштюков, где присутствует настоящий цикл.
Вы же не ожидаете, что я буду перечислять ВСЕ способы работы в консоли? Это слишком много.
А так, единственные повсеместно встречающиеся пакетные обработки — это что-то вида "перенести файлы из одного каталога в другой", или там "удалить файлы по маске".
Ну, для тех, кто не умеет работать в консоли, и это достижение. Поэтому и предлагается ее изучение, что возможностей там намного больше.
Ну, тогда в консоли практически никто не работает :)
Вы забыли добавить "из вашего окружения".
запустить какую-то программу и узреть её результат в консоли, это вот оно и есть. Ничего другого среднестатистический пользователь там не делает
"Среднестатистический пользователь" про консоль знает только что она страшная, черная и для хакеров. А пользуется в основном телефоном.
Вы же не ожидаете, что я буду перечислять ВСЕ способы работы в консоли? Это слишком много.
Опять возвращаемся к уже пройденному материалу:
-Я не ем квашеную капусту
-То есть, вы утверждаете, что практически ничего не едите?
"Какая, например?" - "Вы же не ожидаете, что я буду перечислять ВСЕ способы работы в консоли? "
Очевидно же, что спросив "какая", я не ожидаю, что вы будете перечислять все способы :)
Поэтому и предлагается ее изучение, что возможностей там намного больше.
Простите, но в консоли нет вообще никаких возможностей, кроме как запускать утилиты с разными параметрами и автоматизировать их запуск. Вы изучаете тот софт, с которым вы работаете, и более никаких возможностей она вам не даст.
Вы забыли добавить "из вашего окружения".
Я имел в виду "для всех". Продвинутые возможности консоли - это узкоспециализированная вещь. Нужная сисадминам, девопсам и тому подобным профессиям, работа которых состоит в автоматизации процессов, состоящих из вызова разного мелкого софта с разными параметрами. И ещё молодым энтузиастам, которые ещё не наигрались непосредственно с операционкой. Вот, собственно, и всё. Кого вы ещё знаете, кому продвинутые возможности консоли могут пользу принести?
Очевидно же, что спросив "какая", я не ожидаю, что вы будете перечислять все способы :)
Ну, мне не очевидно чего вы ожидаете и соответственно что вам отвечать. Вообще-то довольно сложно рассказывать повседневные вещи...
Простите, но в консоли нет вообще никаких возможностей, кроме как запускать утилиты с разными параметрами и автоматизировать их запуск. Вы изучаете тот софт, с которым вы работаете, и более никаких возможностей она вам не даст.
То есть ваши познания консоли ограничены временами MSDOS, и с современными консолями вы не работали.
Я имел в виду "для всех". Продвинутые возможности консоли — это узкоспециализированная вещь. Нужная сисадминам, девопсам и тому подобным профессиям, работа которых состоит в автоматизации процессов,
Нет. Базовые возможности консоли полезны всем, кто о них знает. Очень многие бытовые задачи могут быть куда продуктивнее решены через консоль, чем принято считать. Но чтобы понять… не то даже как это сделать, а что так вообще возможно сделать, нужно хоть немного освоить консоль.
То есть ваши познания консоли ограничены временами MSDOS, и с современными консолями вы не работали.
Регулярно работаю, потому и удивляюсь вашей позиции. Озвучте, пожалуйста, я вас прошу, хоть одну функцию консоли за пределами "ввёл одну команду с параметрами", которая принесёт пользу хотя бы продвинутому пользователю, например, программисту.
Озвучте, пожалуйста, я вас прошу, хоть одну функцию консоли за пределами "ввёл одну команду с параметрами", которая принесёт пользу хотя бы продвинутому пользователю, например, программисту.
История. Автодополнение. Да банальные возможности конвейеризации и скриптования почему-то кажутся высоким уровнем.
История
Это не программирование, и не за пределами "ввёл одну команду", и даже не продвинутая функция современной консоли. Я без малого тридцать лет назад эту фичу на упомянутой MS DOS имел
Автодополнение
И эту тоже
а банальные возможности конвейеризации и скриптования
А это те самые банальные возможности, про которые мы уже говорили - это не для пользователей, а для нескольких специфических профессий. Что может сейчас скриптовать в консоли программист (у него что, nano/vim/mc/VS Code etc отобрали)? И ладно, то хоть программист, у него хоть по специфике работы скрипты могут быть. Что может скриптовать в консоли художник, копирайтер, дизайнер, математик, бухгалтер, музыкант и все остальные, кто компьютерами пользуются?
А это те самые банальные возможности, про которые мы уже говорили - это не для пользователей, а для нескольких специфических профессий
grep ERROR app.log | tail -n1
Совсем себе не специфическая профессия. Обычный саппорт, даже не Л3.
Что может скриптовать в консоли художник, дизайнер
что-нибуьд с ffmpeg, какую-нибудь обработку (ресайз, замыливание и др) при помощи подходящего софта.
копирайтер
Какой-нить апи вызов к чатгпт, какой-нить простой , который тырит инфу у другого копирайтера.
математик
Что-нибудь в bc
музыкант
https://www.youtube.com/watch?v=HdEEH4BfClc
Возможно вы не сильно интересовались сколько различных и удобных консольных команд есть для любых профессий.
Понятно, что для айтишников их абсолютное большинство, но даже меньшинство сегодня - это тысячи а может и миллионы программ.
История
Это не программирование
Так вы и спрашивали какие возможности программированию помогают. Я работал в виндовой консоли и прекрасно знаю насколько без истории и автодополнения неудобно.
А это те самые банальные возможности, про которые мы уже говорили — это не для пользователей
Нет, это именно для пользователей, потому что ни к чему специфичному не привязано. Просто "пользователи" об этих возможностях не знают, потому и не пытаются использовать.
Лично я пользовался консолью для программирования, администрирования (это как раз естественно), работы с картинками и видео, скачивания из интернета видео в странном формате, разработке электроники, визуализации данных с измерительного прибора, написании документации. Да проще перечислить где я ее не применял — в трехмерном моделировании разве что.
Что может скриптовать в консоли художник, копирайтер, дизайнер, математик, бухгалтер, музыкант и все остальные
А вы утверждаете что художнику или копирайтеру нужно что-то скриптовать или работать в консоли?
Я работал в виндовой консоли
Виндовая консоль с середины 90-х у тех, кто ей пользуется, выглядит вот так:
Есть там история, автодополнение и многое другое.
Лично я пользовался консолью для программирования, администрирования (это как раз естественно), работы с картинками и видео, скачивания из интернета видео в странном формате, разработке электроники, визуализации данных с измерительного прибора, написании документации.
И что вы в ней программировали, когда скачивали из интернета видео в страном формате или писали документацию? Вызвать curl или nano - это не программирование :)
Так вы и спрашивали какие возможности программированию помогают.
Нет, я такого не спрашивал. Я спрашивал, что вы подразумеваете под "программированием" в консоли, утверждая, что работа в консоли, это программирование.
Виндовая консоль с середины 90-х у тех, кто ей пользуется, выглядит вот так:
С тех пор прошло немало времени.
И что вы в ней программировали, когда скачивали из интернета видео в страном формате или писали документацию?
Формат потокового проигрывания .ts, когда отправляется куча фрагментов с предсказуемыми номерами. Собственно программирование было в их скачивании в цикле, склейке и конвертации в mp4.
Озвучте, пожалуйста, я вас прошу, хоть одну функцию консоли за пределами "ввёл одну команду с параметрами", которая принесёт пользу хотя бы продвинутому пользователю, например, программисту.
Нет, я такого не спрашивал.
Вы уж определитесь.
С тех пор прошло немало времени.
И тем не менее она у меня выглядит всё так же ;)
Ну, yakuake тоже не сильно изменился.
https://github.com/microsoft/terminal а вот это уже новое.
С тех пор прошло немало времени.
Да, теперь виндовая консоль поддерживает вкладки и можно выделить мышкой. А так - она все та же, синенькая.
Кого вы ещё знаете, кому продвинутые возможности консоли могут пользу принести?
С появлением современных сильно неравноценных ядер (79x0X3D, Core 12+ gen) стало вновь актуально указание аффинности для приложения.
Это можно делать как каждый раз ручками в гуях, так и один раз сделав ярлык.
Указание используемого видеоадаптера (это больше касается пингвина, в виндах это делается через gui или настройки самого приложения).
Кому актуально? Геймерам в первую очередь.
То, что они об этом не знают, никак не отменяет того, что так можно получить буст в производительности и/или плавности от существенного до огромного.
Обкатывать решение до получения рабочего варианта придется в консоли.
У нас спор не про "гуй или консоль", а про "программировать в консоли - это для всех, или для узкопрофессиональных применений"
Тут логическая ошибка в противопоставлении.
Если поделить выполняемые задачи на отдельные сферы, про каждую из которых можно однозначно сказать, что здесь умение поставить задачу, сделать прототип, отладить его до полезного варианта и придти к конечному результату реализованному через консоль однозначно пригодится или нет, то окажется, что каждому из этих всех нужны несколько, а то и множество сфер.
Таким образом, охват множества пользователей этими узкопрофессиональными сферами будет стремиться к полному.
Любопытно, вы, кажется, первый, кому не надо объяснять, чем программирование отличается от запуска полученного в его результате артефакта…
Таким образом, охват множества пользователей этими узкопрофессиональными сферами будет стремиться к полному.
Это, конечно, можно сделать, если у вас есть машина для растягивания сов и достаточно компактные глобусы. Ну т.е. сесть и теоретизировать, как там дизайнеру вдруг когда-нибудь в какой-нибудь удачно сложившейся ситуации может понадобиться написать скрипт, который как-то пакетно обрабатывает модели и куда-то отправляет. А бухгалтеру - то же самое, но с актами сверки. Но в реальной практике такого нет. Есть достаточно узкий список профессий, у которых есть потребность в написании баш-скриптов, а всем остальным оно нафиг не сдалось, кроме сово-глобусных примеров, и если даже какой-то такой пример и придумать, там всегда будет способ сделать ничуть не хуже, но без консоли.
Ну, это из разряда кому нужно умение ходить, когда есть велосипед.
И, так же, как и с велосипедом, он потенциально мог бы пригодиться буквально каждому (инвалидов и беременных пока считать не будем), но использует его относительно небольшое количество людей. У всех находятся причины, чтобы не использовать велосипед. Тем не менее, полезности и возможности использования эти причины никак не отменяют, они им совершенно ортогональны.
Вот это вот прям хрестоматиный пример консольного спора. Он всегда так выглядит. Апологеты консоли тебе говорят кучу пространных аналогий а-ля: "Одна маленькая, но очень гордая птичка сказала "А я полечу на Солнце"..", а как только просишь не о птичках, а привести реальный полезный пример, в лучшем случае тебе приведут пример скрипта, который фоточки по папкам с датами раскладывает, с уменьшением разрешения, или реже - музычку, и на этом все "человеческие" варианты заканчиваются. А в типичном - какой-то хитровымудренный скрипт сборки какого-то приложения, о котором только его автор знает. И какие фичи консоли, кроме "набрал софтинку с параметрами, нажал энтер и посмотрел результат" могут пригодиться тому подавляющему большинству людей, которым не нужен хитровымудренный скрипт сборки приложения, никто ответить не в состоянии.
Да-да, каждый раз, когда касается велосипедного спора, вам приводят кучу пространных аналогий, а как просите реальный полезный пример — так ничего кроме абстрактной пользы для здоровья не видно )
Хорошо-хорошо, вы правы.
Только сперва покажите, как в гуях, сделать один раз и навсегда пин ниток к нужным ядрам, чтобы не страдать каждый раз, когда планировщик отправит процесс погулять на другое ядро. Ладно, хрен с ними, с нитками — хотя бы процесс.
Но не в диспетчере задач, а РАЗ И НАВСЕГДА.
Или обоснуйте, почему геймерам не нужно +20% к максимальному фпс и +100500 к стабильности фреймрейта.
Ладно, хрен с ними, с нитками — хотя бы процесс.
Чорт, какая же непосильная задача.
А вот как вы потоки внутри процесса по ядрам персистентно раскидывать собрались, хоть в консоли, хоть в гуи - это даже Аллах не знает.
Или обоснуйте, почему геймерам не нужно +20% к максимальному фпс и +100500 к стабильности фреймрейта.
Это не даст ни 20% к фпс, ни 100500 к стабильности фреймрейта. Так, в некоторых сырых свежевышедших играх иногда немного будет стабильнее.
Но самое интересное тут другое - какое отношение этот ваш вопрос имеет к контексту спора? Напомню,
какие фичи консоли, кроме "набрал софтинку с параметрами, нажал энтер и посмотрел результат
Чорт, какая же непосильная задача
И при нажатии Apply система на вас ругнулась.
Потому что в %PATH% никакого start нет, это внутренняя команда cmd.exe, и вызывать ее надо через cmd -k.
Это не даст ни 20% к фпс, ни 100500 к стабильности фреймрейта
Ну да, ну да. Всем, кроме уже умеющих припиниваться самостоятельно, дает — вам не дает.
Или вы потеряли контекст и забыли, о каком железе идет речь, и, отвечая, приведете еще один непроверенный и иррелевантный пример?
Вопрос риторический.
Ветка, похоже, проклята.
Потому что в %PATH% никакого
startнет, это внутренняя командаcmd.exe, и вызывать ее надо черезcmd -k.
Я это прекрасно знаю, там просто не всё выделено. Но у меня к вам отличный встречный вопрос: если вы сами, оказывается, в курсе, как через гуи настроить аффинити маску - к чему был вот этот ваш вопрос:
Только сперва покажите, как в гуях, сделать
Далее,
Ну да, ну да. Всем, кроме уже умеющих припиниваться самостоятельно, дает
По поводу этого, уж извините, если это ваше "всем" существует, вам же не составит труда кинуть ссылочку на тесты, да? Целых +20% фпс просто настройкой ярлыка - это же должно быть в библии любого геймера, т.е. статьи на эту и тесты есть на всех геймерских и многих негеймерских сайтах, верно? А то у меня, похоже, гугл неисправный, не находит никак :(
к чему был вот этот ваш вопрос: <…>
Как вы предлагаете придти к этому решению без знания консоли — вот правильный вопрос.
Целых +20% фпс просто настройкой ярлыка — это же должно быть в библии любого геймера
И не найдете, потому что добыча этого знания требует погружения в матчасть. А геймеры все еще спорят, важен ли для производительности CPU, не до матчасти им.
Без нее получаются только вот такие недоэксперименты, в которых малониточный процесс пинят на всю нума-ноду — и даже это дает измеримый эффект, причем больший, чем пин на ядра с максимальным бустом.
Но если у вас есть любой двух- и более чиплетный Ryzen/TR/Epyc под руками или интеловская нума на минимум две ноды с высокочастотными процессорами (про обязательность более-менее приличной видеокарты, этот смеет надеяться, уточнять не надо?) то вы сами можете легко устроить эксперимент.
Возьмите любую игру, которая не пинит свои потоки (из таковых каджиту попался только WoW — то есть, подойдет почти любая), и показывает загрузку на 3-4 ядра со средней частотой кадров на вашем мониторе ниже частоты синка, и проведите замеры средней частоты и редких событий.
На R5-1600 с 16ГБ и RX6700 эффект от привязывания к одному чиплету аналогичен замене процессора на 5800G, у которого выше частоты и более гомогенная внутрянка.
Особенно видно по редким событиям, они практически исчезают при таком подходе.
Как вы предлагаете придти к этому решению без знания консоли — вот правильный вопрос.
Точно так же, как и со знанием консоли - погуглить. В "знание консоли" напрочь не входит знание наизусть всех параметров всех системных утилит. Это гуишник ещё что-то может сам разобраться, просто открыв этот самый гуи и почитав названия на кнопках/чекбоксах. В консоли by design предполагается, что вы мануалы читаете.
И не найдете, потому что добыча этого знания требует погружения в матчасть
Ну то есть, шикарный способ бесплатно увеличить производительность на реально огромную величину, оказывается, никому не известен.
Но если у вас есть любой двух- и более чиплетный Ryzen/TR/Epyc под руками или интеловская нума на минимум две ноды с высокочастотными процессорами
То есть, для чистого эксперимента нам уже нужно играться не на компьютере, а на двухпроцессорном серваке, раз уже нума пошла. Как-то резко мы перешли от геймеров к чувакам, которые на серверах играются.
Возьмите любую игру, которая не пинит свои потоки (из таковых каджиту попался только WoW
Простите, я даже не буду проводить эксперимент самостоятельно, давайте я делегирую это профессионалам:
5600X - один чиплет, 5950Х - два чиплета, одноядерная производительность плюс-минус одинаковая, у первого на 200 МГц выше базовая частота, у второго на 200МГц выше одноядерный буст. Где я могу у первого наблюдать +20% быстродействия, а также существенное снижение количества фризов?
Это гуишник ещё что-то может сам разобраться, просто открыв этот самый гуи и почитав названия на кнопках/чекбоксах
Эти гуишники даже с простейшим Handbrake разобраться не могут, заполоняют форумы предельно тупыми и очевидными вопросами.
Что уж там про более сложный софт.
Или, вот, например, что нужно сделать в гуях, чтобы догадаться что удаление с шифтом — удаляет мимо корзины, м?
Не забывайте, что ответ, очевидный продвинутому пользователю — для абстрактного типичного пользователя суть чистая магия.
Как-то резко мы перешли от геймеров к чувакам, которые на серверах играются
Как-то вы резко и избирательно перестали читать написанное, и стали выбрали то, к чему, на ваш взгляд, удобнее дободаться
Простите, я даже не буду проводить эксперимент самостоятельно, давайте я делегирую это профессионалам:
… и — даже понимать прочитанное. Потому как в ваших скриншотах упор идет вовсе не во время подготовки кадра.
Ну, за сим с вами тоже дальнейший диалог становится бесполезен: участие в спецолимпиадах требует времени, разжевывание людям букв, которые они не желают сложить в слова и прочитать эти слова буквально по значению — тоже.
Эти гуишники даже с простейшим Handbrake разобраться не могут, заполоняют форумы предельно тупыми и очевидными вопросами.
При этом они как-то не называют вас тупым только потому, что вы не разбираетесь в бухгалтерии, медицине или ещё в какой-либо профессии этих гуишников. Может, и вам пора перестать считать себя Д'Артаньяном? То, что вы научились пользоваться компьютером лучше других, чести вам не добавляет. Вы просто освоили свою профессию.
Как-то вы резко и избирательно перестали читать написанное, и стали выбрали то, к чему, на ваш взгляд, удобнее дободаться
Ну так не пишите то, что откровенно нелепо. Я ж вас за язык не тянул :)
… и — даже понимать прочитанное. Потому как в ваших скриншотах упор идет вовсе не во время подготовки кадра.
Ненене, не сбегайте в кусты. Я же, повторюсь, вас за язык не тянул - раз сами начали, давайте, отвечайте уж за свои слова. Итак какое ещё "время подготовки кадра" вы имете в виду, и почему вдруг FPS на скришнотах - не про это, особенно в свете того, что там даже предельные есть, 1% и 0.1%? Рассказывайте-ка мне поподробнее, с учётом того, что вы это рассказываете человеку, который в нулевые писал игровые движки под DirectX.
участие в спецолимпиадах требует времени, разжевывание людям букв, которые они не желают сложить в слова и прочитать эти слова буквально по значению — тоже.
Может быть, ваша проблема в другом? Фигово пытаться спорить, не владея матчастью, и вместо технических деталей приходится отбиваться философией и пространными намёками а-ля "я-то вот что-то знаю, а вы если бы читали, то бла-бла" :)
Может, и вам пора перестать считать себя Д'Артаньяном?
Аргумент ваш состоял в том, что в гуях есть некое волшебство, позволяющее научиться ими пользоваться просто тыкая мышкой.
На самом деле это не так, иначе профессональные форумы по раболте с софтом — вымерли бы. Именно это проиллюстрировал каджит, выбрав максимально однозначные и доходчивые формулировки.
И вы, ожидаемо, прицепились к формулировкам, как и почти все в этой ветке.
Я же, повторюсь, вас за язык не тянул
Нет, вы начали страдать подменами, как и другие участники.
Но, надо сказать, очень наглядно показали, что если читаь по диагонали не понимая, о чем вообще речь — то, действительно, можно долго не видеть никакого смысла в аргументах оппонента.
Каджит описал и принцип, и случаи. Если вам что-то непонятно, вызывает вопросы и выхотите получить ответ, а не разводить демагогию — сформулируйте эти вопросы и задайте их, а не цеплйтесь к чему попало.
Без пререканий, без наездов, без обвинений в софизме или дартаньянстве.
вместо технических деталей
Если бы вы матчасть действительно знали, или, хотя бы, ценили так как говорите, то и разница между Zen1-2-3-4 от вас бы не ускользнула, и плохая применимость принесенных вами картинок к описанным каджитом условиям. Да и вместо картинок принесли бы статью полностью.
Говорил же: ветка проклята, любой диалог превращается сборку жигулей.
Но, ради вас, этот готов начать сначала.
Итак, что вызывает у вас вопросы? Сформулируйте их и выложите списком — вместе пройдемся и проанализируем.
Аргумент ваш состоял в том, что в гуях есть некое волшебство, позволяющее научиться ими пользоваться просто тыкая мышкой.
Не волшебство, а естественное их свойство, именно так и есть.
На самом деле это не так, иначе профессональные форумы по раболте с софтом — вымерли бы.
Я правильно понимаю, что по-вашему, все люди склонны к самообразованию, а форумы, школы и т.д. - всё это существует лишь потому, что материалов для самообразования в мире недостаточно? Не потому, что в мире много людей, которые не умеют/ленятся/боятся самостоятельно разбираться?
Нет, вы начали страдать подменами, как и другие участники.
Ни единой подмены, чесслово. Просто... вы неправы.
Нет никаких +20% от установки аффинити маски в играх, нет никаких уменьшений фризов,
а приведенный мной FPS - это практически чистое отображение времени подготовки кадра на соответствующих системах, и достоверно и наглядно подтверждает первое.
А выгода от установки аффинити маски для игр на процессорах - это был хотфикс для единичных кривых игр, до того, как апдейты на них повыходили, не более того.
А винда в курсе, какие ядра на каких чиплетах расположены, и раскидывает потоки процессов, исходя из этого. Для того нынче в частности и есть драйверы процессоров.
А каджит не в курсе, что нельзя установить аффинити маску для потока даже через консоль, хотя считает, что можно и нужно. Хотя это для пользователя не реализовано, потому что не имеет смысла, т.к. пользователь не обладает информацией, какой поток внутри процесса за что отвечает. Только сам процесс изнутри, зная дескрипторы своих потоков и кто из них кто, может раскидывать их по ядрам "сознательно".
Не волшебство, а естественное их свойство, именно так и есть
То есть, вы готовы утверждать, что любому пользователю, исключительно исследуя менюшки photoshop/krita/sai/etc, совершенно не изучая правила композиции, работу с перспективой и освещением, и т.д. и т.п., можно стать профессиональным художником, которому будут наперебой крупные студии предлагать миллионные контракты?
Причем тому пользователю, у которого паника случается от сообщения на его родном языке?
Или, может, СВЧ-плату сделает такой пользователь, просто повозив по менюшкам Altium?
Да нет, на практике необходимо сначали изучить тонны матчасти, а уже потом, со страданиями и скрипом, учиться в выбранной программе работать.
Что же до списка…
Во-первых, подмена есть. И если бы вы знали матчасть, как говорите, а не врали, то от вас бы не укрылось то, на каких процессорах это применяется и дает весомый эффект: каджит их натурально перечислил.
В перечисление вошли (в скобках указана причина):
- Zen1:R5-1600 (c2c vs ccx2ccx latency)
- Core 12xxx+ (E and P cores)
- R9-79xxX3D (two chiplets — only one w/3DC stack)
И если вы правы, то выходит, что ни топология, ни задержки, ни частоты, ни размер кеша — вообще никак не влияют на производительность.
Вы же не спроста притащили графики без статьи, вы хотели исключить предметную часть из рассмотрения.
Этот должен вас поздравить, демагог из вам лучше, чем из Канута.
Тем не менее, все, чего вы добились — довели феерию идиотии до новых вершин.
То есть, вы готовы утверждать, что любому пользователю, исключительно исследуя менюшки photoshop/krita/sai/etc, совершенно не изучая правила композиции, работу с перспективой и освещением, и т.д. и т.п.,
Я готов утверждать, что любому пользователю, которому знакомы правила композиции, работа с перспективой и освещением и прочие вещи, не имеющие отношения к UI, но зато имеющие отношения непосредственно к его предметной области (и которые непонятно зачем тут приплёл каджит) действительно можно, исследуя менюшки фотошопа, научиться им пользоваться. Более того, многие профессиональные художники, переходя с бумаги на цифру, так и делали ввиду отсутствия интернетов в то время. И тем более, если вы освоили Фотошоп, то освоить другой редактор вам вообще легко будет. И это мы с вами говорим про сложнейшие профессионально-ориентированные инструменты. А консольщику, чтобы с несчастной wget на curl пересесть, мануал надо читать :)
В перечисление вошли (в скобках указана причина):
Простите, но это ложь, придуманная каджитом исключительно по его собственным предположениям. В реальности планировщик задач ОС и без установки аффинити маски прекрасно знает разницу между ядрами и справляется с этим. Он знает, какие ядра производительные, какие нет, и ресурсоёмкие задачи вроде игр запускает только на производительных ядрах.
Вы же не спроста притащили графики без статьи, вы хотели исключить предметную часть из рассмотрения
Я вам притащил графики из первой попавшейся статьи с тестированием игр, где есть одночиплетный и двухчиплетный райзен. Самая обычная игровая статья - фпс в разрезе игр, потребление и выводы, какой процессор лучший к покупке. Вы можете любую такую же взять, там те же цифры. Вся суть была на графиках - процессор с одним чиплетом показывает такую же производительность, как и процессор с двумя чиплетами. Значит, гипотеза каджита, что якобы на многочиплетных процессорах винда будет разбрасывать потоки между разными чиплетами, из-за чего будет страдать производительность - ложь. ЧТД. Если хотите опровергнуть - интернет у вас есть, давайте другие графики и тестирование, где установка аффинити маски повышает производительность на 20%. Да или хотя бы на 5%, блин, а не в пределах статистической погрешности.
Тем не менее, все, чего вы добились — довели феерию идиотии до новых вершин
Именно. Это ли не феерия идиотии - на фразу "научиться пользоваться ГУИ просто тыкая мышкой" в качестве контрпримера приводить "научиться пользоваться фотошопом, не умея рисовать"? Или не феерия идиотии - в ответ на обычные игровые тесты, которые есть на любом игровом сайте, устраивать теорию заговора "Вы же не спроста притащили графики без статьи, вы хотели исключить предметную часть из рассмотрения. ", а что каджит не в состоянии свои тесты привести - так это потому что тесты очень секретные, а не потому, что каджит ерунду сочиняет :)
Да, в какой-то мере эту феерию идиотии действительно довёл я - я же мог с каджитом просто не спорить, а так, связался на свою голову, и вот, оно всё выплыло
Простите, но это ложь, придуманная каджитом исключительно по его собственным предположениям
Простите, каджит придумал что вы не умеете использовать поиск по странице в браузере, или архитектуру и топологию конкретных процессоров?
Не очень с дивана понятна глубина трагедии.
UPD: этот готов оставить место для взаимонепонимания, но оно явно носит характер тотального пиздеца.
Давайте его как-нибудь приведем в более приличный вид, что ли…
Простите, каджит придумал что вы не умеете использовать поиск по странице в браузере
Однозначно придумал
или архитектуру и топологию конкретных процессоров?
Архитектуру - не придумал, побочный эффект от этой архитектуры - придумал, и целую теорию развил на фантазиях.
Однозначно придумал
То есть, вы таки знали конкретные модели, но на скриншотах специально притащили что попало. Мило.
на фантазиях
Ммм… ок, так и запишем: E и P ядра одинаковы по производительности, дорогущий 3D-cache ни на что не влияет.
Собственно, на этом спор о матчасти можно закончить, пока мы не докатились до того, что 486SX быстрее EPYC.
А это мы даже до кондовой реализации вытесняющей многозадачности не дошли, которой даже в виндах сто лет в обед как нету.
То есть, вы таки знали конкретные модели, но на скриншотах специально притащили что попало. Мило
На скриншотах я притащил именно те модели, на которых ваш эффект должен проявляться. Не проявляется. Мило.
Ммм… ок, так и запишем: E и P ядра одинаковы по производительности, дорогущий 3D-cache ни на что не влияет.
Вы издеваетесь? Я вам вроде бы понятным русским языком написал:
В реальности планировщик задач ОС и без установки аффинити маски прекрасно знает разницу между ядрами и справляется с этим. Он знает, какие ядра производительные, какие нет, и ресурсоёмкие задачи вроде игр запускает только на производительных ядрах.
И ладно бы один раз, но я и до этого писал это же самое. Скажите, это каджит читает одну строку через три? Или читает нормально, просто предпочитает в упор не замечать неудобные вопросы, чтобы см.выше, ещё немного оттянуть неизбежное, т.е. извиниться за глупости?
И напоминаю ещё раз, а то я вижу, вы ещё несколько строчек не прочитали:
Вы можете извиваться как хотите, ваше право, но я от вас жду только два вариант ответа:
а) результаты тестирования игр, где на мультичиплетных процессорах установка аффинити маски даёт +20% производительности
б) слов "Извините, я был неправ"
Всё остальное можете отправлять в мусор ещё до того, как напишете,
А если у вас кишка тонка извиниться, вы можете просто... промолчать. Вряд ли кто-то из посетителей сайта ещё следит за нашей дискуссией, а я ваш спектакль точно не оценю :)
Ну и, заодно, давайте разберем пункты, кратко.
1,3,4 — конфигурация и эффект описаны, добавить можно, разве что, свежеобновленную винду и свежие драйвера.
Таким образом, ваше утверждение означает или что R5-1600 и R7-5800G идентичны по производительности, или что вы вообще не понимате, о чем идет речь, или что намеренно врете.
2 — уже сказал в соседнем комменте, притащить абстрактные графики без конфигурации, на других поколениях либо иных топологических конфигурациях, без каких-либо пояснений… многое говорит как о вашем хваленом знании матчасти, так и вообще хотя бы событий последних лет пяти.
5 — еще одно соломенное чучело. Ну или цитату в студию )
1,3,4 — конфигурация и эффект описаны, добавить можно, разве что, свежеобновленную винду и свежие драйвера
Нет, не описаны. Вы лжёте, потому что если были бы описаны - пруфы вы бы в первом же посте выложили, а не занимались пустословием на десять постов.
притащить абстрактные графики без конфигурации
Что значит "абстрактные графики без конфигурации"? Процессор 5600Х против 5950Х, остальное идентичное и не играет роли в данном контексте, как и во всех игровых тестах (или каджит не знает даже как проводятся игровые тесты?). Выбирайте любой, соотношение цифр везде одинаковое:
https://www.google.com/search?client=firefox-b-d&q=5600x+vs+5950x+gaming
Где ваши +20% на одночиплетных конфигурациях?
5 — еще одно соломенное чучело. Ну или цитату в студию
И здесь я вас тоже за язык не тянул. Держите свою цитату:
Только сперва покажите, как в гуях, сделать один раз и навсегда пин ниток к нужным ядрам, чтобы не страдать каждый раз, когда планировщик отправит процесс погулять на другое ядро
На сим разрешите откланяться. Вы можете извиваться как хотите, ваше право, но я от вас жду только два вариант ответа:
а) результаты тестирования игр, где на мультичиплетных процессорах установка аффинити маски даёт +20% производительности
б) слов "Извините, я был неправ"
Всё остальное можете отправлять в мусор ещё до того, как напишете, экономьте байты, пожалуйста. Но почему-то я уверен, что ответа от вас не будет, потому что вариант а) вы подтвердить не сможете, а для варианта б) у вас смелости не хватит, ибо если была бы, вы бы уже десять раз извинились, а не превращали свой авторитет в (опять вас цитирую):
характер тотального пиздеца.
У всех находятся причины, чтобы не использовать велосипед.
Угу. И основная причина это наличие более удобных альтернатив.
И так же и со скриптами: есть куча проблем, которые можно решать скриптами. Но дело в том что их можно решать не только скриптами. И альтернативы обычно удобнее для среднего пользователя.
Вы уже смогли разобратья с разжеванным примером и ответить на вопросы со звездочками, чтобы спор об определениях мог сдвинуться дальше?
Потому как вы снова сделали подмену на удобную вам трактовку, и увлеченно воюете с соломенным чучелом.
Kanut COKPOWEHEU
Вы оба по своему правы, и оба несколько перегибаете )
Во времена dos народ поголовно работал в консоли, но даже запустить keyrus самостоятельно могли не только лишь все. Чего уж говорить о написании батников.
Обычно работали с nv/vc/dn, lexicon, qv и другими готовыми программами.
Сейчас основной рабочий инструмент это gui, и шелл юзеру практически не нужен, даже продвинутому. А те, кому нужен именно как среда выполнения самописных скриптов — они уже программисты по другим критериям.
Обычно работали с nv/vc/dn, lexicon, qv и другими готовыми программами.
А, так вопрос может быть в терминологии. Я под работой в консоли понимаю именно CLI, а не любой текстовый интерфейс. Псевдографика это не "работа в консоли".
Ну я работаю в консоли - использую различные тулы, но не пишу скрипты. Это преимущественно запуск сборки, тестов (по другому не запустить нужную для проверки версию), просмотр логов, какие-то манипуляции с ними при помощи разных утилит (grep, dsq, jq) или апи дернуть курлом, пакеты обновить/поставить.
Это программирование? Вряд ли, иначе - любой запуск программы становится программированием. Работа в консоле - да, все тулы имею CLI, из обладающих псевдографикой только tmux/screen.
Запуск одной программы и работа в ней это все же не работа в системной консоли. А вот хотя бы объединение нескольких утилит в конвейер — примитивным программированием уже считать можно.
А какая разница, объединяю я запуск команд в конвейер или перенаправляю вывод одной команды в файл, а потом этот файл передаю на вход другой команде? Тем самым я сохраняю промежуточное состояние и если ошибся в команде, или мне нужны другие параметры, то не надо выполнять всю цепочку команд.
И это мало отличается от того, чтобы открыть файл в одной программе, сделать с ним какие-то манипуляции, результат сохранить и обработать а другой программе.
Если я написал скрипт (не важно bash, sh, bat, power shell), то да, это будет программированием, программирование подразумевает, что появляется описание алгоритма которое можно переиспользовать. В случае ручного набора команд и объединения их в конвейер результат в виде скрипта не остаётся, т.е. нет результата процесса программирования.
Так же, я могу чертить в автокаде используя его встроенную консоль и даже делать циклы, но это опять же не будет программированием, так есть только результат работы, но нет самой программы.
А если я в ворде записал макрос и сохранил его - это программирование, так в результате процесса появилась программа, которую можно повторно запустить.
Даже написание файла конфигурации vim/nvim - программирование, потому что в результате появляется программа которую можно выполнить и выполняет её vim/nvim. Ну или emacs.
Если по вашему работа в консоли - это хотя бы объединение команд в конвейер, то как называть просто отдельный запуск CLI программ?
А какая разница
Разница в том, кто занимается однообразной работой, человек или машина.
Если я написал скрипт (не важно bash, sh, bat, power shell), то да, это будет программированием, программирование подразумевает, что появляется описание алгоритма которое можно переиспользовать. В случае ручного набора команд и объединения их в конвейер результат в виде скрипта не остаётся,
Он остается в истории команд и точно так же может быть вызван повторно.
Если по вашему работа в консоли — это хотя бы объединение команд в конвейер, то как называть просто отдельный запуск CLI программ?
С какой стороны посмотреть. Вбиваете-то вы команду скриптового языка. Ну то есть шеллам без разницы откуда возьмется исходный код скрипта для интерпретации — из файла, из аргументов запуска или набранный интерактивно. С этой точки зрения, запуск отдельной программы это вырожденный случай программирования.
$ ls
$ bash -c "ls"
$ echo "ls" > file.sh ; bash file.shВсе три варианта с точки зрения баша одинаковы. Почему вы считаете, что первый это не программирование, а последний — уже оно?
С какой стороны посмотреть. Вбиваете-то вы команду скриптового языка.
Необязательно команду языка, это может быть просто имя исполняемого файла, но да, тогда это будет рассматривать как команда на запуск этого файла.
Но таком случае, работа в программе в GUI, где есть возможность записи макроса и/или повтора команды из истории так же является вариантом визуального программирования. Ведь по сути, клик по меню или выбор и применение инструмента - это просто форма описания команды, которая сохранилась в истории. Является ли это программированием (визуальным)?
Все три варианта с точки зрения баша одинаковы. Почему вы считаете, что первый это не программирование, а последний — уже оно?
В моем понимании ни первый ни последний не являются программированием. Для меня грань пролегает при появлении языковых конструкций ветвления, циклов. При этом написать скрипт в котором после каждого вызова программы будет стоять явная проверка на то, что команда завершилась успехом, и в этом случае продолжается исполнение скрипта, а в случае ошибки прерывается с каким-то дополнительным сообщением - становится программированием. Просто прерывание попадает под программирование, но можно заменить set -e или объединением команд в одну через &&. Или дописав || exit 1 к каждой.
Необязательно команду языка, это может быть просто имя исполняемого файла
Шелл не знает что это, для него это просто оператор языка. Это потом он будет его искать сначала среди встроенных, потом внешних. Вы сначала вводите оператор(ы) скриптового языка, потом даете команду на выполнение.
Для меня грань пролегает при появлении языковых конструкций ветвления, циклов.
То есть даже линейная последовательность команд или конвейер для вас программированием не является. А собственно почему?
То есть даже линейная последовательность команд или конвейер для вас программированием не является. А собственно почему?
Это просто вызов команд, не важно как его делать в конвейере, объединив команды через &&, или ||, или записать их последовательность в скрипт и выполнить, или каждый раз вручную вводя команду (копируя откуда-то), или кликая мышкой по менюшкам. Запись макроса или последовательный запуск команд в скрипте, на границе, но всё же нет.
В противном случае, любая работа связанная с использование компьютера - программирование. Просто интерпретатором команд является не шелл, а какая-то другая программа. Ну за исключением компьютер когда используется как подставка или его куда-то переносят, ну или еще совершают какое-то действие как с некоторым объектом. :)
Причем процесс программирования - это как раз процесс создания программы. Дальнейшие её запуски уже программированием не являются. И смысл программирования ещё в том, чтобы программа, как результат процесса, использовалась многократно без модификации, а не создавалась для разового выполнения.
Это просто вызов команд, не важно как его делать
А программирование это просто вызов операторов.
Запись макроса или последовательный запуск команд в скрипте, на границе, но всё же нет.
Ага. То есть вопрос снова в определениях. Понятно что под программированием вы понимаете что-то свое, не просто формализацию алгоритма чтобы при помощи относительно универсальных команд решить конкретную задачу. Написание исходного кода для его последующего выполнения машиной тоже. А что же тогда?
В противном случае, любая работа связанная с использование компьютера — программирование.
Ну, если говорить об обычном определении программирования — нет. Насколько оно соответствует вашему ведомо только вам.
И смысл программирования ещё в том, чтобы программа, как результат процесса, использовалась многократно без модификации, а не создавалась для разового выполнения.
Ну разумеется, нет!
А программирование это просто вызов операторов.
Нет. Программирование это составление программы, в которой вызываются операторы.
Если вы просто "вручную" вызываете операторы один за другим, то это не программирование. Это всё ещё может быть какой-то разновидностью профессиональной деятельности. Но это уже не программирование.
Нет. Программирование это составление программы
Гениальное определение!
Если вы просто "вручную" вызываете операторы один за другим, то это не программирование.
Вы на скриптовых языках программировали? На Питоне хотя бы. Там ведь точно так же есть интерактивный режим, когда операторы вводятся по одному и по одному же выполняются. Почему там это программирование, а в шелле — нет?
Гениальное определение!
А что вам не нравится? Ну можете на википедии посмотреть: "Программи́рование — процесс создания компьютерных программ." :)
Почему там это программирование, а в шелле — нет?
Потому что использование того же Питона в этом самом интерактивном режиме это тоже не программирование :)
Охохонюшки-хохо, то есть, вы утверждаете, что прототипирование в REPL — не программирование?
На взгляд каджита, спор снова свелся к определениям.
Охохонюшки-хохо, то есть, вы утверждаете, что прототипирование в REPL — не программирование?
Если вы только выполняете одиночные команды, то нет, это не программирование.
Ну, теперь step-by-step debugging в REPL — не программирование, выходит… хрен редьки не слаще.
Ну да debugging может быть частью процесса создания программ, но сам по себе программированием не является.
П.С. И ещё раз уточню: выполнение отдельных команд в консоли или debugging совсем не обязательно что-то менее полезное или менее значимое или ненужное. Просто само по себе это не программирование как таковое.
Дебаггинг это и поиск ошибки и ее устранение — написание нового кода и/или рефакторинг старого, причем она часть разработки (программирования).
Теперь, с ваших слов, и вовсе выходит чудно: программирование у нас больше не программирование.
Если уж хотите провести границу, то ее можно проводить по структурности: там где явно выраженной структуры нет — мы имеем дело со скриптом (записью последовательности), там где она есть — с программой.
При этом, заметьте, ни одно определение, которое можно найти, не накладывает ограничений по длине программы print("Hello world!" — это тоже программа, и это первая программа которую вы увидите в учебнике и первая, которую вы напишете сами).
При этом, скрипт можно рассматривать вырожденный случай программы, когда она состоит из единственной функции и эту функцию незачем отдельно отформлять, когда можно оставить от нее только тело.
Таким образом, провести четкую границу границу — невозможно, ее просто нет.
Единственное, что точно не программа ни в коем виде — это вызов исполняемого файла без параметров. awk "{print '$1'}" уже выполняет работу по определенным предписанным правилам, как и find -type f -name '*~' -mtime -7 -rm, и какого-либо внятного объяснения, которое выдержит проверку другими условиями и не вступит в конфликт с другими определениями, почему первое это программа, а второе нет — не существует.
Дебаггинг это и поиск ошибки и ее устранение — написание нового кода и/или рефакторинг старого, причем она часть разработки (программирования).
Нет. Дебаггинг это дебаггинг. Он может привести к написанию нового кода или рефакторингу. Но сам по себе ими не является.
Если уж хотите провести границу, то ее можно проводить по структурности: там где явно выраженной структуры нет — мы имеем дело со скриптом (записью последовательности), там где она есть — с программой.
Лично я как раз не вижу принципиальной разницы между скриптом и программой в контексте обсуждаемого. Потому что например все программы на js по хорошему являются скриптами.
При этом, заметьте, ни одно определение, которое можно найти, не накладывает ограничений по длине программы (print("Hello world!")
Ну да. При этом если вы запишите ваше "print("Hello world!")" в программу или скрипт, то это будет программирование.
А если вы потом запустите эту программу или просто напишите "print("Hello world!")" в консоли, то это программированием не будет.
Но сам по себе ими не является
Но входит в более общий термин, вместе с рефакторингом, нет? Если не входит, то это должно значит большую разницу, как между программироваием и эксплуатацией или что-то вроде того.
А если вы потом запустите эту программу или просто напишите "print("Hello world!")" в консоли, то это программированием не будет
Запуск это эксплуатация, тут все ясно.
А вот чем так принципиально отличается print("Hello world!"), полученный из одного файла или из другого — нет.
То получается, что программирование это не процесс написания кода, а сохранение результата этого написания.
Но входит в более общий термин, вместе с рефакторингом, нет? Если не входит, то это дол
Нажатие клавиш на клавиатуре тоже является частью процесса программирования и "входит в более общий термин". Является из-за этого любой "процесс нажатия клавиш на клавиатуре" программированием?
А вот чем так принципиально отличается print("Hello world!"), полученный из одного файла или из другого — нет.
Ничем не отличается. Но мы сейчас обсуждаем не полученный результат, а процессы при помощи которых его получают. И вот они вполне себе могут отличаться.
Если перед вами лежит мёртвый человек, то он мёртвый вне зависимости от того как он умер. Это результат каких-то там процессов. Но далеко не все процессы, которые могли бы к этому привести, обозначаются термином "убийство".
То получается, что программирование это не процесс написания кода, а сохранение результата этого написания.
Нет. Хотя сохранение результата в каком-то виде вполне себе является частью процесса.
Является из-за этого любой "процесс нажатия клавиш на клавиатуре" программированием?
Нажатие клавиш это метод ввода информации в машину. Очевидно, что ввод данных отличается от обработки данных и оба они от создания средств обработки.
Ничем не отличается. Но мы сейчас обсуждаем не полученный результат, а процессы при помощи которых его получают. И вот они вполне себе могут отличаться
Окей, давайте разовьем эту мысль. Вот три примера, в которых каджит создает некой код, выполняющий некую работу и демонстрирует, что работа выполняется:
❯ python3
Python 3.11.3 (main, Jun 5 2023, 09:32:32) [GCC 13.1.1 20230429] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> print("Hello World!")
Hello World!
>>>
❯ echo 'print("Hello World!")' > /tmp/helloworld.py && python3 /tmp/helloworld.py
Hello World!
❯ echo 'print("Hello World!")' | python3
Hello World!Добавьте к ним написание того же кода на бумаге, если хотите задачу со звездочкой.
Вопрос: в каком случае написание кода не является программированием, и почему?
Нажатие клавиш это метод ввода информации в машину. Очевидно, что ввод данных отличается от обработки данных и оба они от создания средств обработки.
Это не ответ на мой вопрос. Является любой "процесс нажатия клавиш на клавиатуре" программированием?
Вопрос: в каком случае написание кода не является программированием, и почему?
Написание кода является программированием тогда, когда в результате вы получаете "программу" в том или ином виде.
Это не ответ на мой вопрос
Это и есть ответ. Ввод данных ≠ созданию средств обработки.
Написание кода является программированием тогда, когда в результате вы получаете "программу" в том или ином виде
Хорошо, каджит придумал программу, но не записал ее в файл на компьютере. Пока он помнит или может восстановить по памяти ее текст — была ли эта деятельность программированием?
Вопрос со звездочкой:
каджит проверил свою программу в REPL. Введенные строки сохранились в истории команд REPL. Программу, соотвественно, можно вычленить их истории команд и оформить отдельным файлом, но каджит этого не сделал. Была ли эта деятельность программированием?
Вопрос с двумя звездочками:
каджит таки вычленил свою программу из истории REPL и сохранил в файл — но случайно удалил его. Была ли эта деятельность программированием?
Вопрос с тремя звездочками:
каджит взял testdisk, нашел и спас удаленный файл, добавил его в репозиторий. Была ли эта деятельность программированием?
Пожалуйста, обоснуйте ответ в каждом случае: это нужно для проверки на противоречивость определений.
Это и есть ответ. Ввод данных ≠ созданию средств обработки
То есть нажатие клавиш само по себе программированием не является?
Хорошо, каджит придумал программу, но не записал ее в файл на компьютере. Пока он помнит или может восстановить по памяти ее текст — была ли эта деятельность программированием?
Если вам хочется позаниматься софистикой, то я выше давал ссылки на определения терминов "программа" и "программирование". Можете их использовать для получения ответа на свои вопросы. Я вам для этого не нужен.
Что, тоже почувствовали, что вот-вот докажете правоту оппонента? )
Ссылки-то вы привели, только вот с вашего выражения вашего же понимания там написанного выходило всякое чудесатое. То привязка к месту редактирования, то к способу сохранения, то вообще — уничижение роли мыслительной деятельности в процессе.
Именно эти… нюансы… и должны были вскрыться в ходе формулирования ответов.
Ну, раз вы отказались отвечать, то мысль все равно стоит закончить.
Программа выглядела в псевдокоде так:
10 СОСТАВИТЬ РЕКУРСИВНЫЙ СПИСОК ФАЙЛОВ НАЧИНАЯ ОТ ТЕКУЩЕГО ПОДКАТАЛОГА
20 ВЫБРАТЬ БЭКАПНЫЕ ФАЙЛЫ
30 ВЫБРАТЬ ФАЙЛЫ СОЗДАННЫЕ ЗА ПОСЛЕДНЮЮ НЕДЕЛЮ
40 УДАЛИТЬ ФАЙЛЫСогласно любому определению, в котором print("Hello World!") — валидная программа (а с этим утверждением вы уже согласились), эта программа так же валидна.
Она может быть выражена на любом языке, в котором есть понятие файла/каталога и работа со строками.
В том числе, она может быть выражена и так:
find -type f -name '*~' -mtime -7 -rmFinita.
Что, тоже почувствовали, что вот-вот докажете правоту оппонента?
Нет просто лень заниматься софистикой. Потому что я точно так же могу провести вам "список сценариев".
В том числе, она может быть выражена и так
Она может быть выражена как угодно. Но формально исполнение вашего "find -type f -name '*~' -mtime -7 -rm" в консоли программированием не является.
И точно так же если мы не хотим "формально", то большинство людей(и даже большинство программистов) не назовет выполнение этой команды в консоли программированием.
Но формально исполнение вашего
А вы полагаете, что эти буквы там появятся самостоятельно, без какой либо мыслительной деятельности — или намеренно подменяете создание программы ее исполнением?
Так исполнение и не программирование, этого никто не утверждал.
Оно вообще не важно как они там появятся. Формально то что вы описали не удовлетворяет определению "программировать". Как минимум если брать определение из википедии.
Вы в саму вики-то заглядывали?
Программи́рование — процесс создания компьютерных программ
Процесс создания.
Не сохранение, не ввод. Весь процесс, от идеи, через формализацию, прототипиторование, отладку, и прочий рефакторинг — до готового изделия, будь оно бинарным артефактом, скриптом или однострочником.
Компью́терная програ́мма — 1) комбинация компьютерных инструкций и данных, позволяющая аппаратному обеспечению вычислительной системы выполнять вычисления или функции управления (стандарт ISO/IEC/IEEE 24765:2010)[1]; 2) синтаксическая единица, которая соответствует правилам определённого языка программирования, состоящая из определений и операторов или инструкций, необходимых для определённой функции, задачи или решения проблемы (стандарт ISO/IEC 2382-1:1993)[2].
Тут 1 явно распространяется исключительно на бинарные артефакты. Согласно этому пункту, программ на питоне, яве, эликсире, шарпе — не существует.
2 — синтаксическая единица <…> для определённой функции, задачи или решения проблемы
Причем вырезанная часть содержит рекуррентное определение, и потому иррелевантна.
Проблема формализована, задача поставлена и решена.
Реализация с find прошла через все те же шаги, что и реализация на, допустим, python.
Но вот эта реализация (тяпнуто с S-O, лень писать и отлаживать, уж простите, ради пустого спора об определениях)
import os, time
path = r"c:\users\%myusername%\downloads"
now = time.time()
for filename in os.listdir(path):
if os.path.getmtime(os.path.join(path, filename)) < now - 7 * 86400:
if os.path.isfile(os.path.join(path, filename)):
print(filename)
os.remove(os.path.join(path, filename))одной и той же программы для вас — Ъ, а реализация с помошью языка posix shell — не-Ъ.
Еще раз, вы говорите о программе, предъявляя претензии к ее имплементации.
Не сохранение, не ввод. Весь процесс, от идеи, через формализацию, прототипиторование, отладку, и прочий рефакторинг — до готового изделия, будь оно бинарным артефактом, скриптом или однострочником.
Вот именно. Не сохранение. Не ввод. Не дебаггинг. Весь процесс, а не отдельно взятые составляющие.
Еще раз, вы говорите о программе, предъявляя претензии к ее имплементации.
И ещё раз: я не говорю о программе. Я говорю о процессе.
Но можете привести своё определение программированию и мы можем его тоже обсудить.
И именно потому, что вы говорите о процессе, когда этот расписал вам процесс и задал наводящие вопросы, вы встали в позу и объявили каджита софистом.
Ню-ню.
Но можете привести своё определение программированию и мы можем его тоже обсудить.
Нам бы в вашем логические дыры залатать…
Потому по факту что ваши аргументы крутятся вокруг я художник, я так вижу, хоть вы и декларируете обратное.
Ну так приведите ваше определение и если оно будет лучше моего, то я с удовольствием буду использовать его. И тогда мы возьмём расписанный вами процесс и посмотрим как он попадает в в ваше определение. И останутся после этого какие-то вопросы или нет.
Вопросы были к вашему пониманию общедоступных определений. Точнее, к расхождению ваших деклараций этого понимания, с демонстрируемым поведением.
Выглядит это анекдотически.
Теперь вы пытаетесь переложить ответственность, но софист по прежнему каджит, да?
Только вот вопросы были к вашему пониманию общедоступных определений...
ORLY?
Этот вообще предлагал перестать спорить об определениях.
Но кидаться бездоказательными утверждениями, не опираясь факты, определения и логику, но лишь на глубоко личное понимание — никто не прекратил.
Пришлось разобрать эту цепочку, и выяснить, что:
- дебаг это не программирование — вот именно так вот, абсолютистски, даже если в процессе ты отрефакторишь полпроекта
- НО программирование это сложный процесс, включающий в себя дебаг
- написание программ это программирование
- НО если одна из имплементаций программы чем-то не понравится кое-кому, то это не программирование. Вот так вот, тут помню — тут не помню. А тут мы рыбу заворачивали
- если кое-кто сам себе противоречит, то он прав
- НО если это заметит каджит, то виноват каджит (видимо, нечего было провоцировать)
- если кое-кто сослался на определения в вики и сказал, что они противоречат — то он прав
- но если каджит разобрал и применил определения, и противоречий, ВНЕЗАПНО, не обнаружилось — снова виноват каджит
Знаете, ребят… это уже сильно смахивает на фрик-шоу. Дальше вы как-нибудь сами.
дебаг это не программирование — вот именно так вот, абсолютистски, даже если в процессе ты отрефакторишь полпроекта; НО программирование это сложный процесс, включающий в себя дебаг
Да, вот именно так! Ты можешь заниматься дебагом и программированием одновременно (=твоя деятельность в некоторый момент может попадать под оба определения), но дебаг от этого программированием не становится. Так же как рука человека не является человеком. Так же как ковыряние в носу не является программированием.
Что тут, блин, вообще сложного?!
Нет-нет-нет, Дэвид Блэйн.
Пока кто-нибудь из вас не сможет четко и внятно объяснить, каким образом форма побочного артефакта превращает программирование в сборку жигулей — никаких больше с вами споров об определениях.
Вот разберетесь с этой малостью — можно будет двинуться дальше.
Тут же ничего сложного, правда?
UPD: за минус к комменту извините, в сердцах клацнул не туда.
Вопросы были к вашему пониманию общедоступных определений.
Каких общедоступных определений? Если брать определение из википедии, то там всё относительно ясно и ваши "сценарии" под определение программирования не особо попадают.
Если у вас есть какое-то другое общедоступное определение, то киньте ссылку или процитируйте. И тогда посмотрим.
Ничем не отличается. Но мы сейчас обсуждаем не полученный результат, а процессы при помощи которых его получают. И вот они вполне себе могут отличаться.
Могут. Но не отличаются. И в том, и в другом, и в третьем случае мы пишем программу, потом нажимаем "выполняй", и шелл выполняет. Где мы ее пишем, какой у нее объем — совершенно безразлично.
И в том, и в другом, и в третьем случае мы пишем программу, потом нажимаем "выполняй", и шелл выполняет.
Ну вот процесс написания программы это программирование. А вот "нажатие выполняй" нет. Когда вы пишите скрипт(неважно где и как), то это программирование. Когда вы его выполняете — нет.
И да, вы можете написать скрипт в консоли и "сохранить" его там и потом сразу выполнить. И такое будет в том числе содержать в себе и процесс программирования. Но из-за этого любое выполнение каких-то команд в консоли программированием не становится.
Но из-за этого любое выполнение каких-то команд в консоли программированием не становится.
Еще раз. Сама консоль ничего кроме программ выполнять не умеет. Да, программа (скрипт) может быть вырожденной до единственного оператора.
Когда вы пишете echo "hello world" в консоли это ничем не отличается от написания кода в IDE, а нажатие Энтера — от нажатия кнопки Run.
Ещё раз. Выполнение программ это не программирование.
И да, можно попытаться натянуть написание строки с одной командой в консоли на определение программирования. Но формально это не оно.
И даже если отойти от формальностей то это нужно очень большую сову. И опять же большинство с этим наверняка не согласится.
И да, можно попытаться натянуть написание строки с одной командой в консоли на определение программирования. Но формально это не оно.
Оно самое, пусть в вырожденной форме. Иначе у вас программирование начинает зависеть от длины кода, количества запусков, объема мыслительной деятельности и тому подобного.
Иначе у вас программирование начинает зависеть от длины кода, количества запусков, объема мыслительной деятельности и тому подобного.
Нет. Иначе у нас программирование начинает зависеть от в том или ином виде персистированной программы. По определению.
Нет. Иначе у нас программирование начинает зависеть от в том или ином виде персистированной программы. По определению.
Не понял. Пожалуйста, разверните мысль подробнее.
Ну так "Программи́рование — процесс создания компьютерных программ". Где у вас создаётся эта самая компьютерная программа?
И например будет ли программированием запись в регистре которая приводит к запуску какой-то программы в момент загрузки ОС?
Ну так "Программи́рование — процесс создания компьютерных программ". Где у вас создаётся эта самая компьютерная программа?
Имеется в виду "в мозгу" или "в строке ввода"?
И например будет ли программированием запись в регистре которая приводит к запуску какой-то программы в момент загрузки ОС?
Здесь снова не понял. Для меня регистр это ячейка памяти процессора или периферии. При загрузке операционки она пользуется всеми своими регистрами.
Но попробую угадать: в командной строке загрузки ядра можно указать какие-то параметры вроде включения заставки, режима монтирования дисков, безопасной загрузки. Но мне казалось, это не программирование, а конфигурирование. То есть там не последовательность действий задается, а единое состояние.
Имеется в виду "в мозгу" или "в строке ввода"?
Где мы в результате имеем ту самую программу?
Но попробую угадать: в командной строке загрузки ядра можно указать какие-то параметры вроде включения заставки
Всё гораздо проще. У винды есть реестр он же registry. Туда можно писать много чего разного. В том числе и конфигурировать автостарт программ при загрузке ОС. Это программирование?
Где мы в результате имеем ту самую программу?
Ну допустим, в командной строке.
Всё гораздо проще. У винды есть реестр он же registry.
Вот про это точно бы не вспомнил. Насколько я помню, последовательность или алгоритм там задать невозможно. Значит не программирование, а конфигурирование. Вот в autoexec.bat уже скрипт.
Ну допустим, в командной строке.
То есть если я что-то напишу в командной строке, то это можно рассматривать как программу? Вот это программа и программирование:
Насколько я помню, последовательность или алгоритм там задать невозможно. Значит не программирование, а конфигурирование.
Извините а где написано что при программировании обязательно должна быть задана последовательность?
Если я запускаю какие-то параллельные/асинхронные процессы и меня не интересует в каком порядке они выполнятся, то это уже не программирование?
Вот это программа и программирование:
Не знаю. По крайней мере ваш шелл попытался распознать это как программу и не преуспел. С другой стороны, может вы просто забыли установить программу sss.
Извините а где написано что при программировании обязательно должна быть задана последовательность?
Последовательность это не в смысле "строго один за другим", если что. Важна возможность ее задать и способность интерпретатора выполнить. Будете ли вы ей пользоваться это уже ваше дело.
Если я запускаю какие-то параллельные/асинхронные процессы и меня не интересует в каком порядке они выполнятся, то это уже не программирование?
Интересный вопрос, ответа на который я не знаю: считать ли конфигурирование ПЛИС программированием. Обычно говорят что да, но алгоритма-то там нет, есть именно что конфигурация кучи ячеек, которые потом работают параллельно. Как и многие графические языки вроде Labview. Но если исходить из предназначения, "решить произвольную задачу", то да, программирование.
Не знаю. По крайней мере ваш шелл попытался распознать это как программу и не преуспел
Не, то что я там написал это программа и программирование? Ну то есть написать "sss" это оно или не оно?
Последовательность это не в смысле "строго один за другим", если что. Важна возможность ее задать и способность интерпретатора выполнить. Будете ли вы ей пользоваться это уже ваше дело.
Ну так в реестре это есть. Там записи идут одна за другой.
Интересный вопрос, ответа на который я не знаю: считать ли конфигурирование ПЛИС программированием
Причём здесь ПЛИС? Я в куче ЯП могу запускать параллельные и/или асинхронные вещи.
Так задавать последовательность обязательно или нет?.. Запись в реестре это программирование или нет?
Ну так в реестре это есть. Там записи идут одна за другой.
Сколько я помню реестр, это база данных. То, что в каком-то просмотровщике данные идут одно за другим, ничего не значит. Позволяет ли он задавать именно последовательность или хотя бы взаимосвязи команд?
Причём здесь ПЛИС? Я в куче ЯП могу запускать параллельные и/или асинхронные вещи.
Ну не хотите ПЛИС, я ведь и Labview предложил. А в более общем случае — функциональные языки. В общем, если есть возможность написать более-менее любой алгоритм, и работа идет именно через этот механизм — это программирование.
Так задавать последовательность обязательно или нет?.. Запись в реестре это программирование или нет?
см. выше: я не знаю как там в реестре устроено.
Позволяет ли он задавать именно последовательность или хотя бы взаимосвязи команд?
А почему это внезапно стало важно?
В общем, если есть возможность написать более-менее любой алгоритм, и работа идет именно через этот механизм — это программирование.
То есть последовательность задавать не обязательно?
см. выше: я не знаю как там в реестре устроено
А как это должно быть устроено чтобы это было программированием?
А почему это внезапно стало важно?
Ну мы же о программировании говорим, нет? Обычное программирование это выстраивание команд друг за другом в ориентированный граф (последовательность, но с условиями и циклами). Менее обычное вроде тех же ПЛИС или Labview — в описании взаимодействий между постоянно работающими блоками.
То есть последовательность задавать не обязательно?
Последовательность, как оказалось, это слишком узкий термин. Правильнее, наверное, алгоритм взаимодействия.
А как это должно быть устроено чтобы это было программированием?
Так я ж уже приводил примеры. Можно описать именно последовательность как в autoexec.bat. В порядке фантазии — можно прописать какие выходы одних программ соединены с какими входами других. Или, скажем, привязка к общим событиям.
Обычное программирование это выстраивание команд друг за другом в ориентированный граф (последовательность, но с условиями и циклами).
Кто это сказал? То есть где написано что это обязательное условие? Особенно учитывая что наличие параллельно/асинхронно выполняемых процессов в это не вписывается.
Правильнее, наверное, алгоритм взаимодействия.
Что такое "алгоритм воздействия"? Почему в скриптах он есть, а в реестре нет?
Так я ж уже приводил примеры
Не-не. Что надо поменять в реестре чтобы это стало программированием? Ну вот скажем в реестре есть несколько списков для запуска программ при старте. Сначала запускаются программы из списка 0, потом из списка 1, потом из списка 2 и так далее. Теперь это программирование?
Кто это сказал? То есть где написано что это обязательное условие? Особенно учитывая что наличие параллельно/асинхронно выполняемых процессов в это не вписывается.
А вы с какой целью вырвали половину цитаты и проигнорировали вторую, в которой и содержится ответ на ваш вопрос? Нехорошо так вести дискуссию.
Что такое "алгоритм воздействия"? Почему в скриптах он есть, а в реестре нет?
Это вы мне скажите, есть он в реестре или нет. Мне-то откуда знать?
Не-не. Что надо поменять в реестре чтобы это стало программированием?
Еще раз: я реестром не пользуюсь, если вам что-то в нем надо сделать, помочь я вам не смогу.
Еще раз: я реестром не пользуюсь, если вам что-то в нем надо сделать, помочь я вам не смогу.
Ну пусть будет не реестр а просто база данных с такой функциональностью. Это программирование?
Какая еще база данных для запуска программ? Чего вас все время куда-то в сторону уводит, а теперь еще и вообще в оторванную от реальности фантазию.
Если ваша система позволяет реализовать условно-любой алгоритм, работа с ней будет программированием.
Какая еще база данных для запуска программ?
Простая. Вы туда что-то записываете. Потом при старте ОС оттуда читается и запускаются внесённые в базу программы. Такой вариант это программирование.
Если ваша система позволяет реализовать условно-любой алгоритм, работа с ней будет программированием.
Что значит "условно любой алгоритм"? И что если в каком то языке программирования нельзя реализовать "условно любой алгоритм", а скажем только какое-то подмножество алгоритмов, то он уже не язык программирования?
Простая. Вы туда что-то записываете.
Повторяю вопрос: какое отношение ваша вымышленная база данных имеет к консоли? Такое ощущение, что вы меня на неточности формулировки поймать хотите.
Что значит "условно любой алгоритм"? И что если в каком то языке программирования нельзя реализовать "условно любой алгоритм", а скажем только какое-то подмножество алгоритмов, то он уже не язык программирования?
Хватит уже троллить, вы все прекрасно поняли.
Повторяю вопрос: какое отношение ваша вымышленная база данных имеет к консоли?
Она имеет отношение к вашему определению этого самого программирования. Которые вы так и не озвучили.
Хватит уже троллить, вы все прекрасно поняли.
Наоборот. Я уже запутался и вообще не могу понять что вы считаете программированием, а что нет.
Я понимаю только что именно работу в консоли вы программированием почему-то считаете. Вот и пытаюсь выяснить почему.
Я понимаю только что именно работу в консоли вы программированием почему-то считаете. Вот и пытаюсь выяснить почему.
Потому что ничего другого она не понимает, по крайней мере современная. Куда интереснее почему вы это отрицаете.
В чем по-вашему разница между вводом программы в IDE с последующим выполнением, и вводом программы в командную строку с последующим выполнением?
Потому что ничего другого она не понимает, по крайней мере современная.
От того что вы это считаете программированием оно автоматически не становится.
В чем по-вашему разница
В чём разница с записью чего-то в базу данных/реестр и последующихм выполнением?
С копированием файлов в различные папки и запуском всего что лежит в папках?
На мой взгляд разница например в том что в одном случае мы имеем именно саму программу, асв других нет.
И примеры это конечно здорово, но на одних примерах далеко не уедешь. У вас хоть какое-то формальное определение есть? Можете его озвучить?
От того что вы это считаете программированием оно автоматически не становится.
А от того, что вы это отрицаете, работа в командной строке программированием быть не перестает.
В чём разница с записью чего-то в базу данных/реестр и последующихм выполнением?
Опять вы от темы уходите. Мы не реестр обсуждаем и не базы данных. Ну либо сформулируйте какое они имеют отношение к теме.
У вас хоть какое-то формальное определение есть? Можете его озвучить?
Нет. Всегда появляются исключения.
А у вас есть?
Мы не реестр обсуждаем и не базы данных. Ну либо сформулируйте какое они имеют отношение к теме.
Мы обсуждаем программирование. Это по вашему программирование или нет?
А у вас есть?
Да. Ссылку на Википедию я уже приводил.
Мы обсуждаем программирование. Это по вашему программирование или нет?
Мы обсуждаем консоль. А угадывать является ли программированием каждая ваша вымышленная система, я не собираюсь.
Да. Ссылку на Википедию я уже приводил.
Согласно ей работа в консоли является программированием. Ну либо озвучьте чему из приведенного там она не соответствует.
Мы обсуждаем консоль.
Которая на мой взгляд программированием не является, а на ваш является. Поэтому сначала надо придти к общему пониманию термина программирование.
Согласно ей работа в консоли является программированием. Ну либо озвучьте чему из приведенного там она не соответствует.
Программирование это создание программ. При выполнение отдельных команд в консоли программы не создаются.
Можно конечно попытаться натянуть сову на глобус и утверждать что программа там создаётся.
Но тогда получается что запись в реестр/базу данных или копирование файлов в папку из описанных мною выше примеров тоже создание программирование.
Поэтому вопрос: вы это тоже считаете программированием? Если нет, то чему из приведенного в Википедии это не соответствует? Или может вы можете дать какое-то другое определение?
При выполнение отдельных команд в консоли программы не создаются.
Как же это не создаются. Или для вас и написание bat-файла или шелл-скрипта это не программирование? А ведь работа в командной строке это оно и есть. Разве что код не в файле хранится, а в памяти.
копирование файлов в папку из описанных мною выше примеров тоже создание программирование.
То есть по-вашему копирование файлов (про реестр и базы данных мы уже выяснили, что они к теме не относятся) это написание программ? Интересное у вас представление о программировании.
Или для вас и написание bat-файла или шелл-скрипта это не программирование?
Ну так написанный bat-файл или шелл-скрипт это программа, но их можно писать где угодно. А вот конкретно выполнение чего-го в командой строке само по себе не программирование.
Разве что код не в файле хранится, а в памяти.
Большая сова, маленький глобус. С той же логикой я могу заявить что записи в реестр/базу данных это тоже программы. И что список файлов и папок это тоже программа.
То есть по-вашему копирование файлов (про реестр и базы данных мы уже выяснили, что они к теме не относятся) это написание программ?
По моему нет. Точно так же как и выполнение команд в консоли.
Вопрос в том считаете ли вы это всё программированием и если нет, то где, как и почему вы проводите разделение. И хотелось бы увидеть определение программирование под которое попадает такое разделение.
Ну так написанный bat-файл или шелл-скрипт это программа, но их можно писать где угодно
Ну наконец-то вы это признали! Именно что где угодно, в том числе прямо в командной строке.
А вот конкретно выполнение чего-го в командой строке само по себе не программирование.
Ну разумеется, выполнение кода и его создание это разные вещи.
С той же логикой я могу заявить что записи в реестр/базу данных это тоже программы.
Вы этот бред повторяете уже раз пятый, и до сих пор не придумали как же они связаны с программированием.
Вопрос в том считаете ли вы это всё программированием и если нет, то где, как и почему вы проводите разделение.
"все это" это что? Написание программ (в IDE, в блокноте, в командной строке) это программирование. Мы объясняем компьютеру алгоритм достижения нужного результата. Где у вас в реестре или базе данных алгоритм?
И хотелось бы увидеть определение программирование под которое попадает такое разделение.
Ну, в первом приближении определение из википедии подходит. Правда, вы на него умудрились копирование файлов натянуть. И не делитесь травой, которая вас к этому привела.
Именно что где угодно, в том числе прямо в командной строке.
Или в мозгу или на листке бумаги или в реестре или в базе данных или в виде файлов и папок. Где вы проводите границу и почему именно там?
Вы этот бред повторяете уже раз пятый, и до сих пор не придумали как же они связаны с программированием.
Ну так я хочу понять почему вы это не считаете программированием. Это не соответствует определнию из Википедии? В каком конкретно месте?
Это не соответствует какому-то другому определению программирования? Какому именно?
"все это" это что?
Озвученные мною выше примеры с реестром/базой данный и файлами/папками. Это программирование или нет?
Правда, вы на него умудрились копирование файлов натянуть. И не делитесь травой, которая вас к этому привела.
Точно так же как вы умудрились на него натянуть выполнение команд в консоли.
Или в мозгу или на листке бумаги или в реестре или в базе данных или в виде файлов и папок. Где вы проводите границу и почему именно там?
О, уже дошли до того, что важно не где пишут, а что пишут. Осталось всего ничего — осознать почему интерпретатор командной строки называется интерпретатором.
Ну так я хочу понять почему вы это не считаете программированием.
Вы же понимаете, что я физически не смогу это ни доказать, ни опровергнуть, потому что что вы там нафантазировали ведомо только вам. Может у вас реестр или база данных какие-то особые, что код выполнять умеет.
Точно так же как вы умудрились на него натянуть выполнение команд в консоли.
Вы так и не придумали как это опровергнуть.
О, уже дошли до того, что важно не где пишут, а что пишут.
Нет, не дошли.
Вы же понимаете, что я физически не смогу это ни доказать, ни опровергнуть,
Тогда просто озвучьте ваше определение программирования.
Может у вас реестр или база данных какие-то особые, что код выполнять умеет.
А зачем им уметь код выполнять? Если вы код в IDE или там блокноте пишете они его тоже выполнять не умеют.
Вы так и не придумали как это опровергнуть.
Придумал. По крайней мере получается либо выполнение команд в консоли не программирование, либо реестр/базы данных/файлы в папках это тоже программирование. Для меня более логичен первый вариант. А для вас?
Нет, не дошли.
Значит, все еще печальнее...
Тогда просто озвучьте ваше определение программирования.
Так чем вас не устраивает ваше же из википедии?
А зачем им уметь код выполнять? Если вы код в IDE или там блокноте пишете они его тоже выполнять не умеют.
А, так вы в реестре и базе данных код для Питона пишете. Месье знает толк...
Придумал. По крайней мере получается либо выполнение команд в консоли не программирование, либо реестр/базы данных/файлы в папках это тоже программирование. Для меня более логичен первый вариант. А для вас?
Так расшифровка-то этого псевдо-логического умозаключения будет или нет? Как у вас копирование файлов на программирование натягивается?
Так чем вас не устраивает ваше же из википедии?
Тем что без натягивания совы на глобус выполнение команд в консоли под него не попадает. А с натягиванием под него попадает куча всего разного. В том числе и перечисленные мною выше примеры.
А, так вы в реестре и базе данных код для Питона пишете.
Откуда вы это взяли?
Так расшифровка-то этого псевдо-логического умозаключения будет или нет?
Так ответ на мой вопрос будет или нет?
Как у вас копирование файлов на программирование натягивается?
Ну вот я скопировал файлы по папкам. Потом запускаю "интерпретер", он сортирует файлы и папки и потом начинает запускать файлы в том порядке как они отсортированы. Это программирование?
Тем что без натягивания совы на глобус выполнение команд в консоли под него не попадает.
А написание в блокноте с последующим запуском? Вы ж сами говорили, что запуск скрипта на исполнение программированием не является.
Откуда вы это взяли?
Ну вы же пытаетесь доказать, что написание чего-то в реестре или базе данных является программированием. Насколько мне известно, ни то, ни другое выполнять код не умеют. Значит, вы пишете для какого-то другого компилятора или интерпретатора. Или у вас база данных и код выполнять умеет?
Так ответ на мой вопрос будет или нет?
Вы пока сами не ответили на вопрос. Пока я не узнаю что вас заставляет относить реестр к программированию, мне опровергать нечего.
Ну вот я скопировал файлы по папкам. Потом запускаю "интерпретер", он сортирует файлы и папки и потом начинает запускать файлы в том порядке как они отсортированы. Это программирование?
Да, вполне возможно. Кстати, такой подход реально используется. Сложных задач так, конечно, не решают, но вот обеспечить правильный порядок запуска и останова программ при старте системы вполне можно. А уж если некоторые программы будут переименовывать других, менять значение счетчика и т.п., можно вообще тьюринг-полный язык получить.
А написание в блокноте с последующим запуском?
Написание в блокноте в данном случае это программирование. После написания мы имеем программу, которую можем запускать.
Ну вы же пытаетесь доказать, что написание чего-то в реестре или базе данных является программированием.
И где там хоть слово про питон? Я вам выше уже несколько раз описал примеры о которых идёт речь.
Пока я не узнаю что вас заставляет относить реестр к программированию, мне опровергать нечего.
Записал в реестр пути к программам. При старте ОС считала их оттуда и эти программы запустила. Это программирование?
Да, вполне возможно.
То есть когда кто-то копирует файлы или ярлыки в папку "автозапуск" у винды, то он программирует?
Написание в блокноте в данном случае это программирование. После написания мы имеем программу, которую можем запускать.
Хорошо. А если вы написали скрипт из единственной команды?
И где там хоть слово про питон? Я вам выше уже несколько раз описал примеры о которых идёт речь.
Да на здоровье, пусть не Питон, а Си, или Java, да хоть Брейнфак. Вы же код собрались в базе данных писать, а сама она его выполнить не сможет.
Записал в реестр пути к программам. При старте ОС считала их оттуда и эти программы запустила. Это программирование?
Там можно задать условие, цикл, рекурсию или еще какую-то зависимость от данных?
Хорошо. А если вы написали скрипт из единственной команды?
Мы всё ещё имеем написанную программу.
Вы же код собрались в базе данных писать, а сама она его выполнить не сможет.
И что? Я вон пишу код в текстовые файлы и храню их на диске. И ни мой редактор кода, ни моя ОС сами по себе их тоже выполнять не могут.
Там можно задать условие, цикл, рекурсию или еще какую-то зависимость от данных?
А почему это должно быть обязательным условием? Если кто-то напишет программу без всего этого, то она не будет программой?
Мы всё ещё имеем написанную программу.
А собственно все. Нет никакой разницы сохраните вы этот код на жесткий диск или в историю команд. Это код.
А почему это должно быть обязательным условием? Если кто-то напишет программу без всего этого, то она не будет программой?
Зачем вы пытаетесь вывернуть все с ног на голову. Безразлично как устроена конкретная программа. Безразлично где она хранится и хранится ли вообще. Важно только что она описывает алгоритм и предназначена для выполнения.
Так и интерпретатор командной строки. Он потому и интерпретатор, что предназначен интерпретировать скрипты. Поэтому даже если вам нужен запуск единственной программы без параметров, приходится писать скрипт и отдавать на интерпретацию. Вы не сможете ничего добиться от консоли, пока не напишете ей код, хотя бы и простейший из одной команды.
А реестр, насколько я понял из ваших слов, для этого не предназначен. Возможно, при должной упоротости, программировать в нем возможно, но не любое действие будет являться программированием.
Нет никакой разницы сохраните вы этот код на жесткий диск или в историю команд. Это код.
Ну для вас нет. Для меня есть. Потому что если разницы нет, то и реестр со списком путей у нас вдруг программа и папки с файлами.
Зачем вы пытаетесь вывернуть все с ног на голову.
Зачем вы добавляете какие-то странные условия под которые даже обычные программы перестают попадать?
Безразлично как устроена конкретная программа. Безразлично где она хранится и хранится ли вообще. Важно только что она описывает алгоритм и предназначена для выполнения.
Тогда реестр винды это программа. И папка "автостарт" это программа.
А реестр, насколько я понял из ваших слов, для этого не предназначен.
Ну так консоль она как бы тоже не предназначена для программирования.
Ну для вас нет. Для меня есть.
Для вас есть разница на каком носителе записана программа?! Типа как если на жестком диске, то программа, а на оптическом уже не тру?
Потому что если разницы нет, то и реестр со списком путей у нас вдруг программа и папки с файлами.
Пошли на очередной круг. Покажите как в реестре посчитать 2+2.
Зачем вы добавляете какие-то странные условия под которые даже обычные программы перестают попадать?
Это какие? Сколько помню, это только вы добавляете какие-то странные условия вроде того чтобы программа была обязательно сохранена на ПЗУ.
Тогда реестр винды это программа. И папка "автостарт" это программа.
Ну если у вас такие странные определения, что ж тут поделаешь...
Ну так консоль она как бы тоже не предназначена для программирования.
Что значит не предназначена?! Она только для этого предназначена.
Для вас есть разница на каком носителе записана программа?
Так на каком носителе она записана в консоли?
Пошли на очередной круг. Покажите как в реестре посчитать 2+2.
Почему это должно являться необходимым условием для того чтобы что-то считалось программой?
Кроме того далеко не каждая консоль поддерживает математику "из коробки".
Это какие?
Какой-то порядок исполнения должен обязательно быть. Циклы. Возможность "посчитать 2+2". И так далее и тому подобное.
Ну если у вас такие странные определения, что ж тут поделаешь...
Ну так вы с этим согласны? Если нет, то каким определением вы пользуетесь?
Что значит не предназначена?! Она только для этого предназначена.
Я бы сказал что консоль предназначена для выполнения чего-то там. Но не для программирования.
Так на каком носителе она записана в консоли?
В оперативке, очевидно. Пока вы не нажали энтер, программа ведь где-то хранится.
Почему это должно являться необходимым условием для того чтобы что-то считалось программой?
Да что ж вы только критикуете-то не по существу. Ну не нравится мой пример, так свой приведите.
Ну если у вас такие странные определения, что ж тут поделаешь…
Ну так вы с этим согласны?
С тем, что у вас странные определения, которые то ничего не определяют, то определяют не то, что надо? Так это с самого начала было очевидно.
Я бы сказал что консоль предназначена для выполнения чего-то там.
Еще одно прекрасное определение, ну да ладно.
В очередной раз спрашиваю: почему, как вы думаете, интерпретатор командной строки называется именно интерпретатором?
В оперативке, очевидно
С каких пор оперативка стала носителем?
Да что ж вы только критикуете-то не по существу
Вполне себе по существу. У вас ваши требования постоянно меняются и похоже берутся просто с потолка.
Ну не нравится мой пример, так свой приведите.
Ну так я привёл. Даже несколько.
В очередной раз спрашиваю: почему, как вы думаете, интерпретатор командной строки называется именно интерпретатором?
Потому что он интерпретирует ввод? Но далеко не любая интерпретация означает что интерпретируется именно программа.
С каких пор оперативка стала носителем?
С тех самых, как в ней стало возможно хранить произвольную информацию. То есть всегда.
Вполне себе по существу. У вас ваши требования постоянно меняются и похоже берутся просто с потолка.
И опять у вас все с ног на голову. Не я пытался притянуть за уши реестр и базы данных.
Ну так я привёл. Даже несколько.
Где?! Где вы привели хоть один пример алгоритма, реализуемого на реестре или базе данных? Ну кроме поочередного запуска фиксированного списка программ.
Потому что он интерпретирует ввод?
Что еще за "интерпретация ввода"? Парсинг что ли? Так нет, парсинг это лишь малая часть.
Ладно, подскажу: что такое интерпретатор вообще и чем он отличается от компилятора?
И подскажу с другой стороны: отличается ли синтаксис программ, вводимых в командную строку из скрипта и интерактивно?
С тех самых, как в ней стало возможно хранить произвольную информацию
Я смотрю у вас ещё и какое-то своё собственное определение носителей...
. Не я пытался притянуть за уши реестр и базы данных.
Реестр и базы данных это не требования, а примеры. Требования это ваше "надо чтобы можно было считать 2+2"....
Где вы привели хоть один пример алгоритма, реализуемого на реестре или базе данных? Ну кроме поочередного запуска фиксированного списка программ.
А чем это не алгоритм? Простой, но всё ещё алгоритм.
Что еще за "интерпретация ввода"?
Самая обычная.
Ладно, подскажу: что такое интерпретатор вообще и чем он отличается от компилятора?
Вы сначала определитесь что такое интерпретатор и какие они вообще бывают. Интерпретаторы существуют не только в контексте программ и программирования.
Я смотрю у вас ещё и какое-то своё собственное определение носителей...
Да нет, похоже, это у вас...
Реестр и базы данных это не требования, а примеры. Требования это ваше "надо чтобы можно было считать 2+2"....
То есть примеров вы привести так и не можете, только отмазки...
А чем это не алгоритм? Простой, но всё ещё алгоритм.
Тем, что не универсальный, очевидно. Ежу понятно, что единственную задачу, на которую приложение рассчитано, оно выполнит и без программирования.
Самая обычная.
Ага, ответа нет, значит вы и сами не знаете и пытаетесь словом "очевидно" это скрыть.
Вы сначала определитесь что такое интерпретатор и какие они вообще бывают.
Этот наводящий вопрос я вам задал, не надо пытаться его вернуть.
Да нет, похоже, это у вас...
С Википедии :
Носи́тель информа́ции (информацио́нный носи́тель) — любой материальный объект или среда[уточнить], используемый человеком, способный достаточно длительное время сохранять (нести) в своей структуре занесённую на него информацию, без использования дополнительных устройств (например, источника энергии).
А какое у вас определение?
То есть примеров вы привести так и не можете, только отмазки...
Так привёл же.
Тем, что не универсальный, очевидно.
Мне не очевидно. Алгоритм и есть.
Этот наводящий вопрос я вам задал, не надо пытаться его вернуть.
Я без понятия зачем вы его задали и что этим хотели сказать. Но использование слова "interpreter" не означает автоматом что речь идёт о программированнии.
То есть примеров вы привести так и не можете, только отмазки…
Так привёл же.
Отмазки продолжаются, а примеров как не было, так и нет.
Мне не очевидно. Алгоритм и есть.
Если программа решает одну-единственную задачу, можно ли ее считать интерпретатором языка программирования?
Я без понятия зачем вы его задали и что этим хотели сказать. Но использование слова "interpreter" не означает автоматом что речь идёт о программированнии.
О, кажется, вы начинаете подозревать, что интерпретатор в данном контексте означает именно то, что означает, а не то, чего бы вам хотелось.
Отмазки продолжаются, а примеров как не было, так и нет.
Примеров чего?
Если программа решает одну-единственную задачу, можно ли ее считать интерпретатором языка программирования?
А почему нет?
О, кажется, вы начинаете подозревать, что интерпретатор в данном контексте означает именно то, что означает, а не то, чего бы вам хотелось.
Я вообще ничего не начинаю подозревать. Вы свой тезис сформулируйте сначала.
Примеров чего?
То есть вы даже не знаете, какие примеры "привели". Великолепно!
Примеры программирования в реестре чуть сложнее банального запуска заданного набора программ.
А почему нет?
Я уже говорил, что у вас странные определения. По ним выходит, что все — программирование.
Я вообще ничего не начинаю подозревать. Вы свой тезис сформулируйте сначала.
Хорошо, дам сразу правильный ответ. Интерпретатор командной строки потому и интерпретатор, что интерпретирует скриптовый язык, для каждой консоли свой. А поскольку этот язык изначально создавался для гибкой работы со сторонними программами, то и интерактивный режим там реализован ровно так же — вводом программы. Обратите внимание, что процесс программирования в консоли ничем не отличается от программирования в какой-нибудь IDE: сначала код вводится, редактируется, просматривается, и только потом запускается на исполнение.
Разумеется, есть текстовые интерфейсы, устроенные по другим принципам. В первую очередь примитивные диалоговые в некоторых программах. Вроде "введите то, введите это, нажмите 1 чтобы выйти". Сюда же взаимодействие с некоторыми железяками, которые понимают только отдельные команды, но не код. Бывают TUI вроде mc, nv, vc — даже при наличии там системной консоли сами эти среды заточены под ручное управление, а не под написание скриптов.
Но, напоминаю, обсуждали мы именно системную консоль, причем именно в современных распространенных операционных системах. Понятно, что можно найти какого-нибудь 8-битного динозавра с примитивной диалоговой консолью. Они сюда не относятся.
А вот GUI программированием не является, там именно что ручной вызов отдельных действий. Именно поэтому для автоматизации действий в GUI приходится изобретать сторонние программы — кликеры, виртуальные графические серверы и т.д.
То есть вы даже не знаете, какие примеры "привели". Великолепно!
Какие я привёл я знаю. Я не понимаю какие вы ещё хотите и чем вас мои не устраивают.
Примеры программирования в реестре чуть сложнее банального запуска заданного набора программ.
Не вижу почему я должен приводить что-то "чуть сложнее ". Примеры есть и они являются программированием в вашем понимании. Ну или дайте наконец-то ваше определение.
Я уже говорил, что у вас странные определения. По ним выходит, что все — программирование.
Так это не у меня, это у вас. По моему мнению всё это не программирование. Как реестр, так и ввод команд в консоли.
Хорошо, дам сразу правильный ответ.
Очень много букв и интересное мнение. Но не более того. И я с ним просто не согласен. И похоже не только я.
Но я с удовольствием поменяю свою точку зрения если вы сможете привести ваше личное адекватное определение этого самого "программирования". И тогда мы его обсудим и посмотрим.
Не вижу почему я должен приводить что-то "чуть сложнее ".
Ну вот сами видите, что ни для чего кроме одной конкретной задачи ваша система не годится. Хотя с вашими "определениями" это может быть хоть программированием, хоть кошкой.
Очень много букв и интересное мнение. Но не более того. И я с ним просто не согласен. И похоже не только я.
Но обосновать не можете.
Просто не хотите признавать, что написание домохозяйкой одной строчки в консоли является программированием в не меньшей степени, чем написание ей же одной строчки в консоли какого-нибудь Питона. Поймите, быть программистом и писать хелло-ворлды это далеко не одно и то же.
Но я с удовольствием поменяю свою точку зрения если вы сможете привести ваше личное адекватное определение этого самого "программирования".
Кого вы пытаетесь обмануть? Вам мое определение нужно не для того, чтобы его использовать, а чтобы к нему цепляться, искать исключения, придумывать бредовые примеры, не относящиеся к делу. Для срача, а не для дискуссии.
Ну вот сами видите, что ни для чего кроме одной конкретной задачи ваша система не годится.
И что? От этого это не перестаёт быть программированием.
Но обосновать не можете.
Я этим как раз и занимаюсь ту всё время.
Просто не хотите признавать, что написание домохозяйкой одной строчки в консоли является программированием в не меньшей степени, чем написание ей же одной строчки в консоли какого-нибудь Питона.
А с этим я и не спорю. И я уже выше писал что ни то, ни другое программированием не является :)
Вам мое определение нужно не для того, чтобы его использовать, а чтобы к нему цепляться, искать исключения, придумывать бредовые примеры, не относящиеся к делу
Ну так вы дайте нормальное определение которое сразу всё поставит на свои места. И всё. В чём проблема? Может быть в том что у вас вообще никакого нет?
И что? От этого это не перестаёт быть программированием.
А с этим я и не спорю. И я уже выше писал что ни то, ни другое программированием не является :)
То у вас программирование (написание кода на Питоне) программированием не является, то не-программирование (запуск фиксирвоанного списка программ) является. Причем одновременно. И после этого вы будете что-то там вещать про определения?
Я этим как раз и занимаюсь ту всё время.
Ну хватит врать-то! Все время вы пытаетесь подловить меня на неточности формулировок, а вовсе не сравнить процессы программирования, работы в консоли и GUI.
Ну так вы дайте нормальное определение которое сразу всё поставит на свои места.
Так оно вас тоже не устроит и вы снова кинетесь натягивать сову на глобус лишь бы с ним не соглашаться. Раз уж вы редактирование реестра в программирование записали.
Ну хорошо, попробуем еще раз. Формальная запись алгоритма для решения машиной произвольной задачи.
То у вас программирование (написание кода на Питоне) программированием не является
Выполнение команд питона в консоли у меня программированием не является.
то не-программирование (запуск фиксирвоанного списка программ) является.
И это у меня программированием не является.
Причем одновременно.
Нет. Либо и то и другое программирование, либо ни то ни другое не программирование. Я выбрал для себя второй вариант. А вы?
Формальная запись алгоритма для решения машиной произвольной задачи.
Тогда ваше выполнение команд в командной строке программированием не является. Потому что не позволяет выполнить любую произвольную задачу.
Выполнение команд питона в консоли у меня программированием не является.
Ну а у нормальных людей программирование на Питоне программированием является.
И это у меня программированием не является.
А кто тут врал будто редактирование реестра это программирование?
Тогда ваше выполнение команд в командной строке программированием не является. Потому что не позволяет выполнить любую произвольную задачу.
Докажите.
Ну а у нормальных людей программирование на Питоне программированием является.
Программирование на Питоне является программированием. Выполнение отдельных команд в консоли нет.
Докажите
Посчитайте мне пожалуйста в консоли число Пи.
Программирование на Питоне является программированием. Выполнение отдельных команд в консоли нет.
Так в чем разница-то?
Посчитайте мне пожалуйста в консоли число Пи.
Вас в гугле забанили? Первая же ссылка выдает https://stackoverflow.com/questions/23524661/how-can-i-calculate-pi-using-bash-command
$ { echo -n "scale=50;"; seq 1 2 100 | xargs -n1 -I{} echo '(16*(1/5)^{}/{}-4*(1/239)^{}/{})';} | paste -sd-+ | bc -lА теперь, гуру реестра, приведите-ка решение на нем. Или на базе данных, или на копировании файлов.
Почему linux должен быть единственной системой в образовательном процессе