Почему же, делайте, и все будет, никакой уличной магии там нет, инженерия вполне обычная. Понятно, что сразу замахиваться на высокочастотную симуляцию не смысла, но что-то небольшое сделать самому — вполне можно, а если с сообществом поделитесь — будет отлично совсем.
Так я и не спорю с этим, в реалиях бизнеса все так и есть. Проблема водопада именно в том, что он несовместим с качанием требований вслед за линией партии, но это не делает саму методологию плохой, а лишь неподходящей к этим реалиям. Т.е. если цель — решить задачу бизнеса, то решать ее надо как получается, и не жаловаться на тормоза и неоптимальность решения. А хочешь оптимально — доставай строгие требования, математику, теорию систем, инженерию, все то, что мы как человечество наработали для решения проблем, влезающих в головы архитекторов.
Мы с вами находимся на одной стороне спора, мне кажется. Я говорил про вот это:
Провода — вроде бы все одни, но нет — через один зарядка не идёт, через другой не идёт быстрая зарядка, третий не предназначен для Thuderbolt, четвёртый не работает с v2. А usb-c наушники — вот уж подлиное безумие! Все с проблемами. Телефоны работают с ними всяк по своему. И снова уйма несогласованных стандартов.
Даже с учетом того, что физически разъем выглядит одинаково, его по причинам вполне прозаическим не делают совместимым со всеми режимами, альтернативными или нет, и кабелей таких, по которым все вообще режимы работали бы — нет, и не надо. О чем я и написал, а ваших вопросов теперь понять не могу, т.к. это не я хочу один кабель на все случаи жизни.
Не перегибаю, аналоговое аудио по активным кабелям не работает на том Belkin, я проверял. Работу VirtualLink не проверял пока, но надеюсь, что вывезет без отдельных кабелей.
Опять же, никто не мешает USB IF послезавтра выпустить еще десяток альтернативных режимов для которых понадобятся свои кабеля, и задача сведется к предыдущей.
Работал и так, и так, и справляться приходилось и с водопадом, и с эджайлом.
Если у вас задача не влезает по сложности в дизайн — это показатель того, что решать ее рано. Ах, надо уже вчера? Ну тогда никто не гарантирует никакого качества, кроме того, что получится. Именно так получается нынешнее ПО, нынешние процессоры и все остальное. Нужно лучше — планируйте, контролируйте, используйте подходящие инструменты, контролируйте, хорошо платите, контролируйте, и не забывайте контролировать, это обязательно.
Пока это все не станет выгодно (т.е. ничем другим от конкурентов отличиться станет невозможно, кроме размера и\или скорости кода), для масс это не будет сделано никогда, потому что это адски дорого, адски долго, а на выходе получаются только примитивные вещи, влезающие в дизайн по ТЗ.
Именно в этом и разница между инженерной задачей и задачей получить на выходе продукт, который кому-то нужен. И именно поэтому софт для спутника или марсохода пишется по спеке и исключительно по ней, а писать так приложения для бизнеса, который сам не знает, чего хочет — выбросить сотню миллионов на ветер, и остаться позади конкурентов. Разные цели — разные методы, и я не ругаю ни тот, ни другой, просто отвечаю на вопрос «почему результат вот такой» — он вот таким получается, получать его иным — дорого.
Истинно так, выпрямлять — невыгодно, т.е. делаться будет либо энтузиастами, либо только тогда, когда ничего другого уже не поможет, и останется только выпрямлять. Думаю, мы вполне успеем дожить до этого момента, если никаких существенных прорывов в скорости вычислений и объемах памяти не произойдет в ближайшие лет 30.
Потому что из песка, скотча и тряпок ее делать дешевле в соответствии с теми процессами, которые идут внутри компании, эту систему производящую.
Чтобы бить задачи на подзадачи, нужно ясное видение «что именно строим», и план детальный к нему. По нынешней же моде это все называется жутким словом «водопад» и преподносится дорогими консультантами как жуткое болото, страшный суд, ад и погибель (о том, что так делается любой инженерный проект от моста через реку до ракеты, консультанты умалчивают почти всегда). Теперь у нас в моде эджайл, скрам, канбан и прочее все, призванное ПО не разрабатывать, а выращивать, лепя MVP из песка, тряпок и скотча, чтобы релизить быстрее, потому что иначе деньги кончатся, а инвесторы не дадут новые.
Виноваты умолчания.
Никто не захотел думать (не знал, не стал заморачиваться, не влезал в строки, не влезал в бюджет, не влезал в целевую производительность, причины точные не знает никто), что процессор можно атаковать с этой стороны. Почему раньше никто не переживал по поводу того, что kernel.dll отображается по фиксированному адресу, а теперь это большая проблема? Почему никто не пытался предотвращать исполнения страниц памяти с данными, а теперь все стараются всеми силами? Почему аппаратура начала вести теневые стеки, подписывать указатели и тегировать динамическую память, а раньше об этом никто не думал?
Все потому, что программирование — оно в основном про то, как выполнить задачу бизнеса при определенном наборе входных данных и выдать относительно приличный результат за относительно же приличное время. Написание программы, работа которой возможна при любых входных параметрах, противостоящей утечкам данных из любых общих ресурсов, тайминг-атакам и всему тому, что появилось за 50 лет противостояния брони и снаряда — это совсем другая задача за совсем другие деньги.
Согласен с автором, но причин разочаровываться не вижу. Человечество развивает ИТ таким же образом, как и все остальное, в полном соответствии со своей природой. Программы пишутся так же, как строятся города: кем попало, без плана и на руинах от предыдущих попыток. Сложность современных вычислительных систем уже вплотную подбирается (если уже не превысила) порог их понимания человеческим мозгом, и потому единственный путь вперед — повторять за эволюцией, нагромождая слои на слои, и сравнивая результаты.
Автору посоветую пойти и попробовать разобраться досконально хотя бы с современными архитектурами, т.е. как оно там все работает «на самом деле», начиная прямо с собирания сумматора из подручных материалов (как у Петцольда в известной книге), написания процессора простейшего на верилоге и так вверх до ЖаваСкрипта со всеми остановками. Где-то на реализации первых сложных команд в микрокоде придет понимание того, что писать все так, чтобы летало, при этом было доступно вчерашним школьникам, масштабировалось, обновлялось, свистело и пердело — просто настолько умопомрачительно дорого по всем параметрам, что позволить себе это могут либо огромные корпорации, либо гениальные энтузиасты (вроде Беллара). Все остальные берут то, что уже есть, и добавляют к нему то, чего еще нет, но хотелось бы иметь, либо комбинируют то, что уже есть, нужным им способом. Да, медленно, да 10 слоев, да эмуляция виртуализации эмуляции, да, никто понять не может толком уже давно, но результат — вот он, решения в массы, деньги в кассы.
Потому что унификация должна проводиться железной рукой и контролироваться на каждом этапе до состояния «не будут брать — отключим газ», а такое возможно только там, где цена ошибки очень высока — у ядерщиков, военных и авиаторов. И там не рынок, а олигополия, и разработка унифицированных продуктов занимает там годы и стоит миллионы.
Рынку же нафиг не нужна унификация, наоборот каждому игроку нужны свои, ни с чем не совместимые и запатентованные разъемы, кабели, периферия, и собственные стандарты вообще на все, иначе прибыль от продажи всех сопутствующих товаров падает.
Кроме того, если вам сделать один кабель USB-C, по которому можно будет передавать и Thunderbolt, и USB 3.1, и питание, и аудио цифровое и аналоговое, и черта лысого оцифрованного — такой кабель будет толщиной в палец и стоить 50 долларов за метр, а покупать его никто не будет, потому что десяток кабелей попроще можно купить вдесятеро дешевле.
Производителю нужно, чтобы его продукт продавался, и он это делает так, как умеет. Хотите совместимости со всем вообще — покупайте только такие продукты, голосуйте рублем и ногами. Нет таких — сделайте и постарайтесь продать. Не вышло — значит это не нужно никому, кроме вас, прошу искреннего пардону.
С кэшем там непонятно, потому что ядро там Quark DXk, т.е. кэш может и быть, и не быть, синтезируют что захотят. Почти все написано на верилоге, и поэтому у одного процессора (серверного, например), может быть и L1I, и SRAM, а у другого (атома) — ни того, ни другого.
Я не хочу с вами спорить, я только пояснил, почему ситуация именно такая, а не иная.
Не нравится — не ешьте, меняйте дебильную систему команд на нормальную, предлагайте архитектуры, пишите петиции, делайте свои собственные процессоры так, как вы считаете нужным, и рынок потом вас рассудит.
Предлагать я тоже могу что-угодно, любой степени сложности и реализма, а по факту количество специализированных закрытых контролеров с собственной прошивкой у всех только растет, а количество вещей, реализованных на железе, с каждым поколением уменьшается, потому что делать вещи на железе — дорого.
Лестно, но не верно, я тоже могу ошибаться и ошибаюсь.
Пруф на относительную дороговизну генерации частот — без проблем, блок Integrated Clock Control вынесен у Intel в прошивку начиная с MEv7 (Sandy Bridge), у AMD — с внедрения SMU (точную модель не помню, но лет 10 уже как минимум). Занимаются оба управлением частотами и питанием, которое делать на железе было бы намного дороже тупо потому, что писать на верилоге сложнее, чем на С.
У IBM есть уже POWER без этих извращений, и TalosII с открытыми прошивками, только за $5k+ и без нормального ПО они мало кому нужны. Кому надо — пожалуйста, но рынку это все нужно постольку-поскольку.
Все эти извращения созданы по двум причинам: 1. софт намного дешевле железа и в производстве, и в поддержке. 2. место на кристалле под дополнительные контролеры сейчас бесплатное.
В итоге те, кто переходит на сотовые реализации своих фич, получают конкурентное преимущество (больше фич за те же деньги), и выдавливает остальных с рынка. Таким образом у нас появились сначала микрокоды (декодировать все операции на железе — дорого), затем контролеры ICC (управлять питанием и генерацией частот на железе — дорого), а затем и МЕ с PSP (выполнять инициализацию на железе — дорого). А раз сервисный процессор общего назначения уже есть, на него можно заодно повесить побольше фич, и пока он тормозить не начнет, потом поставить такой же, но мощнее (переход с МЕ7-10 на МЕ11-12), и повесить еще больше фич, теснее интегрировать с остальными железками внутри SoC ради еще большего количества фич, так далее по кругу. Это все — реально продает, и потому будет длиться несмотря на любые петиции.
Еще раз скажу спасибо коллегам из PT за все, что они делают вокруг МЕ. За прошедшие пару лет с безопасностью там стало намного лучше, чем было до этого, и это случилось исключительно благодаря Максиму, Марку и Дмитрию. Так держать!
Лучший способ использования небезопасным инструментом — не пользоваться им, если это возможно.
Т.е. если у вас кроме C и ассемблера ничего нет и не будет, тогда нужны правильные процессы, анализаторы, верификаторы, санитайзеры и прочий остальной тулинг, а сами вы должны быть готовы писать по 50 строк в день и защищать на ревью каждую строку.
Не хотите? Используйте более безопасные инструменты, оставив С тем, кому от него деваться некуда.
Непонятно, зачем технарям-машиностроителям вообще может понадобится зубодробительный матан (и другие науки), чтобы преподавать его своим магистрам. Они в магистратуре знания углубляют по своему Schwerpunkt'у, а если этот самый пункт для бакалавров много матана не подразумевал, то у магистров его вообще совсем может не быть.
Я там выше тоже жаловался на слабое владение мат. аппаратом у магистров информатики, но по факту это аппарат нужен весьма небольшому количеству людей (потому что криптография и криптоанализ — не хер собачий, и с наскока за семестр все равно не изучается), а остальным нужны знания практические, т.е. не «как в деталях устроен AES-GCM», а «как и когда его правильно применять, чтобы реализация оставалась стойкой». Это, вообще говоря, две ортогональные системы знания, и в TH первому чаще всего просто не учат, т.к. незачем.
Два чая этому господину.
Тоже несколько участвовал в собеседованиях вчерашних студентов на позицию junior firmware developer, пока работал в Германии, на оценки мы смотрели исключительно если появзялись какие-то сомнения, а их чаще всего уже не было к этому моменту.
Даже с учетом того, что физически разъем выглядит одинаково, его по причинам вполне прозаическим не делают совместимым со всеми режимами, альтернативными или нет, и кабелей таких, по которым все вообще режимы работали бы — нет, и не надо. О чем я и написал, а ваших вопросов теперь понять не могу, т.к. это не я хочу один кабель на все случаи жизни.
Опять же, никто не мешает USB IF послезавтра выпустить еще десяток альтернативных режимов для которых понадобятся свои кабеля, и задача сведется к предыдущей.
Если у вас задача не влезает по сложности в дизайн — это показатель того, что решать ее рано. Ах, надо уже вчера? Ну тогда никто не гарантирует никакого качества, кроме того, что получится. Именно так получается нынешнее ПО, нынешние процессоры и все остальное. Нужно лучше — планируйте, контролируйте, используйте подходящие инструменты, контролируйте, хорошо платите, контролируйте, и не забывайте контролировать, это обязательно.
Пока это все не станет выгодно (т.е. ничем другим от конкурентов отличиться станет невозможно, кроме размера и\или скорости кода), для масс это не будет сделано никогда, потому что это адски дорого, адски долго, а на выходе получаются только примитивные вещи, влезающие в дизайн по ТЗ.
Чтобы бить задачи на подзадачи, нужно ясное видение «что именно строим», и план детальный к нему. По нынешней же моде это все называется жутким словом «водопад» и преподносится дорогими консультантами как жуткое болото, страшный суд, ад и погибель (о том, что так делается любой инженерный проект от моста через реку до ракеты, консультанты умалчивают почти всегда). Теперь у нас в моде эджайл, скрам, канбан и прочее все, призванное ПО не разрабатывать, а выращивать, лепя MVP из песка, тряпок и скотча, чтобы релизить быстрее, потому что иначе деньги кончатся, а инвесторы не дадут новые.
Никто не захотел думать (не знал, не стал заморачиваться, не влезал в строки, не влезал в бюджет, не влезал в целевую производительность, причины точные не знает никто), что процессор можно атаковать с этой стороны. Почему раньше никто не переживал по поводу того, что kernel.dll отображается по фиксированному адресу, а теперь это большая проблема? Почему никто не пытался предотвращать исполнения страниц памяти с данными, а теперь все стараются всеми силами? Почему аппаратура начала вести теневые стеки, подписывать указатели и тегировать динамическую память, а раньше об этом никто не думал?
Все потому, что программирование — оно в основном про то, как выполнить задачу бизнеса при определенном наборе входных данных и выдать относительно приличный результат за относительно же приличное время. Написание программы, работа которой возможна при любых входных параметрах, противостоящей утечкам данных из любых общих ресурсов, тайминг-атакам и всему тому, что появилось за 50 лет противостояния брони и снаряда — это совсем другая задача за совсем другие деньги.
Автору посоветую пойти и попробовать разобраться досконально хотя бы с современными архитектурами, т.е. как оно там все работает «на самом деле», начиная прямо с собирания сумматора из подручных материалов (как у Петцольда в известной книге), написания процессора простейшего на верилоге и так вверх до ЖаваСкрипта со всеми остановками. Где-то на реализации первых сложных команд в микрокоде придет понимание того, что писать все так, чтобы летало, при этом было доступно вчерашним школьникам, масштабировалось, обновлялось, свистело и пердело — просто настолько умопомрачительно дорого по всем параметрам, что позволить себе это могут либо огромные корпорации, либо гениальные энтузиасты (вроде Беллара). Все остальные берут то, что уже есть, и добавляют к нему то, чего еще нет, но хотелось бы иметь, либо комбинируют то, что уже есть, нужным им способом. Да, медленно, да 10 слоев, да эмуляция виртуализации эмуляции, да, никто понять не может толком уже давно, но результат — вот он, решения в массы, деньги в кассы.
Рынку же нафиг не нужна унификация, наоборот каждому игроку нужны свои, ни с чем не совместимые и запатентованные разъемы, кабели, периферия, и собственные стандарты вообще на все, иначе прибыль от продажи всех сопутствующих товаров падает.
Кроме того, если вам сделать один кабель USB-C, по которому можно будет передавать и Thunderbolt, и USB 3.1, и питание, и аудио цифровое и аналоговое, и черта лысого оцифрованного — такой кабель будет толщиной в палец и стоить 50 долларов за метр, а покупать его никто не будет, потому что десяток кабелей попроще можно купить вдесятеро дешевле.
Производителю нужно, чтобы его продукт продавался, и он это делает так, как умеет. Хотите совместимости со всем вообще — покупайте только такие продукты, голосуйте рублем и ногами. Нет таких — сделайте и постарайтесь продать. Не вышло — значит это не нужно никому, кроме вас, прошу искреннего пардону.
Не нравится — не ешьте, меняйте дебильную систему команд на нормальную, предлагайте архитектуры, пишите петиции, делайте свои собственные процессоры так, как вы считаете нужным, и рынок потом вас рассудит.
Предлагать я тоже могу что-угодно, любой степени сложности и реализма, а по факту количество специализированных закрытых контролеров с собственной прошивкой у всех только растет, а количество вещей, реализованных на железе, с каждым поколением уменьшается, потому что делать вещи на железе — дорого.
Пруф на относительную дороговизну генерации частот — без проблем, блок Integrated Clock Control вынесен у Intel в прошивку начиная с MEv7 (Sandy Bridge), у AMD — с внедрения SMU (точную модель не помню, но лет 10 уже как минимум). Занимаются оба управлением частотами и питанием, которое делать на железе было бы намного дороже тупо потому, что писать на верилоге сложнее, чем на С.
Все эти извращения созданы по двум причинам: 1. софт намного дешевле железа и в производстве, и в поддержке. 2. место на кристалле под дополнительные контролеры сейчас бесплатное.
В итоге те, кто переходит на сотовые реализации своих фич, получают конкурентное преимущество (больше фич за те же деньги), и выдавливает остальных с рынка. Таким образом у нас появились сначала микрокоды (декодировать все операции на железе — дорого), затем контролеры ICC (управлять питанием и генерацией частот на железе — дорого), а затем и МЕ с PSP (выполнять инициализацию на железе — дорого). А раз сервисный процессор общего назначения уже есть, на него можно заодно повесить побольше фич, и пока он тормозить не начнет, потом поставить такой же, но мощнее (переход с МЕ7-10 на МЕ11-12), и повесить еще больше фич, теснее интегрировать с остальными железками внутри SoC ради еще большего количества фич, так далее по кругу. Это все — реально продает, и потому будет длиться несмотря на любые петиции.
Т.е. если у вас кроме C и ассемблера ничего нет и не будет, тогда нужны правильные процессы, анализаторы, верификаторы, санитайзеры и прочий остальной тулинг, а сами вы должны быть готовы писать по 50 строк в день и защищать на ревью каждую строку.
Не хотите? Используйте более безопасные инструменты, оставив С тем, кому от него деваться некуда.
Я там выше тоже жаловался на слабое владение мат. аппаратом у магистров информатики, но по факту это аппарат нужен весьма небольшому количеству людей (потому что криптография и криптоанализ — не хер собачий, и с наскока за семестр все равно не изучается), а остальным нужны знания практические, т.е. не «как в деталях устроен AES-GCM», а «как и когда его правильно применять, чтобы реализация оставалась стойкой». Это, вообще говоря, две ортогональные системы знания, и в TH первому чаще всего просто не учат, т.к. незачем.
Тоже несколько участвовал в собеседованиях вчерашних студентов на позицию junior firmware developer, пока работал в Германии, на оценки мы смотрели исключительно если появзялись какие-то сомнения, а их чаще всего уже не было к этому моменту.