И хорошо что не знают… А то «каждый суслик агроном».
Поймите наконец — контроллер не синоним «слабенькому компьютеру». Перед ним всегда стоят сугубо утилитарные, как правило довольно простые задачи, главное требование к которым максимально быстрое реагирование на «внешние раздражители». Я дико не люблю термин «системы реального времени» ибо маркетологи его давно превратили в грязную тряпку, но если так оно проще воспринимается — ну пусть будет именно так.
Для таких решений слишком много накладных расходов, а попытки их решить даже с помощью простых решение типа FreeRTOS приводит к катастрофическому падению производительности (увеличению того самого времени реакции). К слову, не уверен что FreeRTOS поддерживает многопоточность/многоядерность.
А не мужикам дайте посмотреть каталог любого поставщика. Например вот этого. Пусть сами оценят каков процент многоядерных систем, и что является основным потоком, а что хипстерским ответвлением.
А вот массовое появление в контроллерной среде тех, кто считает контроллер слабым компьютером приводит к крайне интересным последствиям. Например замене контроллеров на ПЛИС'ы. Т.е. возврату к «жесткой логике»на современном этапе развития. А от вопросов в стиле «У нас же ARM на 200МГц с SD-картой и USB, так почему мы не можем воткнуть в него USB свисток для Wi-Fi?» я уже отбиваться замучался.
Виноват. Сильно польстил Microsoft'у. Думал с появлением PowerSheell и прочих улучшений в консоли этого мира длинный %errorlevel% давно заменен на что-нить короткое и понятное типа $?..
Уже написал, потом только осознал глупость написанного. И тем не менее, искуство написания BAT'ников или же CMD'шников практически утеряно. Мало кто этим занимается. Если по MSDOS это было важно и нужно, то под Windows… Если и нужно, то не так сильно. Окошки все же для тех, кто джойстиком балуется мышью водит, а не для тех кто клаву тискает скриптами автоматизацию наводит.
P.S.
Пожалуй стоит заменить, на тех кто помнит как пользоваться choice.com
Хоть заверифицируйся, натур испытания никто не отменял.
Уже хотел начать возмущаться, но дочитал до конца и полностью поддерживаю. Разве что уточню что объем натурных испытаний тоже тот еще вопрос. В зависимости от критичности изделия это может быть и выборочное тестирование из партии, и приемо-сдаточные, и периодические. При чем у изделия критика может проверяться приемо-сдаточными и периодикой, а менее критичные моменты выборочным тестированием.
Впрочем, на технических ресурсах, эти чисто менеджерские (в крайне хорошем смысле этого слова) заморочки не в чести. А зря.
В той сфере «продакшен» к слову тоже понимается несколько по другому. Для простейших это как правило выращивание в питательной среде (довольно старая технология), для растений микроклонирование — меристемное размножение (середина прошлого века), для животных… А тут все сложно. Законодательно сложно. Более мене пофиг Штатам. Но, блин, им всегда пофиг. И напалм, и ДДТ и инвазивные виды, заменяющие природные. Четкое ощущение того, что «после нас хоть потоп». И это уже неоднократно било по всему миру. Они главные поставщики всего генно-модифицированного. И соответственно наиболее продвинутые в части исследований. Но никто не может знать — не окажется ли это все очередной бомбой. Заметьте про тот же ДДТ — отложенное воздействие. Через много лет. И обнаружилось это уже тогда, когда инсектицид был в продакте. При чем не первый год (и даже не десяток лет).
Мое мнение на сегодня — простейших можно ставить на поток. Но не для вживления человеку или животным, а для тех мест, где используется их «продукция». Разложение органики, переработка пластмасс или что-то подобное. Даже тут работы непочатый край. Декоративные растения — ну пусть будет. Вроде как ничего особо страшного от них ждать не приходится. В принципе это и к высшим относится. Те же GloFish довольно давно обитают в аквариумах. Если будете смотреть — смотрите в картинках на google. В статье фотография исходной (природной) формы.
А вот для хозяйственного применения я бы повременил. Но тут Америка, которую мы в очередной раз перегоняем. Тут продовольственная безопасность (хороша безопасность когда семена за океаном закупаем, а выращенные из них у нас есть можно, но расти они не будут). Тут деньги. Потому, скорее всего, придется еще раз пройтись по граблям. В конце-концов как бы грубо это не звучало — человеков стало слишком много. Природа ищет способ сократить поголовье. Перестало получаться с внутривидовой агрессией, не получилось с со СПИДом и раком, так ГМО добьет.
А про лекции популяризаторов науки… Мои биологи мне сказали так: очень разные люди очень разные вещи очень по разному говорят. Не хочешь быть бараном, идущим за таким же бараном, но возомнившим себя вожаком — читай и изучай. Или не суди о темах, которых не знаешь. Сложно с ними не согласиться.
У вас же где-то, пусть даже на бумаге, эта спека есть?
Так, а вот с этого момента стоп. Если это было в спецификации, но не реализовалось в железе — вопрос как его принимали? И пофиг кто и что там проверял — компилятор, отк, натурные тесты… Но проблема в том, что судя по публикациям в спецификации такого и не было. И вообще фактически новый самолет был выпущен под видом модификации существующей модели. С крайне сокращенной программой испытаний.
Да, это та самая ошибка проектирования системы. Когда критически важные моменты проходят мимо ТЗ, спецификаций, приемки. И никакой компилятор это исправить не может. А если это есть — по по совести пофиг на компилятор. Хоть на бейсике пишите — лишь бы требованиям спецификации соответствовало.
Я про ошибки репликации и методы их устранения. Есть у клетки такие механизмы. Клетки могут тупо отторгать код донора. Если очень кратко и сжато, то например здесь (буквально первое, что попалось — наверняка есть и понятнее). Т.е. мало встроить, надо встроить так, чтоб реплицировалось. Для этого есть свои методы. Раз Вы интересуетесь — то видимо в курсе. На самом деле с расшифровкой геномов и пониманием процедуры кодирования проблема уже практически не стоит. Но мы на IT'шном ресуре. И приходится искать аналогию. Думаю, что ближайшей будет примерно такая — встроить код не поломав подпись. А для того, чтоб стало совсем понятно — встроить код в квайн не поломав подпись.
И уж если на то пошло, то давайте обозначим на понятном IT'шникам языке что представляет собой та самая технология CRISPR. Сможете предложить понятную аналогию? А я попробую — технология компьютерных вирусов времен MSDOS. Берем способный к размножению вирус. Вместо форматирования жесткого диска или проигрывания дурацкой музыки вставляем свой код, используя от вируса именно механизмы внедрения и размножения. Практически полный аналог гулявшей в свое время по BBS'кам Virus Creating Library — там тоже была возможность выбора полезной нагрузки или написания собственной. По сути примерно так работали «ванцинаторы» по д MSDOS. Охраняли файлы путем их вирусного заражения и сохранения контрольной суммы. И при заражении поднималась паника. Ровно так и с CRISPR. В носителе помимо полезной нагрузки остается кусок вирусного DNK. То что это хорошо не скажет ни один генетик. Вопрос лишь в том насколько это плохо. А вот тут мнения делятся. Впрочем в IT мире известны файлы, которые отказывались работать после вакцинации. Где гарантия, что подобный исход не постигнет модифицированный продукт? А где гарантия что оно не сработает на n-ой репликации?
Справедливости ради стоит сказать, что вроде как существуют технологии редактирования не оставляющие следов вирусного генома. Но, насколько мне известно, они пока тестируются и работают заметно хуже чем исходный CRISPR.
Опять же заметьте — это мы про редактирование. Вы же в статье пытаетесь убедить в том, что практически можно брать куски ДНК и производить себе на потребу дня бактерий или еще кого-то. Типа как программисты пишут код, генетики проектируют DNK и получают по ней образцы живых бионтов. Боюсь, пока до такого очень и очень далеко. Больше того, решению этой проблемы не поможет и полная расшифровка генома. Тут свои тараканы…
Впечатлит. Но при всех достижениях — это все же копирование. Сложное — безусловно. Но копирование. И даже не редактирование. Китайский IPhone по внешнему виду тоже был похож на оригинал. И даже копировал его «повадки». И даже лучше был — там две сим-карты и телевизор.
Я не биолог. Мне сложно судить о той области. Просто как хобби интересуюсь смежной наукой и однажды сцепился именно с биологами. Как раз с точки зрения программиста. С позиции геном — это как код программы. Почему бы не использовать «удачные» алгоритмы из сеседней программы в своей собственной? Ну или почему не поставить в условную Волгу, радиатор охлаждения от условного «Мерседеса» — он надежнее и прослужит дольше? По мере погружения в вопрос выяснилось — такая аналогия крайне упрощена. В первую очередь она не учитывает репликацию (т.е. по сути программа не просто программа — она квайн) и, самое главное, контроль целостности. Т.е. нельзя вот так запросто поменять код — при следующей репликации изменения обнаружат и удалят. В худшем случае вообще прервав цепочку репликаций. Почему и говорю, конечно крайне грубо говорю, про обезьян с часами. Прогресс идет. И сам факт появления методики класса CRISPR об этом говорит. И то, что успехи есть — это радует. Конечно, развивать дальше тоже надо.
Просто многолетний опыт редактирования генома методом селекции был понятен. Относительно понятен. Большую часть работы делала матушка-природа, а человек ее только подталкивал к нужным решениям. Она же занималась самоуничтожением явно ошибочных ветвей используя для этого генетически сформированные за миллионы лет эволюции механизмы в растениях. А вот опыты с пересадкой части генома даже не родственных растений… У меня сегодня вызывают некоторую оторопь. Ладно, репликация идет. Ладно защиту от ошибок при копировании подавили. Но чем грозит выпуск таких организмов в дикую природу? Борщевик Сосновского может показаться детской шалостью…
Потому и пишу — не время для победных реляций. Время для глубоких исследований до полного понимания. Но повторюсь — я не биолог и не генетик. Могу и ошибаться. И, если честно, хочу ошибаться.
Т.е. мы уже считаем возможным совершенно безболезненно редактировать квайны, которые через несколько перерождений производят другие квайны, которые в свою очередь через несколько перерождений производят несколько архив с исходным квайном? И это ближайшая аналогия самых простейших организмов.
По мне мы сейчас на уровне обезьян. Которые бьют одни часы об другие с мыслью посмотреть как оно устроено. Прогресс, безусловно, есть. И его безусловно не остановить, но время для таких восторженных статей еще явно не настало.
Или мое понимание проблематики не соответствует действительности?
Вопрос только в том откуда компилятор должен знать о том, что требуется проверять? И что будет критерием отказа датчика? И как действовать в такой ситуации? Не получится так, что описание критериев тестирования встанет более сложной задачей чем их реализация? Отменит ли прохождение теста натурные испытания (и если нет, то зачем тест)?
Мне кажется, если ответы на эти вопросы будут, то язык уже не будет таким уж принципиальным фактором. Обидно, что те области, которые казалось бы должны быть ужасно консервативны в плане контроля безопасности, вдруг демонстрируют такие откровенные даже не ошибки, а убийственные недоработки. Вот и думай, так ли хороша система в которой все ради денег.
Вот и получается, что есть целый список вопросов, на которые сознательно или нет, но забили при проектировании. Как результат неверные действия тех же пилотов. Им никто не сказал о неисправном датчике или некорректно работающей подсистеме. Как результат ее никто и не отключал, а фактически боролся с ней. И даже помолчим о том, что процедура отключения данной подсистемы совсем не тривиальна.
не потому, что датчик или MCAS чего-то там, а потому, что плохо обученные пилоты не смогли парировать совершенно восстановимый и некритичный отказ
А можно ссылку на Ваши источники? Я плохо знаю тему и вынужден верить тому, что пишут. Но пишут-то как раз обратное. Что MCAS работает только при ручном управлении, и именно она вместо неотключаемого помощника превратилась неотключаемого врага. Бороться с автоматикой в таком случае тяжело. Все равно что пытаться широким плечом несущийся камаз остановить…
Но вернувшись к теме. Это как раз ошибка проектирования. Не спас бы ситуацию тот же ошибочно спроектированный код, но написанный на Rust. Вот и думайте где безопасность, а где ее иллюзия.
А как хорошо издалека видно кто и что делал под DOS.
Вот если я напишу %errorlevel% многие ли без гугла поймут к чему бы это? Многие ли назовут хоть одно преимущество vc.com, кроме как размер? Многие ли помнят достоинства и недостатки emm.sys vs qemm.sys?
Вот поймал себя на мысли, что ведь сколько лет прошло, а до сих пор все помню. Эх, бытность Fido'шная с самостоятельной настройкой софта… А потом еще тоже самое но под Linux… И да, на деле инструментов для доступа к интернету под Dos хватает. Одних браузеров несколько штук могу припомнить. Там, правда, с русским у всех проблемы… Но там не менее. И почту читать. Порты с msdos, специфический софт для чтения почты по uucp, ftp, gopher (помнит ли его еще хоть кто-то?) клиенты… И горка сервисов типа ftp via E-Mail, http via EMail. А великое богатство NNTP? Оно ведь тоже вполне доступно было из DOS…
Это не говоря уже о таких программах как Adobe Acrobat Reader. Последняя, правда, не со всеми принтерами работала… Но работала.
Вот она моральная проблема. С одной стороны надо свой код показать, с другой именно то, что показать можно не очень показательно. Да и хвастовством отдает… Ладно, посмотрите драйвер и подсистема. Ну, и чуть более сложный пример и прочие драйвера рядом.
А потом скажите — много ли свободы остается для оптимизатора? И уж поверьте на слово — в контроллерах примерно так же. Рад бы показать, но все проекты коммерческие — и в открытую не лежат. Когда одна из базовых идей как раз минимизация кода (и тактов) оптимизатору остается разве что платформо-специфичные трюки проделывать. Он, собственно, именно этим и занят. На уровнях выше никакого. Не та область, где ему развернуться можно.
Как, кстати, вы к нему на С обратитесь?
Вдруг сейчас выяснится, что С тоже не подходит для системного программирования.
А вы читали то, что я выше писал? Я же четко и однозначно написал:
И да, язык С не транслирует это выше. Переполнение и переполнение. Ну что теперь…
И даже пояснил, почему это не важно от слова совсем. Разве нет?
Но раз пошли наезды на мои любимые инструменты, то могу за них постоять. Для начала «кто сам без греха пусть первым бросит камень». Что-то я навскидку не припомню языков, которые бы так умели. Опять же — причина выше обозначена. Во вторых, я не знаю реализовано ли это в Rust (не дошел), но беглый поиск приводит к этой статье. И если так, то при необходимости я легко сделаю это «как в Rust» банальной ассемблерной вставкой или даже статически линкумемой библиотечкой. В обоих случаях, кстати, может находиться и банальная заглушка ежели вдруг найдется архитектура такую функциональность не поддерживающая. А вот как будет выкручиваться на таких архитектурах Rust? Неужели переписывать ассемблерные команды математики?
Нужна ли эта функциональность в стандарте языка? Мое мнение — абсолютно не нужна. Во всяком случае в стандарте языка С точно нет.
Потому что себе я не доверяю, не доверяю тому, что буду поддерживать 100% внимательность всё время, что не напишу хрени с недосыпа, и тому подобные вещи...
Странно, мы исходим из одних и тех же предпосылок, но приходим к разным выводам. Мне кажется, что «семь раз отмерь, один отрежь» более правильный подход. Не надо писать «хрени с недосыпу». От слова совсем. Есть множество работ, даже у программиста, которые не требуют головного мозга. Достаточно спинного (читай инстинктов). Вот их с недосыпу и надо делать. Они всегда откладываются, ибо тупые и неинтересные, но когда мозг не работает — для них самое время.
Впрочем, поправьте если я ошибаюсь. Вы же больше прикладник? Или пришли в системщики из прикладников? Математические обоснования, необходимость писать во что бы то ни стало чтоб успеть к очередному дедлайну — это скорее оттуда. Я пришел из схемотехников. А там суетность всегда приводит к выпуску из устройства главной составляющей — волшебного дыма. Потому наш лозунг «Сейчас медленно спустимся с горы и, хм..., разберемся со всем стадом».
Наверное поэтому Вам важен "… мощный язык может позволить выразить требование этого контроля ...", а мне грамотно проектировать систему в целом, меньше писать и больше думать. Вообще лучший код это тот, которого нет.
Только не сочтите это за наезды или что-то такое. Мир большой. В нем место найдется любому подходу.
Потому что сравнивать раст разумнее с плюсами, ИМХО.
Вот именно поэтому меня и не покидает ощущение, что мы говорим об одном и том же, но приходим чуть ли не к диаметрально противоположным выводам.
Вы меня «валите» теми плюсовыми заморочками, которые меня или совсем не касаются, или касаются очень опосредовано. И по большому счету мне и возразить нечего — я просто с этим никогда не сталкивался.
Но я согласен с Вами. Если Rust и конкурент (с оговоркой, конечно, — в современном мире), то конкурент плюсам. Потому с ним можно поиграться, как с забавной игрушкой, но до применения в железе ему еще далеко. Впрочем, вполне себе предвидя Ваши возражения, все же напишу что и плюсов это тоже касается. С одно маленькой поправкой. Им уже далеко.
Конечно, все написанное исключительно мое субъективное мнение. Ни коим образом не претендующее на звание «единственно верного и идеологически выдержанного».
А почему он должен так сильно отличаться от C?
godbolt.org/z/am8Bwf
godbolt.org/z/wp6wpu
А если примеры посложнее, да с safe массивами? А еще замечательный пример — реализация кольцевых буферов, где переполнение чуть ли не основная фишка. Впрочем, я уже ответил выше.
Мы не первый раз встречаемся с Вами в комментарих. Может стоит попытаться расставить реперные точки? Давайте сначала.
Когда нацисты хватали коммунистов, я молчал: я не был коммунистом.
Когда они сажали социал-демократов, я молчал: я не был социал-демократом.
Когда они хватали членов профсоюза, я молчал: я не был членом профсоюза.
...
Так вот — пока Rust воевал с С++ и Go, я молчал: это не моя поляна.
Это поляна прикладников, они пусть с ней и разбираются. Меня вопрос заинтересовал исключительно после комментария Грега о том, что Rust вполне возможно появится как инструмент кодогенерации в ядре. Вот тут мне пришлось пошевелиться и посмотреть что это за «зверь неведомый», «с чем его едят» и «стоит ли его бояться»? Решать не мне, конечно, но… Пока я вижу только проблемы. Везде. От кросскомпиляции до форматов данных. Нет, это работает. Но диапазон сильно уже, чем минимально необходимый. Потому ждем. Слишком рано.
Теперь отдельно про кодегерацию и дизассемблерный листинг. Начнем с простого. Конечно, не -O0. Ну что Вы в самом деле. Базовая настройка всегда -Os. Но весь прикол в том, что включать, допустим, -O3 в подавляющем большинстве случаев приведет к замедлению, а не к ускорению. И как раз дамп это прекрасно показывает. Причины этого я напишу чуть ниже. Просто чтобы не мешать в одну кучу мух и котлет. Каждая строка моего C кода транслируется в одну-две (редко больше) ассемблерные инструкции. При чем в подавляющем большинстве случаев я знаю какие именно инструкции будут, и как повлияют настройки оптимизации на поведение компилятора. Больше того, я точно знаю что в подавляющем большинстве случаев никак не повлияют. Что бы я не поставил после -O. А в меньшинстве, как раз приходится бороться с «излишне умным» компилятором. Чаще всего путем #pragma GCC optimize («O0»)
Теперь про переполнения. Знаковые, беззнаковые — уже детали. Да, у процессора есть флаг, позволяющий данную ситуацию отловить. Т.е. если спуститься глубже, то можно это дело накрыть. И да, язык С не транслирует это выше. Переполнение и переполнение. Ну что теперь…
Казалось бы криминал-криминал. Но ведь нет. И знаете почему нет? А ровно потому, что мастер знает свой инструмент. Даже люди старой закалки, писавшие на ассемблере, практически никогда не проверяли флаг переполнения. Тому есть несколько причин. Первая — мастер, в отличие от ремесленника, не решает задачу, а проектирует систему. А в этом случае размерность типов данных выбирается такой, чтобы переполнений не возникало. Или они были строго контролируемы. Причина, вызывающая переполнение, в подавляющем большинстве случаев это недостаточная фильтрация входных данных. Так вот всегда бороться надо с причиной, а не со следствием. Вторая причина в том, что информация о случившимся переполнении на уровне процессора практически бесполезна. Хорошо, случилось переполнение. И как прикажете на него реагировать? Направлять программу по другому пути, где предусмотрены большие размеры? Падать с ошибкой? Или что? Вот потому-то и важно не садиться кодить сломя голову, а садиться и думать. О системе. О том как она будет работать и как будет себя вести в случае неадекватных входных данных. Опять же — скриптовым языкам это может быть и полезно, но всему что транслируется в машинный код информация о переполнении… Не думаю.
А вот теперь, сказав о необходимости проектирования системы и контроля входных параметров можно вернуться к дополнительным проверкам в Rust. Впрочем, я уже все сказал. Потому особо задерживаться здесь не будем. Контроль входных данных (как минимум на самом низком уровне) — однозначно ответственность автора. Только так, и никак иначе.
Теперь про дизассемблер оптимизированных плюсов. Тут я сразу отмажусь тем, что актуального состояния не знаю. Может быть. Но плюсы и более высокие языки в дизассемблере… Впрочем, Вы ж не ломаете собственный код. У Вас же есть отладочная информация. Что там может остаться непонятным? Для меня загадка. На рубеже 2000-2010 годов (эпоха shareware софта) я развлекался сломом и написанием кейгенов. Так со временем даже Delphi (не к ночи будь помянут) в дизасемблере становился понятным. А уж плюсы просто с листа читались. Но еще раз — актуальным состоянием дел я не владею. Потому верю на слово, и, если хотите, сочувствую. Мне бы без понимания того как именно работает написанный мной код было бы очень тяжело.
И напоследок. Скажите, а Вы осознанно ставите знак равенства между C и C++? Если это и родственники, то дальние. В лучшем случае двоюродные братья. По мне не очень разумно их сливать в один чан. Конечно, офисный пакет класса LibreOffice или САПР класса AutoCAD писать на С не будешь. Для этого есть плюсы. Но и у C есть своя ниша. Конечно, одну и ту же задачу можно решить разными инструментами. Но несколько негоже оперировать мечем, колоть дрова скальпелем или забивать гвозди микроскопом. Еще хуже жаловаться при этом на инструмент. Разве нет?
А теперь вернемся к началу статьи. В битве прикладных языков я занимаю позицию наблюдателя. А системная составляющая Rust вызывает у меня (и не только у меня) вполне обоснованные вопросы. И только.
И еще. Я старался максимально убрать любой сарказм и любые подколки. Если что осталось, прошу простить. Я не со злаю
— Перегрузки больше двадцатикратной могут убить.
— Могут. Но падение с высоты пяти километров не может не убить.
Я бы плюсанул, если бы мог. Хороший пример, и главное в месту. Вопрос только в том смогут ли это понять. А то «все это уже было в симпсонах» воспринимается, а вот «все это уже было у Лема, Хайнлайна и многих других» как-то не очень. Да и не только среди фантастической литературы, к слову.
Ну вот… Конечно. Только давайте все же не сравнивать эти два компилятора. Особенно по части обращения с данными. Ибо C творит с ними ровно то, что может процессор. Потому и не возражает против переполнений или чего-то похожего, и система кодогенерации у него крайне простая. А вот Rust напротив вносит некоторое количество проверок усложняя код. Да еще как мне тут рассказывают для разных случаев разные проверки. Мало того что в каждой из них потенциально проблемы, так еще возможность выбора «не той системы».
И еще момент — в силу простоты реализации компилятор С легко проверяется изучением дизассемблированоого текста. Можно ли так же на Rust'е? Понятен ли будет его ассемблерный код (особенно тому, кто ратует за него, ибо даже C сложно)? Сработает ли этот факт на повышение надежности? Мое мнение — однозначно нет.
Нет, общий вывод неоспорим. Конечно все именно так.
Однако любая струна рано или поздно лопнет. Работа под постоянной нагрузкой даром не проходит. А токсичные свинцовые белила одно время были весьма популярны в качестве косметического средства. Да и в состав красок они входили.
К чему я? Да к тому, что каждый технологический или научный виток отправляет на свалку истории то, что было сделано раньше. Беда в том, что супер безопасность Rust'а не защитит от уязвимостей класса той же spectre. Вот так раз — и главный козырь оказался побит.
Однако я не буду делать выводов. Еще раз — в целом я полностью согласен. Искусство — это писать грамотно и безопасно в современном понимании этих понятий. И, конечно, не от одних только UB это зависит.
Стоит ли это понимать, как роспись в собственном бессилии? Ведь компилятор тоже не с небес спустился. Его тоже кто-то написал. И кто-то проверил. Стоит ли так безоговорочно верить ему?
А единственный компилятор, который реально безопасно программировать учит — это компилятор с ассемблера. При чем учит так, как кошмарят по поводу плавания: бросили за борт — выплывешь, значит научишься, а нет… не судьба. Безопасно писать можно только своими руками пощупав все костыли, которые только возможны. Даже С такой свободы не дает (и ответственности не налагает).
Так что по сути ситуация как сейчас. Кто-то пишет драйвера, а кто-то Web-приложения. И между ними всякие браузеры гуляют. Вот и разделение. Для низа C и Assembler. Дай бог Rust'у туда влезть, но… Без боя не прокатит — это вам не прикладников теснить, тех которые на голом C по голому железу да без malloc() не могут. Для серединки — ну тот же Rust и какой-нить Go. Тут С++ тоже повоюет, но… Я бы сказал, есть шансы его подавить… Ну а в вебе скриптовые языки. Тут без вариантов.
Тут уж Вам решать какой слой элитарным обзывать. Я, кстати, про элитарность ничего не говорил. И даже мысли не было. Мне все равно кого элитой назовут. Просто чем ниже, тем большая подготовка нужна. Там возможностей больше, но и требования выше, и ответственность серьезнее. Я это искусством называл, а не элитой. Разные понятия. Особенно в современном мире.
Мне (не?) повезло — я всегда в самом низу. В лучшем случае (контроллер) весь проект мой, в худшем (BSP, драйвера, подсистемы) сверху гора прикладников, которых не волнует медленная периферия, необходимость синхронизации данных или что-то еще. Им нужны данные в любое время или как минимум четкий сигнал об их отсутствии. Ну и не занимать процессор. А то до тактов их скриптовые языки жадные.
А безопасность Rust… Не получилось бы с ней как с небезизвестной Spectre. Сначала все прикрыли, а потом ужаснулись провалу в производительности и призадумались — а справедлива ли цена? И это тот еще вопрос. Нет по нему консенсуса.
И хорошо что не знают… А то «каждый суслик агроном».
Поймите наконец — контроллер не синоним «слабенькому компьютеру». Перед ним всегда стоят сугубо утилитарные, как правило довольно простые задачи, главное требование к которым максимально быстрое реагирование на «внешние раздражители». Я дико не люблю термин «системы реального времени» ибо маркетологи его давно превратили в грязную тряпку, но если так оно проще воспринимается — ну пусть будет именно так.
Для таких решений слишком много накладных расходов, а попытки их решить даже с помощью простых решение типа FreeRTOS приводит к катастрофическому падению производительности (увеличению того самого времени реакции). К слову, не уверен что FreeRTOS поддерживает многопоточность/многоядерность.
А не мужикам дайте посмотреть каталог любого поставщика. Например вот этого. Пусть сами оценят каков процент многоядерных систем, и что является основным потоком, а что хипстерским ответвлением.
А вот массовое появление в контроллерной среде тех, кто считает контроллер слабым компьютером приводит к крайне интересным последствиям. Например замене контроллеров на ПЛИС'ы. Т.е. возврату к «жесткой логике»на современном этапе развития. А от вопросов в стиле «У нас же ARM на 200МГц с SD-картой и USB, так почему мы не можем воткнуть в него USB свисток для Wi-Fi?» я уже отбиваться замучался.
Так что да. Мужики-то не знают…
Уже написал, потом только осознал глупость написанного. И тем не менее, искуство написания BAT'ников или же CMD'шников практически утеряно. Мало кто этим занимается. Если по MSDOS это было важно и нужно, то под Windows… Если и нужно, то не так сильно. Окошки все же для тех, кто
джойстиком балуетсямышью водит, а не для тех ктоклаву тискаетскриптами автоматизацию наводит.P.S.
Пожалуй стоит заменить, на тех кто помнит как пользоваться choice.com
Уже хотел начать возмущаться, но дочитал до конца и полностью поддерживаю. Разве что уточню что объем натурных испытаний тоже тот еще вопрос. В зависимости от критичности изделия это может быть и выборочное тестирование из партии, и приемо-сдаточные, и периодические. При чем у изделия критика может проверяться приемо-сдаточными и периодикой, а менее критичные моменты выборочным тестированием.
Впрочем, на технических ресурсах, эти чисто менеджерские (в крайне хорошем смысле этого слова) заморочки не в чести. А зря.
В той сфере «продакшен» к слову тоже понимается несколько по другому. Для простейших это как правило выращивание в питательной среде (довольно старая технология), для растений микроклонирование — меристемное размножение (середина прошлого века), для животных… А тут все сложно. Законодательно сложно. Более мене пофиг Штатам. Но, блин, им всегда пофиг. И напалм, и ДДТ и инвазивные виды, заменяющие природные. Четкое ощущение того, что «после нас хоть потоп». И это уже неоднократно било по всему миру. Они главные поставщики всего генно-модифицированного. И соответственно наиболее продвинутые в части исследований. Но никто не может знать — не окажется ли это все очередной бомбой. Заметьте про тот же ДДТ — отложенное воздействие. Через много лет. И обнаружилось это уже тогда, когда инсектицид был в продакте. При чем не первый год (и даже не десяток лет).
Мое мнение на сегодня — простейших можно ставить на поток. Но не для вживления человеку или животным, а для тех мест, где используется их «продукция». Разложение органики, переработка пластмасс или что-то подобное. Даже тут работы непочатый край. Декоративные растения — ну пусть будет. Вроде как ничего особо страшного от них ждать не приходится. В принципе это и к высшим относится. Те же GloFish довольно давно обитают в аквариумах. Если будете смотреть — смотрите в картинках на google. В статье фотография исходной (природной) формы.
А вот для хозяйственного применения я бы повременил. Но тут Америка, которую мы в очередной раз перегоняем. Тут продовольственная безопасность (хороша безопасность когда семена за океаном закупаем, а выращенные из них у нас есть можно, но расти они не будут). Тут деньги. Потому, скорее всего, придется еще раз пройтись по граблям. В конце-концов как бы грубо это не звучало — человеков стало слишком много. Природа ищет способ сократить поголовье. Перестало получаться с внутривидовой агрессией, не получилось с со СПИДом и раком, так ГМО добьет.
А про лекции популяризаторов науки… Мои биологи мне сказали так: очень разные люди очень разные вещи очень по разному говорят. Не хочешь быть бараном, идущим за таким же бараном, но возомнившим себя вожаком — читай и изучай. Или не суди о темах, которых не знаешь. Сложно с ними не согласиться.
Так, а вот с этого момента стоп. Если это было в спецификации, но не реализовалось в железе — вопрос как его принимали? И пофиг кто и что там проверял — компилятор, отк, натурные тесты… Но проблема в том, что судя по публикациям в спецификации такого и не было. И вообще фактически новый самолет был выпущен под видом модификации существующей модели. С крайне сокращенной программой испытаний.
Да, это та самая ошибка проектирования системы. Когда критически важные моменты проходят мимо ТЗ, спецификаций, приемки. И никакой компилятор это исправить не может. А если это есть — по по совести пофиг на компилятор. Хоть на бейсике пишите — лишь бы требованиям спецификации соответствовало.
Разве не так?
И уж если на то пошло, то давайте обозначим на понятном IT'шникам языке что представляет собой та самая технология CRISPR. Сможете предложить понятную аналогию? А я попробую — технология компьютерных вирусов времен MSDOS. Берем способный к размножению вирус. Вместо форматирования жесткого диска или проигрывания дурацкой музыки вставляем свой код, используя от вируса именно механизмы внедрения и размножения. Практически полный аналог гулявшей в свое время по BBS'кам Virus Creating Library — там тоже была возможность выбора полезной нагрузки или написания собственной. По сути примерно так работали «ванцинаторы» по д MSDOS. Охраняли файлы путем их вирусного заражения и сохранения контрольной суммы. И при заражении поднималась паника. Ровно так и с CRISPR. В носителе помимо полезной нагрузки остается кусок вирусного DNK. То что это хорошо не скажет ни один генетик. Вопрос лишь в том насколько это плохо. А вот тут мнения делятся. Впрочем в IT мире известны файлы, которые отказывались работать после вакцинации. Где гарантия, что подобный исход не постигнет модифицированный продукт? А где гарантия что оно не сработает на n-ой репликации?
Справедливости ради стоит сказать, что вроде как существуют технологии редактирования не оставляющие следов вирусного генома. Но, насколько мне известно, они пока тестируются и работают заметно хуже чем исходный CRISPR.
Опять же заметьте — это мы про редактирование. Вы же в статье пытаетесь убедить в том, что практически можно брать куски ДНК и производить себе на потребу дня бактерий или еще кого-то. Типа как программисты пишут код, генетики проектируют DNK и получают по ней образцы живых бионтов. Боюсь, пока до такого очень и очень далеко. Больше того, решению этой проблемы не поможет и полная расшифровка генома. Тут свои тараканы…
Я не биолог. Мне сложно судить о той области. Просто как хобби интересуюсь смежной наукой и однажды сцепился именно с биологами. Как раз с точки зрения программиста. С позиции геном — это как код программы. Почему бы не использовать «удачные» алгоритмы из сеседней программы в своей собственной? Ну или почему не поставить в условную Волгу, радиатор охлаждения от условного «Мерседеса» — он надежнее и прослужит дольше? По мере погружения в вопрос выяснилось — такая аналогия крайне упрощена. В первую очередь она не учитывает репликацию (т.е. по сути программа не просто программа — она квайн) и, самое главное, контроль целостности. Т.е. нельзя вот так запросто поменять код — при следующей репликации изменения обнаружат и удалят. В худшем случае вообще прервав цепочку репликаций. Почему и говорю, конечно крайне грубо говорю, про обезьян с часами. Прогресс идет. И сам факт появления методики класса CRISPR об этом говорит. И то, что успехи есть — это радует. Конечно, развивать дальше тоже надо.
Просто многолетний опыт редактирования генома методом селекции был понятен. Относительно понятен. Большую часть работы делала матушка-природа, а человек ее только подталкивал к нужным решениям. Она же занималась самоуничтожением явно ошибочных ветвей используя для этого генетически сформированные за миллионы лет эволюции механизмы в растениях. А вот опыты с пересадкой части генома даже не родственных растений… У меня сегодня вызывают некоторую оторопь. Ладно, репликация идет. Ладно защиту от ошибок при копировании подавили. Но чем грозит выпуск таких организмов в дикую природу? Борщевик Сосновского может показаться детской шалостью…
Потому и пишу — не время для победных реляций. Время для глубоких исследований до полного понимания. Но повторюсь — я не биолог и не генетик. Могу и ошибаться. И, если честно, хочу ошибаться.
По мне мы сейчас на уровне обезьян. Которые бьют одни часы об другие с мыслью посмотреть как оно устроено. Прогресс, безусловно, есть. И его безусловно не остановить, но время для таких восторженных статей еще явно не настало.
Или мое понимание проблематики не соответствует действительности?
Мне кажется, если ответы на эти вопросы будут, то язык уже не будет таким уж принципиальным фактором. Обидно, что те области, которые казалось бы должны быть ужасно консервативны в плане контроля безопасности, вдруг демонстрируют такие откровенные даже не ошибки, а убийственные недоработки. Вот и думай, так ли хороша система в которой все ради денег.
Вот и получается, что есть целый список вопросов, на которые сознательно или нет, но забили при проектировании. Как результат неверные действия тех же пилотов. Им никто не сказал о неисправном датчике или некорректно работающей подсистеме. Как результат ее никто и не отключал, а фактически боролся с ней. И даже помолчим о том, что процедура отключения данной подсистемы совсем не тривиальна.
Хм. Программы, пишущие программы. Роботы, проектирующие и изготавливающие других роботов.
Я прозевал новый виток эволюции, на котором люди не нужны?
А можно ссылку на Ваши источники? Я плохо знаю тему и вынужден верить тому, что пишут. Но пишут-то как раз обратное. Что MCAS работает только при ручном управлении, и именно она вместо неотключаемого помощника превратилась неотключаемого врага. Бороться с автоматикой в таком случае тяжело. Все равно что пытаться широким плечом несущийся камаз остановить…
Но вернувшись к теме. Это как раз ошибка проектирования. Не спас бы ситуацию тот же ошибочно спроектированный код, но написанный на Rust. Вот и думайте где безопасность, а где ее иллюзия.
Вот если я напишу %errorlevel% многие ли без гугла поймут к чему бы это? Многие ли назовут хоть одно преимущество vc.com, кроме как размер? Многие ли помнят достоинства и недостатки emm.sys vs qemm.sys?
Вот поймал себя на мысли, что ведь сколько лет прошло, а до сих пор все помню. Эх, бытность Fido'шная с самостоятельной настройкой софта… А потом еще тоже самое но под Linux… И да, на деле инструментов для доступа к интернету под Dos хватает. Одних браузеров несколько штук могу припомнить. Там, правда, с русским у всех проблемы… Но там не менее. И почту читать. Порты с msdos, специфический софт для чтения почты по uucp, ftp, gopher (помнит ли его еще хоть кто-то?) клиенты… И горка сервисов типа ftp via E-Mail, http via EMail. А великое богатство NNTP? Оно ведь тоже вполне доступно было из DOS…
Это не говоря уже о таких программах как Adobe Acrobat Reader. Последняя, правда, не со всеми принтерами работала… Но работала.
Вот она моральная проблема. С одной стороны надо свой код показать, с другой именно то, что показать можно не очень показательно. Да и хвастовством отдает… Ладно, посмотрите драйвер и подсистема. Ну, и чуть более сложный пример и прочие драйвера рядом.
А потом скажите — много ли свободы остается для оптимизатора? И уж поверьте на слово — в контроллерах примерно так же. Рад бы показать, но все проекты коммерческие — и в открытую не лежат. Когда одна из базовых идей как раз минимизация кода (и тактов) оптимизатору остается разве что платформо-специфичные трюки проделывать. Он, собственно, именно этим и занят. На уровнях выше никакого. Не та область, где ему развернуться можно.
А вы читали то, что я выше писал? Я же четко и однозначно написал:
И даже пояснил, почему это не важно от слова совсем. Разве нет?
Но раз пошли наезды на мои любимые инструменты, то могу за них постоять. Для начала «кто сам без греха пусть первым бросит камень». Что-то я навскидку не припомню языков, которые бы так умели. Опять же — причина выше обозначена. Во вторых, я не знаю реализовано ли это в Rust (не дошел), но беглый поиск приводит к этой статье. И если так, то при необходимости я легко сделаю это «как в Rust» банальной ассемблерной вставкой или даже статически линкумемой библиотечкой. В обоих случаях, кстати, может находиться и банальная заглушка ежели вдруг найдется архитектура такую функциональность не поддерживающая. А вот как будет выкручиваться на таких архитектурах Rust? Неужели переписывать ассемблерные команды математики?
Нужна ли эта функциональность в стандарте языка? Мое мнение — абсолютно не нужна. Во всяком случае в стандарте языка С точно нет.
Странно, мы исходим из одних и тех же предпосылок, но приходим к разным выводам. Мне кажется, что «семь раз отмерь, один отрежь» более правильный подход. Не надо писать «хрени с недосыпу». От слова совсем. Есть множество работ, даже у программиста, которые не требуют головного мозга. Достаточно спинного (читай инстинктов). Вот их с недосыпу и надо делать. Они всегда откладываются, ибо тупые и неинтересные, но когда мозг не работает — для них самое время.
Впрочем, поправьте если я ошибаюсь. Вы же больше прикладник? Или пришли в системщики из прикладников? Математические обоснования, необходимость писать во что бы то ни стало чтоб успеть к очередному дедлайну — это скорее оттуда. Я пришел из схемотехников. А там суетность всегда приводит к выпуску из устройства главной составляющей — волшебного дыма. Потому наш лозунг «Сейчас медленно спустимся с горы и, хм..., разберемся со всем стадом».
Наверное поэтому Вам важен "… мощный язык может позволить выразить требование этого контроля ...", а мне грамотно проектировать систему в целом, меньше писать и больше думать. Вообще лучший код это тот, которого нет.
Только не сочтите это за наезды или что-то такое. Мир большой. В нем место найдется любому подходу.
Вот именно поэтому меня и не покидает ощущение, что мы говорим об одном и том же, но приходим чуть ли не к диаметрально противоположным выводам.
Вы меня «валите» теми плюсовыми заморочками, которые меня или совсем не касаются, или касаются очень опосредовано. И по большому счету мне и возразить нечего — я просто с этим никогда не сталкивался.
Но я согласен с Вами. Если Rust и конкурент (с оговоркой, конечно, — в современном мире), то конкурент плюсам. Потому с ним можно поиграться, как с забавной игрушкой, но до применения в железе ему еще далеко. Впрочем, вполне себе предвидя Ваши возражения, все же напишу что и плюсов это тоже касается. С одно маленькой поправкой. Им уже далеко.
Конечно, все написанное исключительно мое субъективное мнение. Ни коим образом не претендующее на звание «единственно верного и идеологически выдержанного».
А если примеры посложнее, да с safe массивами? А еще замечательный пример — реализация кольцевых буферов, где переполнение чуть ли не основная фишка. Впрочем, я уже ответил выше.
Так вот — пока Rust воевал с С++ и Go, я молчал: это не моя поляна.
Это поляна прикладников, они пусть с ней и разбираются. Меня вопрос заинтересовал исключительно после комментария Грега о том, что Rust вполне возможно появится как инструмент кодогенерации в ядре. Вот тут мне пришлось пошевелиться и посмотреть что это за «зверь неведомый», «с чем его едят» и «стоит ли его бояться»? Решать не мне, конечно, но… Пока я вижу только проблемы. Везде. От кросскомпиляции до форматов данных. Нет, это работает. Но диапазон сильно уже, чем минимально необходимый. Потому ждем. Слишком рано.
Теперь отдельно про кодегерацию и дизассемблерный листинг. Начнем с простого. Конечно, не -O0. Ну что Вы в самом деле. Базовая настройка всегда -Os. Но весь прикол в том, что включать, допустим, -O3 в подавляющем большинстве случаев приведет к замедлению, а не к ускорению. И как раз дамп это прекрасно показывает. Причины этого я напишу чуть ниже. Просто чтобы не мешать в одну кучу мух и котлет. Каждая строка моего C кода транслируется в одну-две (редко больше) ассемблерные инструкции. При чем в подавляющем большинстве случаев я знаю какие именно инструкции будут, и как повлияют настройки оптимизации на поведение компилятора. Больше того, я точно знаю что в подавляющем большинстве случаев никак не повлияют. Что бы я не поставил после -O. А в меньшинстве, как раз приходится бороться с «излишне умным» компилятором. Чаще всего путем #pragma GCC optimize («O0»)
Теперь про переполнения. Знаковые, беззнаковые — уже детали. Да, у процессора есть флаг, позволяющий данную ситуацию отловить. Т.е. если спуститься глубже, то можно это дело накрыть. И да, язык С не транслирует это выше. Переполнение и переполнение. Ну что теперь…
Казалось бы криминал-криминал. Но ведь нет. И знаете почему нет? А ровно потому, что мастер знает свой инструмент. Даже люди старой закалки, писавшие на ассемблере, практически никогда не проверяли флаг переполнения. Тому есть несколько причин. Первая — мастер, в отличие от ремесленника, не решает задачу, а проектирует систему. А в этом случае размерность типов данных выбирается такой, чтобы переполнений не возникало. Или они были строго контролируемы. Причина, вызывающая переполнение, в подавляющем большинстве случаев это недостаточная фильтрация входных данных. Так вот всегда бороться надо с причиной, а не со следствием. Вторая причина в том, что информация о случившимся переполнении на уровне процессора практически бесполезна. Хорошо, случилось переполнение. И как прикажете на него реагировать? Направлять программу по другому пути, где предусмотрены большие размеры? Падать с ошибкой? Или что? Вот потому-то и важно не садиться кодить сломя голову, а садиться и думать. О системе. О том как она будет работать и как будет себя вести в случае неадекватных входных данных. Опять же — скриптовым языкам это может быть и полезно, но всему что транслируется в машинный код информация о переполнении… Не думаю.
А вот теперь, сказав о необходимости проектирования системы и контроля входных параметров можно вернуться к дополнительным проверкам в Rust. Впрочем, я уже все сказал. Потому особо задерживаться здесь не будем. Контроль входных данных (как минимум на самом низком уровне) — однозначно ответственность автора. Только так, и никак иначе.
Теперь про дизассемблер оптимизированных плюсов. Тут я сразу отмажусь тем, что актуального состояния не знаю. Может быть. Но плюсы и более высокие языки в дизассемблере… Впрочем, Вы ж не ломаете собственный код. У Вас же есть отладочная информация. Что там может остаться непонятным? Для меня загадка. На рубеже 2000-2010 годов (эпоха shareware софта) я развлекался сломом и написанием кейгенов. Так со временем даже Delphi (не к ночи будь помянут) в дизасемблере становился понятным. А уж плюсы просто с листа читались. Но еще раз — актуальным состоянием дел я не владею. Потому верю на слово, и, если хотите, сочувствую. Мне бы без понимания того как именно работает написанный мной код было бы очень тяжело.
И напоследок. Скажите, а Вы осознанно ставите знак равенства между C и C++? Если это и родственники, то дальние. В лучшем случае двоюродные братья. По мне не очень разумно их сливать в один чан. Конечно, офисный пакет класса LibreOffice или САПР класса AutoCAD писать на С не будешь. Для этого есть плюсы. Но и у C есть своя ниша. Конечно, одну и ту же задачу можно решить разными инструментами. Но несколько негоже оперировать мечем, колоть дрова скальпелем или забивать гвозди микроскопом. Еще хуже жаловаться при этом на инструмент. Разве нет?
А теперь вернемся к началу статьи. В битве прикладных языков я занимаю позицию наблюдателя. А системная составляющая Rust вызывает у меня (и не только у меня) вполне обоснованные вопросы. И только.
И еще. Я старался максимально убрать любой сарказм и любые подколки. Если что осталось, прошу простить. Я не со злаю
Я бы плюсанул, если бы мог. Хороший пример, и главное в месту. Вопрос только в том смогут ли это понять. А то «все это уже было в симпсонах» воспринимается, а вот «все это уже было у Лема, Хайнлайна и многих других» как-то не очень. Да и не только среди фантастической литературы, к слову.
И еще момент — в силу простоты реализации компилятор С легко проверяется изучением дизассемблированоого текста. Можно ли так же на Rust'е? Понятен ли будет его ассемблерный код (особенно тому, кто ратует за него, ибо даже C сложно)? Сработает ли этот факт на повышение надежности? Мое мнение — однозначно нет.
Нет, общий вывод неоспорим. Конечно все именно так.
Однако любая струна рано или поздно лопнет. Работа под постоянной нагрузкой даром не проходит. А токсичные свинцовые белила одно время были весьма популярны в качестве косметического средства. Да и в состав красок они входили.
К чему я? Да к тому, что каждый технологический или научный виток отправляет на свалку истории то, что было сделано раньше. Беда в том, что супер безопасность Rust'а не защитит от уязвимостей класса той же spectre. Вот так раз — и главный козырь оказался побит.
Однако я не буду делать выводов. Еще раз — в целом я полностью согласен. Искусство — это писать грамотно и безопасно в современном понимании этих понятий. И, конечно, не от одних только UB это зависит.
А единственный компилятор, который реально безопасно программировать учит — это компилятор с ассемблера. При чем учит так, как кошмарят по поводу плавания: бросили за борт — выплывешь, значит научишься, а нет… не судьба. Безопасно писать можно только своими руками пощупав все костыли, которые только возможны. Даже С такой свободы не дает (и ответственности не налагает).
Так что по сути ситуация как сейчас. Кто-то пишет драйвера, а кто-то Web-приложения. И между ними всякие браузеры гуляют. Вот и разделение. Для низа C и Assembler. Дай бог Rust'у туда влезть, но… Без боя не прокатит — это вам не прикладников теснить, тех которые на голом C по голому железу да без malloc() не могут. Для серединки — ну тот же Rust и какой-нить Go. Тут С++ тоже повоюет, но… Я бы сказал, есть шансы его подавить… Ну а в вебе скриптовые языки. Тут без вариантов.
Тут уж Вам решать какой слой элитарным обзывать. Я, кстати, про элитарность ничего не говорил. И даже мысли не было. Мне все равно кого элитой назовут. Просто чем ниже, тем большая подготовка нужна. Там возможностей больше, но и требования выше, и ответственность серьезнее. Я это искусством называл, а не элитой. Разные понятия. Особенно в современном мире.
Мне (не?) повезло — я всегда в самом низу. В лучшем случае (контроллер) весь проект мой, в худшем (BSP, драйвера, подсистемы) сверху гора прикладников, которых не волнует медленная периферия, необходимость синхронизации данных или что-то еще. Им нужны данные в любое время или как минимум четкий сигнал об их отсутствии. Ну и не занимать процессор. А то до тактов их скриптовые языки жадные.
А безопасность Rust… Не получилось бы с ней как с небезизвестной Spectre. Сначала все прикрыли, а потом ужаснулись провалу в производительности и призадумались — а справедлива ли цена? И это тот еще вопрос. Нет по нему консенсуса.