Спасибо за объяснение, и наверное непринадлежность к этой группе людей мешает мне это понять. Так как считаю, что заметают следы там, где они остаются. При выполнении команд они не остаются. Там не протоколлируется, всё, что исполняется Поэтому усложнение цикла команд и подстановка через стек - считаю просто шаги для может быть и анализа, но когда файл заражён, а это выясняется быстрее, то это уже по моему факт, что что-то пойдёт не так, как надо. А детали - в каком месте и как - это уже несущественно. Но, это я так считаю. Просто увидев название, подумал, что для своих лекций по внутреннему строению будет неплохо. На самом деле было что-то не то. Спасибо.
Замок - это такая вещь, с помощью которой закрывают дом, авто или сейф от посторонних, но также с помощью которого злоумышленники вскрывают их. Похожее можно и про язык программирования сказать и про кухонный нож итд.
В первую очередь стек, это где складываются те данные, которые во время работы или вызовов функций должны быть временно сохранены. Соединить эту основную функцию стека в одном предложении с возможностью им манипулировать и назвать это как Обзор Stack Memory -не знаю, как то не подходит.
Второе, что мне не совсем понятно. Если уж вредоностный код в состоянии быть вызванным и может уже что-либо исполнять, то зачем вся эта катавасия с подменой адреса возврата?
Не соглашусь с вами но с вашим оппонетом. Можно на коленке но сделать надёжное устройство, и да - и на ардуине. А можно вроде подойти профессионально но всё равно сделать несовершенство. Но направо и налево вешать первым делом ярлыки- больше о вас рассказывает, чем о тех, на кого ярлыки вешается. Но это так - на заметку.
теперь о простом подходе. Ваш подход хороший. И идея, сделать все от и до - самому - тоже имеет свои плюсы.
Например, если бы я взялся за такое задание, то может быть взял за основу настоящую простую USB мышь плату и вывел все кнопки, и сенсоры позиционирования наружу. Те. заниматься софтом в принципе и не пришлось бы, тк. плата рабочая и может с компом соединяется. Особенно проще было бы, если мышь была бы чуточку старенькая или очень дорогая, но современная, но тогда цена возрастает, тк. там очень часто не инфраротовое определение позиции а именно физическое с помощью шарика и через кнопки...или четыре по осям, или 8 с доп. по диагоналям тоже.
Просто практическое применение несколько отрезвляет
ну вот — опять всё портите :) А такой масштаб для маркетинга имеет место быть! Не всем-же обязательно знать, что в их вычислительном процессе где-нибудь будет узкое место (bottleneck) — продаваться ведь может в общем на ура. А потом и на поиски этого «узкого места» можно и новые проекты поставить на ноги и доп. буджет освоить итд.
Такой радикальный подхот замечаю при внедрении новых систем, где необдуманно за основу берётся какая-нибудь функция, которую старая система вроде хуже делала, но при этом полностью или частично пренебрегаются и другие, немаловажные функции. И когда система запускается, начинается бесконечное допиливание системы. Потому что старая система не настолько была плохая, как её описывали, чтобы продать/купить новую.
Конкретный пример. У нас в новой архитектуре предусмотрели замену импорта данных на JSON, который раньше был на csv. Ведь это так модерно и круто. А то, что время импорта потом увеличилось в разы — это никого поначалу не волновало, ведь в Big Data все так делают. И не важно, что схема файла почти никогда не будет изменена. Потом приходит осознание, но после этого — многое уже просто так не вернёшь назад. Только за деньги и кучу времени.
Я просто хотел принцип услышать, а не то, что в каком-то языке для этого функция есть. Примеры с сортировком в том и заключаются, что человек понимает суть команды, неважно в c# или в Javе, потому что известно, что за команой .Sort стоит например Quick Sort алгоритм. Но всё равно — спасибо. Попробую посмотреть в этом направлении. Может быть что-нибудь найду интересное.
Если избавиться от CPU, всё будет немножечко лагать. Так делать не надо.
Извиняюсь, но так инженеры не выражаются. Это первое. Второе. Я рассказываю своим студентам тоже разницу между CPU и GPU. Так вот. Если провести параллель, то CPU это пассажирский самолёт, а GPU — истребитель. Можно их сравнивать? Ну для детского воображения — да. Но не взаимоисключающе, а как для своих нужд хорошо отлаженные инструменты.
Не вдаюсь в детали, но сравнение неуместно. Потому что вроде идёт разговор о замещении одного другим, но список задач сводится к шейдерам. Но организация компьютера — это не треугольники и шейдеры. Это намного больше. И CPU занимается своим делом, а GPU и видеокарта — своим. И почему-то уверен, что так и останется ещё долгое время. Архитектура Von-Neumann уже не одно десятилетие пережило. Конечно оба можно в одно интегрировать, но сказать, что одно можно заменить другим — не является истинной. В таких вещах разделение задач только на пользу.
Не совсем понятно, что под сравнением должно быть понято. Есть текст, есть, форматы (цвета, шрифты, размер букв, ориентация итд.), графики, таблицы, комментарии, форматирование чусел, видимые и невидимые аттрибуты итд… Если ориентироваться на что-то определённое, то и можно будет «выбрать» стратегию для реализации…
Хорошие слова. Полностью с Вами согласен. Именно их буду говорить своим студентам, когда будем проходить темы — техническое строение и функционирование микропроцессоров и основы ассемблера. Голосовать не могу. Поэтому только так — Большое спасибо.
Думаю, не только ко мне этот вопрос. Кстати интересный. Потому что в принципе описание процессов только из одной перспективы, как в вашем пиимере - отдела кадров - не самое оптимальное. Всевозможные темы имеют много чего общего, хотя и кое какие специфические вещи. И вот это общее - универсально настолько, что может почти без изменений кочевать из одной темы в другую. Пример с approval workflow ( процессы утверждения). В процессах, которые описывают проекты, есть цепочки для последующего разрешения или изменения статуса. Точно такие же процессы есть и в отделах кадров, в документо-обороте, в процессах при работе с внешними фирмами, экспертами итд. Похожие процессы протекают и в "кишках" любого микропроцессора, или например описание для Tasks, process или job у операционных симтем. Поэтому изобретать велосипед в каждой новой теме не стоит. Стоит видеть похожести. Это облегчает усилия сокращает время и проще для понимания или видоизменения потом. Думаю интернет полон всякими примерами. Есть ли у вас более конкретные вопросы? Потому что разговаривая о BPMN мы разговариваем меньше об этом, и больше о том, как работают или должны работать фирма, отдел, программа, какая-то функция или операция итд. Те. по большей частью о том, что нас окружает. И только маленькая часть - это нотации и описание. С удовольствием поделюсь, если будут вопросы.
полностью с Вами согласен. Приведу свой пример, хоть он немного из другой, нешкольной области. Работаю в Германии доцентом. Как раз по разным темам из it — начиная от железяк до софта и bigdata. Как по школам, так и по университетам — все детали образования — это задача отдельных земель, городов и школ. Нет 100% программы, которая везде одинаковая — общий контроль есть. Но он по-большей части например у меня — от студентов. Т.е. по окончании семестра у них есть возможность оценить моё преподавание по разным кретериям. При наличии дефицитов — будут разговоры с руководителями института. Но. Хоть и темы для обучения оговорены, как это будет преподнесено — моё личное право. И лекцци похожих доцентов из разных городов — различаются по оформлению, качеству, глубины преподнесения вевозможных тем итд. Т.е. имеется наличие своего рода свобод. Но нет никакой анархии в виде безконтрольности. Я, например в своём семестре имею практические занатия с платами Arduino. У других доцентов такого не слышал. А мне это помогает соеденить смежные темы — ассемблер, сотваляющие и работа микроконтроллера, алгоритмы, работа со всевозможными структурами, как например стек, регистры итд. И без этих плат можно обойтись, но с ними многие вещи становятся понятнее. И студенты об этом сообщают в своих рекомендациях к семестрам.
И ещё один момент но его задам с осторожностью. Могу ошибиться , тк. уже более 20 лет не живу в среде русского языка, но мне кажется, что ваше выражение
Помните, что операторы if — это далеко не все зло.
...должно подниматься так, что if операторы - уже зло. Но они не одни есть зло, есть и другие злые вещи. А я вам скажу своё мнение, что сам оператор не есть зло. Злом может быть необдуманное его использование, которое сильно усложняет читаемость кода, а также возведение этого оператора в своего рода ранг табу и после - "борьба" против его использования. Так называемая охота на ведьм.
Дорогой автор, даже, если вам не нравятся другие мнения, всё равно стоит к ним прислушаться. Объясню почему.
В первом случае вы привели тривиальный случай, который 1:1 повторяет if оператор - те. вы заменили этот if оператор на две функции. А что делать, если внутри функции три и более if оператора? Заменять их на n! количество функций? У меня названий не хватит, если я вместо 4-х if(ов) 24 функции напишу, каждая из которых отдельную ситуацию воспроизведёт.
Это первое. Второе. Как бы вы не упрощали, вам всё равно выше по хирархии вызовов надо будет де-то принимать решение, какую из реализаций вызывать. Поэтому видение в if чего-то, чем надо пренебрегать - есть нежелание согласится с чем-то обычным. Таким-же как, если из одного города до другого надо доехать, то это потребует времени. Да, вместо велосипеда одно взять быструю машину но всё равно- какое-то время это потребуется. Очевидно.
В последнем примере опять-же тривиальный случай с типом string. А что делать, если функция возвращает другие типы данных? Например тот-же самый созданный файл, который не смог быть открытым, тк. места на плате нет или нет прав на создание. Что вы там за default value возьмёте?
Не понимаю. весь ассемблер набит функциями по переходу в зависимости от значения или состояния в аккумуляторе. Под это и создаётся оператор if, ну те. он потом с лёгкостью переводится в набор ассемблер команд.
Если вы не видите похожести, что при описании, даже BPM-системы, нужны принципы описания, которые вы и пытаетесь создать. И идея правильная, но уже существуют реализации. И, не плохие. Я вам про грамматику, вы мне — но я-же книгу пишу.
Мы видим это в разных плоскостях. А жаль.
Я думаю под этим словом глючит не стоит ничего. Просто ярлык. Есть процессоры с их микрокодом, ассемблер. ОС, язык. Когда процессор глючил, например от Intel, то на софт-уровне эту проблему на какое-то время исправили.
Если кто-то говорит, что язык глючит, то единственное, что может в этом случае иметь место - компилятор языка сырой и требует доработки. Если язык сам по себе имеет логические или синтаксические ошибки, то он никогда не выйдет на большую сцену. Не знаю таких.
А кто вам лично мешает создавать ОС, браузеры или прикладные программы на неглючных языках писать, как вы выражается? Смешивается всё в кучу. Программирую на многих языках, вплоть до ассемблера. Ни один из них не могу назвать глючным. Один для одного типа задач, другой - для другого. Но фигни на них написать всегда можно. Но это как и с человеческим языком. Можно 50-ю словами всю жизнь обходиться и после каждого второго слова мат для связки слов использовать. А можно и так, что и 50 тысяч слов не будет хватать. Ваша абстракция с суперменом больше говорит о вас, чем о теме, которую вы затрагиваете. Зачем так сложно?
Спасибо за объяснение, и наверное непринадлежность к этой группе людей мешает мне это понять. Так как считаю, что заметают следы там, где они остаются. При выполнении команд они не остаются. Там не протоколлируется, всё, что исполняется Поэтому усложнение цикла команд и подстановка через стек - считаю просто шаги для может быть и анализа, но когда файл заражён, а это выясняется быстрее, то это уже по моему факт, что что-то пойдёт не так, как надо. А детали - в каком месте и как - это уже несущественно. Но, это я так считаю. Просто увидев название, подумал, что для своих лекций по внутреннему строению будет неплохо. На самом деле было что-то не то. Спасибо.
#ирония
Замок - это такая вещь, с помощью которой закрывают дом, авто или сейф от посторонних, но также с помощью которого злоумышленники вскрывают их. Похожее можно и про язык программирования сказать и про кухонный нож итд.
В первую очередь стек, это где складываются те данные, которые во время работы или вызовов функций должны быть временно сохранены. Соединить эту основную функцию стека в одном предложении с возможностью им манипулировать и назвать это как Обзор Stack Memory -не знаю, как то не подходит.
Второе, что мне не совсем понятно. Если уж вредоностный код в состоянии быть вызванным и может уже что-либо исполнять, то зачем вся эта катавасия с подменой адреса возврата?
Не соглашусь с вами но с вашим оппонетом. Можно на коленке но сделать надёжное устройство, и да - и на ардуине. А можно вроде подойти профессионально но всё равно сделать несовершенство. Но направо и налево вешать первым делом ярлыки- больше о вас рассказывает, чем о тех, на кого ярлыки вешается. Но это так - на заметку.
теперь о простом подходе. Ваш подход хороший. И идея, сделать все от и до - самому - тоже имеет свои плюсы.
Например, если бы я взялся за такое задание, то может быть взял за основу настоящую простую USB мышь плату и вывел все кнопки, и сенсоры позиционирования наружу. Те. заниматься софтом в принципе и не пришлось бы, тк. плата рабочая и может с компом соединяется. Особенно проще было бы, если мышь была бы чуточку старенькая или очень дорогая, но современная, но тогда цена возрастает, тк. там очень часто не инфраротовое определение позиции а именно физическое с помощью шарика и через кнопки...или четыре по осям, или 8 с доп. по диагоналям тоже.
ну вот — опять всё портите :) А такой масштаб для маркетинга имеет место быть! Не всем-же обязательно знать, что в их вычислительном процессе где-нибудь будет узкое место (bottleneck) — продаваться ведь может в общем на ура. А потом и на поиски этого «узкого места» можно и новые проекты поставить на ноги и доп. буджет освоить итд.
Такой радикальный подхот замечаю при внедрении новых систем, где необдуманно за основу берётся какая-нибудь функция, которую старая система вроде хуже делала, но при этом полностью или частично пренебрегаются и другие, немаловажные функции. И когда система запускается, начинается бесконечное допиливание системы. Потому что старая система не настолько была плохая, как её описывали, чтобы продать/купить новую.
Конкретный пример. У нас в новой архитектуре предусмотрели замену импорта данных на JSON, который раньше был на csv. Ведь это так модерно и круто. А то, что время импорта потом увеличилось в разы — это никого поначалу не волновало, ведь в Big Data все так делают. И не важно, что схема файла почти никогда не будет изменена. Потом приходит осознание, но после этого — многое уже просто так не вернёшь назад. Только за деньги и кучу времени.
Извиняюсь, но так инженеры не выражаются. Это первое. Второе. Я рассказываю своим студентам тоже разницу между CPU и GPU. Так вот. Если провести параллель, то CPU это пассажирский самолёт, а GPU — истребитель. Можно их сравнивать? Ну для детского воображения — да. Но не взаимоисключающе, а как для своих нужд хорошо отлаженные инструменты.
Не вдаюсь в детали, но сравнение неуместно. Потому что вроде идёт разговор о замещении одного другим, но список задач сводится к шейдерам. Но организация компьютера — это не треугольники и шейдеры. Это намного больше. И CPU занимается своим делом, а GPU и видеокарта — своим. И почему-то уверен, что так и останется ещё долгое время. Архитектура Von-Neumann уже не одно десятилетие пережило. Конечно оба можно в одно интегрировать, но сказать, что одно можно заменить другим — не является истинной. В таких вещах разделение задач только на пользу.
Ну все не могут быть такими умными как вы #ирония.
А серьёзно- ведь как раз таки и была дискуссия о интерполяции этих примеров. И именно 'проблема' с этим. Но об этом уже были пару комментариев выше.
Думаю, не только ко мне этот вопрос. Кстати интересный. Потому что в принципе описание процессов только из одной перспективы, как в вашем пиимере - отдела кадров - не самое оптимальное. Всевозможные темы имеют много чего общего, хотя и кое какие специфические вещи. И вот это общее - универсально настолько, что может почти без изменений кочевать из одной темы в другую. Пример с approval workflow ( процессы утверждения). В процессах, которые описывают проекты, есть цепочки для последующего разрешения или изменения статуса. Точно такие же процессы есть и в отделах кадров, в документо-обороте, в процессах при работе с внешними фирмами, экспертами итд. Похожие процессы протекают и в "кишках" любого микропроцессора, или например описание для Tasks, process или job у операционных симтем. Поэтому изобретать велосипед в каждой новой теме не стоит. Стоит видеть похожести. Это облегчает усилия сокращает время и проще для понимания или видоизменения потом. Думаю интернет полон всякими примерами. Есть ли у вас более конкретные вопросы? Потому что разговаривая о BPMN мы разговариваем меньше об этом, и больше о том, как работают или должны работать фирма, отдел, программа, какая-то функция или операция итд. Те. по большей частью о том, что нас окружает. И только маленькая часть - это нотации и описание. С удовольствием поделюсь, если будут вопросы.
И ещё один момент но его задам с осторожностью. Могу ошибиться , тк. уже более 20 лет не живу в среде русского языка, но мне кажется, что ваше выражение
...должно подниматься так, что if операторы - уже зло. Но они не одни есть зло, есть и другие злые вещи. А я вам скажу своё мнение, что сам оператор не есть зло. Злом может быть необдуманное его использование, которое сильно усложняет читаемость кода, а также возведение этого оператора в своего рода ранг табу и после - "борьба" против его использования. Так называемая охота на ведьм.
Дорогой автор, даже, если вам не нравятся другие мнения, всё равно стоит к ним прислушаться. Объясню почему.
В первом случае вы привели тривиальный случай, который 1:1 повторяет if оператор - те. вы заменили этот if оператор на две функции. А что делать, если внутри функции три и более if оператора? Заменять их на n! количество функций? У меня названий не хватит, если я вместо 4-х if(ов) 24 функции напишу, каждая из которых отдельную ситуацию воспроизведёт.
Это первое. Второе. Как бы вы не упрощали, вам всё равно выше по хирархии вызовов надо будет де-то принимать решение, какую из реализаций вызывать. Поэтому видение в if чего-то, чем надо пренебрегать - есть нежелание согласится с чем-то обычным. Таким-же как, если из одного города до другого надо доехать, то это потребует времени. Да, вместо велосипеда одно взять быструю машину но всё равно- какое-то время это потребуется. Очевидно.
В последнем примере опять-же тривиальный случай с типом string. А что делать, если функция возвращает другие типы данных? Например тот-же самый созданный файл, который не смог быть открытым, тк. места на плате нет или нет прав на создание. Что вы там за default value возьмёте?
Не понимаю. весь ассемблер набит функциями по переходу в зависимости от значения или состояния в аккумуляторе. Под это и создаётся оператор if, ну те. он потом с лёгкостью переводится в набор ассемблер команд.
в параметрах иногда true/false незначительно изменяют кое-какие например флаги. Т.е. убрав if, мне придётся дублировать полностью намного сложнее код.
Какое-то искуственное придумывание проблемы на пустом месте.
… правильный, но вызывает вопрос — а как быть и что делать, если этого не произойдёт? Ведь скорее всего ситуация не изменится.
Мы видим это в разных плоскостях. А жаль.
Я думаю под этим словом глючит не стоит ничего. Просто ярлык. Есть процессоры с их микрокодом, ассемблер. ОС, язык. Когда процессор глючил, например от Intel, то на софт-уровне эту проблему на какое-то время исправили.
Если кто-то говорит, что язык глючит, то единственное, что может в этом случае иметь место - компилятор языка сырой и требует доработки. Если язык сам по себе имеет логические или синтаксические ошибки, то он никогда не выйдет на большую сцену. Не знаю таких.
А кто вам лично мешает создавать ОС, браузеры или прикладные программы на неглючных языках писать, как вы выражается? Смешивается всё в кучу. Программирую на многих языках, вплоть до ассемблера. Ни один из них не могу назвать глючным. Один для одного типа задач, другой - для другого. Но фигни на них написать всегда можно. Но это как и с человеческим языком. Можно 50-ю словами всю жизнь обходиться и после каждого второго слова мат для связки слов использовать. А можно и так, что и 50 тысяч слов не будет хватать. Ваша абстракция с суперменом больше говорит о вас, чем о теме, которую вы затрагиваете. Зачем так сложно?