Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, lpd, Вы писали:

lpd>>Допустим, разрабатывается embedded код, или новая ОС. Процесс существенно осложняется добавлением ВМ, хранилища бинарников, версиями этого добра и прописыванием везде путей к нему.
WH>Тут ты просто что-то себе навыдумывал.

Это ты сводишь вопрос к сравнению своего опыта приложений Java/C# vs С++.
Непростая закулиса VM необходима, и у нее могут быть настройки, несовместимости и баги.
Так или иначе, VM добавляет еще один слой абстракции между процессором и высокоуровневым языком программирования. Это усложнение жизни ты предлагаешь провести ради весьма гипотетического облегчения жизни процессоростроителям. Я предлагаю сначала доказать существование проблемы, и только затем прилагать усилия для ее решения, объективно взвешивая все за и против. Лучшим вариантом я бы вообще считал отсутствие зоопарка процессоров.

Здравствуйте, CoderMonkey, Вы писали:

CM>Этого было недостаточно. Сейчас уже вполне очевидно, что росту частоты пришел конец и нужно намного больше ядер. Проблема в том, что для когерентного кэша накладные расходы растут полиномиально с ростом числа ядер. Значит — нужен некогерентный. А это значит — заодно переписывать все компиляторы

Боюсь, что для NUMA новым компилятором не отделаешься.

Здравствуйте, Sharov, Вы писали:
S>Если не правильно составил запрос -- логическая ошибка, как типизация поможет?
Точно так же, как она помогает в обычных языках. Это в K&R С можно было перепутать местами адрес строки и номер позиции в ней, и компилятор бы и бровью не повёл.
Современный C зачем-то отличает char* от int.

А вот жизнь всем разработчикам субд осложнила бы. Да и от диалектов это бы не спасло.
S>Про декомпозицию вообще не понял.
Попробуйте написать функцию, которая возвращает список заказов, а в параметрах принимает список менеджеров.
Чтобы можно было, скажем, передать туда не XML (омг!), а, к примеру, select manager_id from managers where RegionCode = "LATAM"
А в другом месте — select manager_id from managers where director_id = 850.
Классика жанра — постройте мне table-valued функцию, которая возвращает список заказов по заданным параметрам.
При этом параметры могут быть NULL, что означает "не фильтровать по заданному параметру".

На строго типизированном linq это нефиг делать:

if (startDate.HasValue)
{
  q = from s in q where s.Date >= startDate.Value select s
} 
if (endDate.HasValue)
{
  q = from s in q where s.Date <= endDate select s
}

На T-SQL вы либо убьёте производительность, написав длиннющюю простыню из OR startDate is NULL, либо будете мучительно клеить строки и вызывать EXEC, надеясь что в продакшне не стрельнет редкое сочетание параметров или что там не затешется SQL injection.

Здравствуйте, lpd, Вы писали:

lpd>Это ты сводишь вопрос к сравнению своего опыта приложений Java/C# vs С++.
lpd>Непростая закулиса VM необходима, и у нее могут быть настройки, несовместимости и баги.
И где всего этого добра нет?

lpd>Так или иначе, VM добавляет еще один слой абстракции между процессором и высокоуровневым языком программирования.
Это не правда. Все компиляторы имеют внутри себя некоторую ВМ. Или даже несколько. Просто они не сохраняют этот код, а сразу генерируют нативный код.

lpd>Это усложнение жизни ты предлагаешь провести ради весьма гипотетического облегчения жизни процессоростроителям.
Вполне реального. Ты вообще видел, как происходил переход с x86-32 на x86-64. Это же просто курам на смех. Процессор обновился куча софта работать перестала. Несколько лет прошло прежде чем всё снова заработало.

lpd>Я предлагаю сначала доказать существование проблемы, и только затем прилагать усилия для ее решения, объективно взвешивая все за и против.
Я её своими глазами видел. Итаниум вообще сдох из-за этого.

lpd>Лучшим вариантом я бы вообще считал отсутствие зоопарка процессоров.
Есть много разных задач. И для них нужны разные процессоры.
Так что лучшим решением является ОС на основе ВМ. В этом случае мы можем легко запустить главную задачу на наиболее подходящем процессоре и получить весь периферийный софт совершенно без усилий.

Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, lpd, Вы писали:

lpd>>Лучшим вариантом я бы вообще считал отсутствие зоопарка процессоров.
WH>Есть много разных задач. И для них нужны разные процессоры.
WH>Так что лучшим решением является ОС на основе ВМ. В этом случае мы можем легко запустить главную задачу на наиболее подходящем процессоре и получить весь периферийный софт совершенно без усилий.

Embedded не считаем, т.к. там никто не будет для каждой прошивки городить VM. Остаются только универсальные PC, где рынок поделен между Intel и в некоторой степени ARM. Не вижу необходимости помогать в конкуренции ни одному из них.
За последние 15 лет принципиально новыми процессорами можно считать только разве что GPU. Поэтому я не думаю, что ситуация изменится без научных прорывов.

WH>Я её своими глазами видел. Итаниум вообще сдох из-за этого.
Тут не знаю, однако сомневаюсь. Если Итаниум был значительно лучше других, Linux и софт бы на него спортировали без проблем.

Здравствуйте, GarryIV, Вы писали:

GIV>Боюсь, что для NUMA новым компилятором не отделаешься.

Ну если фантазировать, то зачем мелочиться?

Здравствуйте, WolfHound, Вы писали:

PD>>Убеждает, но она не заявляет, что даже в крайне гипотетическом случае сумма углов треугольника может хоть чуть-чуть отличаться от 180.
WH>А ты знаешь, что при переписывании доказательств математических теорем на верифицируемый машиной язык наши кучу ошибок в доказательствах? Ошибки конечно исправили, но сам факт.

Эээ, минуту. В чем нашли-то ? В доказательствах или в теоремах ? Если первое — это на сами теоремы вообще-то никак не влияет. Ну нашли ошибку в доказательстве, но теорема-то верна ? Надо ее по-иному доказать, вот и все.
А вот если нашли случай неверности теоремы — это совсем иное.

WH>Вот мы говорим ровно про такой случай.

PD>>Это как-то противоречит утверждению о том, что возможна пусть даже гипотетически ситуация, когда "в доказательстве верификатора будет ошибка". Одно из двух — либо он доказал (в математическом смысле) — тогда ошибки быть не может, либо это не доказательство.
WH>Либо доказательство с ошибкой.

WH>Но учитывая то что верификатор маленький и простой как пень вероятность такой ошибки около нуля. И главное он тоже верифицирован машиной. Так что можно спать спокойно.

Ладно, будем спать спокойно.

Подводя итог (со своей стороны).

Я вовсе не против этой идеи. Вполне возможно, что она имеет право на существование. Мой скепсис объясняется в основном интуитивным недоверием к аргументу "математически доказано" в применении к ИТ. Просто о доказательствах правильности программ я слышал еще во времена моей молодости, и, похоже, в плане практического применения этих доказательств дело обстоит примерно так же, как во времена моей молодости
Так что если и впрямь появится такая система, используемая в промышленных масштабах — посмотрим на нее и будем судить, насколько она надежнее существующих. Прототипы вроде Singularity меня не убеждают — на моей памяти было много хороших идей, которые на этапе прототипирования или даже создания альфа-версии казались перспективными, а в итоге никуда не пошли.

Здравствуйте, Sinclair, Вы писали:

S>В протоколе HTTP нет ничего про & и знаки вопроса.

Ну по крайней мере в версии RFC 2616 '?' есть

https://tools.ietf.org/html/rfc2616#section-3.2.2

Впрочем, это неважно, мы не на заседании комитета стандартов. Назовем это не HTTP, а реальной практикой использования HTTP, а в ней эти ?& точно уж есть. Оставил бы их как есть ?


PD>>И вот тут я не уверен. Формат "список ключ:значение" можно было бы тоже на что-то более структурированное заменить.
S>И какую проблему это призвано решить?

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

PD>>По существу, HTTP запрос — это же просто вызов некоторого метода клиентом через сеть на сервере. Своего рода RPC. И этому методу надо параметры передать.
S>Это плохой способ представлять себе работу HTTP.
PD>>Если бы ты (демиург) в момент, когда старое ПО уже уничтожено, а новое еще не создано, стал бы проектировать способ передачи параметров — ты точно сделал бы ее передачу в двух местах (а для POST/PUT и в 3 — json/xml в body) и в таком формате ?
S>Да, именно в двух местах.
S>Параметры в URL — это не часть HTTP.

Да ладно, пусть не часть. Но практика такова, что это часть. Хорошо, не HTTP сам, а эту практику ты бы оставил как есть или все же поменял ?

S>Заголовки — это такая специальная штука с предопределённым значением. Благодаря им, между клиентом и сервером можно вклинить proxy, который умеет делать разные полезные штуки. Это не "параметры метода" — RPC это вообще плохая идея сама по себе, а уж тем более плохой способ думать о HTTP.
S>А структура body, которая, собственно, и является "параметром", в протоколе никак не закреплена.

Хорошо, заголовки отложим. Пусть так. Но от того, что часть параметров де-факто передается через URL, а часть — через body, ты никуда не денешься. Оставил бы так же ?
Кстати, оставил бы де-факто существующий запрет в GET передавать body ?

Здравствуйте, Pavel Dvorkin, Вы писали:
S>>В протоколе HTTP нет ничего про & и знаки вопроса.
PD>Ну по крайней мере в версии RFC 2616 '?' есть
PD>https://tools.ietf.org/html/rfc2616#section-3.2.2
PD>Впрочем, это неважно, мы не на заседании комитета стандартов. Назовем это не HTTP, а реальной практикой использования HTTP, а в ней эти ?& точно уж есть. Оставил бы их как есть ?
Упростил бы. В текущей спеке слишком много деталей про структуру URI — она заставляет людей думать, что надо делать именно так. Например,
Интерпретация URI — это уже дело user-agent. А в рамках протокола даже использование relative URI — уже плохая идея.

PD>Да не в проблеме же дело, речь идет не о том, чтобы решить какую-то проблему, а о том, как это должно бы выглядеть при проектировании. Надо спроектировать новый протокол, и при этом ты знаешь, что это не однодневка будет, а нечто на годы, если не на века. И надо его сделать как можно более стройным и логичным.
PD>Оставишь как есть или все же изменишь ?
Саму схему бы оставил; конкретные особенности бы упростил. В частности, слишком много заголовков управляют сроками годности и кэшированием. Тут тебе и Cache-control:max-age, тут и Expires.
Всё это стоило бы ортогонализировать и ужесточить требования к серверам.

PD>Да ладно, пусть не часть. Но практика такова, что это часть. Хорошо, не HTTP сам, а эту практику ты бы оставил как есть или все же поменял ?
Оставил бы конечно. На её основе работают крайне полезные механизмы.

PD>Хорошо, заголовки отложим. Пусть так. Но от того, что часть параметров де-факто передается через URL, а часть — через body, ты никуда не денешься. Оставил бы так же ?
Да.
PD>Кстати, оставил бы де-факто существующий запрет в GET передавать body ?
Да. Без этого невозможно построить корректное кэширование ответов на GET.

Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Одним махом уничтожается весь существующий нативный код.
Ну ты же сам просил именно об этом. Выкидываем весь этот ужасный нативный код на помойку, и пишем уже на нормальных, статически-верифицированных платформах.
PD>Далее. Представь себе, что это программа линейной алгебры. Там этих a[i][j] в каждой строке может быть по нескольку штук. Если заставлять каждое такое описание верифицировать по твоему механизму — код за этими верификациями видно уже не будет, а отладка превратится в ад.
Ничего подобного. Мы же пишем не на K&R C, а на полноценном языке программирования, созданном с нуля.
В нём компилятор с верфикатором видят, что i и j заведомо ограничены размерами обрабатываемых массивов, поэтому никаких проверок внутри циклов нет.

PD>А не запретишь. И управляемые языки не помогут. Ты же ОС собрался делать, и что, ты мне скажешь, что в этой ОС писать "тяжелый" код можно только на управляемых языках?
Конечно.
PD> Он и без того тяжелый, там O(N^3), например, а мне, выходит, его оптимально написать нельзя ?
Почему нельзя? Можно.
PD>Кроме того, почему ты решил, что массив отведен в стеке ? Для него относительно просто написать stack_available. А если в куче ? Да еще двумерный и при этом jagged ? И при этом еще и не прямоугольный, а хорошо если только треугольный ? Тебе не кажется, что такая "статическая" проверка просто не получится ? А еще realloc (в С) есть. А еще union в нем же есть.
Ну мы же выкинули язык C за ненадобностью. Вместе с union. И вместо realloc у нас операция, которая "сбрасывает" результаты проверок, и верификатор потребует повторной проверки.

PD>Что-то у меня такое ощущение, что это лекарство хуже болезни. Сейчас мне как программисту по крайней мере все ясно — я могу делать (в нативе) что хочу, за свои безобразия в юзермодной части АП я отвечаю сам (кстати, и тут мне помогают, доступ к невыделенным адресам блокируется), а за попытку безобразия в системной части АП будут бить со 100% гарантией. И код я при этом пишу, как его всегда писали. А тут предлагается писать его совсем по-другому, с массой накладных расходов, а успех не гарантирован.
Павел, ты уже реши — хочется "пишу, как его всегда писали", или какого-то прогресса. Если хочется того же самого, что есть сейчас — ну так оно и сейчас есть. Со всеми его недостатками — ограниченным быстродействием процессоров, и дырами в "абсолютной защите" сверху донизу. А если хочется реально изменить мир, без оглядки на существующий код, то надо идти в правильных направлениях.
Убираем все эти неэффективные кольца защиты, и сразу получаем ускорение на вызовах системного кода. А потом можно уже и процессор поменять — раз нету кода, который бы прыгал между разными кольцами, то все эти аппаратные проверки можно просто выкинуть, и наиграть ещё производительности и энергоэффективности на ровном месте.

Здравствуйте, Sinclair, Вы писали:

PD>>Да ладно, пусть не часть. Но практика такова, что это часть. Хорошо, не HTTP сам, а эту практику ты бы оставил как есть или все же поменял ?
S>Оставил бы конечно. На её основе работают крайне полезные механизмы.

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

PD>>Хорошо, заголовки отложим. Пусть так. Но от того, что часть параметров де-факто передается через URL, а часть — через body, ты никуда не денешься. Оставил бы так же ?
S>Да.

Почему ? Твой аргумент насчет того, что хедер — это не параметр, я могу относительно принять. Относительно потому, что через header часто передают и user-defined values. Может, это опять же не стандарт, но де-факто такая практика есть.
А вот насчет того, что часть параметров передается через URL, а часть через body — я аргументов от тебя не услышал.
Так что в итоге все же 3 места (для POST/PUT). URL, header user defined, body

PD>>Кстати, оставил бы де-факто существующий запрет в GET передавать body ?
S>Да. Без этого невозможно построить корректное кэширование ответов на GET.

Хм. Почему при передаче параметров через URL можно, а через body — нельзя ? В любом случае это R/O информация для запроса. В ответе ее нет.

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Здравствуйте, WolfHound, Вы писали:

WH>>ОС находит те места, которые не может верифицировать и добавляет туда проверку.

PD>М-да... В общем, без проверок в рантайме ничего не выходит ни у тебя, ни у AlexRK. Если ОС или верификатор не может верифицировать, надо вставлять проверку в рантайме,
PD>Кстати, не совсем понял, как ОС верифицировать-то будет ? Вроде в дискуссии с AlexRK мы исходили из того, что проверяет статический анализатор на этапе компиляции.
PD>Компиляция прошла давно, на машине пользователя бинарник. Машинные коды верифицировать будем ?
Павел, у меня такое ощущение, что последние 10 лет прошли мимо. Я бы понял, если бы мы обсуждали какую-то новую, гипотетическую идею.
Но ведь мы говорим о вещах, проверенных на практике.
В частности, Singularity была выпущена чёрти когда. И "не пошла" она не потому, что там дыра в верификаторе, или что программы под неё невозможно написать.
А тупо потому, что нет волшебной палочки, способной выбросить на помойку весь существующий код.
PD>Вот только бы знать, насколько менее надежен.
Он намного более надёжен.

Здравствуйте, Sinclair, Вы писали:

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

Если бы ты пораньше ответил, я бы с тобой подискутировал на тему статической верификации. А так мы уже с AlexRK, WolfHound и samius вчера столько понаписали, что повторяться не буду.

PD>>А не запретишь. И управляемые языки не помогут. Ты же ОС собрался делать, и что, ты мне скажешь, что в этой ОС писать "тяжелый" код можно только на управляемых языках?
S>Конечно.

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

PD>> Он и без того тяжелый, там O(N^3), например, а мне, выходит, его оптимально написать нельзя ?
S>Почему нельзя? Можно.

Я не думаю, что стоит еще раз начинать флейм на тему : можно ли на управляемом коде написать столь же эффективно, как на нативе. Мою позицию ты знаешь.

PD>>Кроме того, почему ты решил, что массив отведен в стеке ? Для него относительно просто написать stack_available. А если в куче ? Да еще двумерный и при этом jagged ? И при этом еще и не прямоугольный, а хорошо если только треугольный ? Тебе не кажется, что такая "статическая" проверка просто не получится ? А еще realloc (в С) есть. А еще union в нем же есть.
S>Ну мы же выкинули язык C за ненадобностью. Вместе с union. И вместо realloc у нас операция, которая "сбрасывает" результаты проверок, и верификатор потребует повторной проверки.

Вот это поясни. Верификатор, что, в рантайме работает ? Тогда это уж никак не статический верификатор, а просто динамический контроль индексов в стиле Java/C#

PD>>Что-то у меня такое ощущение, что это лекарство хуже болезни. Сейчас мне как программисту по крайней мере все ясно — я могу делать (в нативе) что хочу, за свои безобразия в юзермодной части АП я отвечаю сам (кстати, и тут мне помогают, доступ к невыделенным адресам блокируется), а за попытку безобразия в системной части АП будут бить со 100% гарантией. И код я при этом пишу, как его всегда писали. А тут предлагается писать его совсем по-другому, с массой накладных расходов, а успех не гарантирован.
S>Павел, ты уже реши — хочется "пишу, как его всегда писали", или какого-то прогресса. Если хочется того же самого, что есть сейчас — ну так оно и сейчас есть. Со всеми его недостатками — ограниченным быстродействием процессоров, и дырами в "абсолютной защите" сверху донизу. А если хочется реально изменить мир, без оглядки на существующий код, то надо идти в правильных направлениях.

Я хочу идти в правильном направлении, но я не уверен, что это направление правильное.

Здравствуйте, Sinclair, Вы писали:

S>Но ведь мы говорим о вещах, проверенных на практике.
S>В частности, Singularity была выпущена чёрти когда. И "не пошла" она не потому, что там дыра в верификаторе, или что программы под неё невозможно написать.
S>А тупо потому, что нет волшебной палочки, способной выбросить на помойку весь существующий код.

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

PD>>Вот только бы знать, насколько менее надежен.
S>Он намного более надёжен.

Ладно, поверю тебе на слово

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Пусть даже это очень редко будет. Но все же ты допускаешь возможность, что где-то верифицировать не удастся, и придется проверять в рантайме.
Ты не понимаешь, что такое верификация, и что такое "верифицировать не удастся".
Полноценная верификация произвольного кода эквивалентна проблеме останова.
Поэтому в реальных системах верификация делается "скептической".
Это означает, что иногда верификатор "не видит" корректности кода. Условно:

InfinitePrecision Fail()
{
  var a = GetInputFromUser();
  var b = sin(a)*sin(a)+cos(a)*cos(a);
  return sqrt(b - 1.0); // верификатор: possible negative!
}

Такая программа не пройдёт верификацию, если нам запрещено вычислять квадратный корень из отрицательных аргументов. Автор знает, что b всегда равно 1, но верификатор неспособен это доказать.
Чтобы программа заработала, программисту придётся обложить вызов sqrt в _данном месте_ проверкой:

InfinitePrecision Fail()
{
  var a = GetInputFromUser();
  var b = sin(a)*sin(a)+cos(a)*cos(a);
  if (b>=0)
    return sqrt(b - 1.0); // верификатор: ok!
  else
    return 42;
}

Совершенно необязательно для этого замусоривать весь код такими проверками. В тех местах, где вывод можно сделать автоматически, он делается автоматически.
Опять же, никто не мешает обернуть нашу sqrt в safe_sqrt(), которая прячет внутри проверку.

Здравствуйте, alex_public, Вы писали:

_>Здравствуйте, WolfHound, Вы писали:

PD>>>Я же не против верификатора, но речь-то идет об ОС, где нужна 100% надежность, хотя бы в принципе. Одна дыра — и мало не покажется, не заштопаешь. Программы уже на компьютере пользователя, этап статической верификации позади, иной защиты нет, не поправишь, как Meltdown.
WH>>
WH>>Это просто курам на смех. Обновить ОС куда проще. После чего ОС перепроверит весь установленный софт.

_>Так ты хочешь верификатор, который работает не с исходным, а с исполняемым кодом? Хм хм хм...
Именно такой верификатор встроен в Singularity. Не вижу никакого смысла цепляться за идею поставки сырого кода x86 на машину пользователя.
Если нас не беспокоит время старта приложения — то тупо делаем верификацию непосредственно перед JIT.
Если беспокоит — то выполняем верификацию перед ngen.

Здравствуйте, Sinclair, Вы писали:

Ты повторяешь то, что написал AlexRK.

Здравствуйте, lpd, Вы писали:
lpd>Embedded не считаем, т.к. там никто не будет для каждой прошивки городить VM. Остаются только универсальные PC, где рынок поделен между Intel и в некоторой степени ARM. Не вижу необходимости помогать в конкуренции ни одному из них.
lpd>За последние 15 лет принципиально новыми процессорами можно считать только разве что GPU. Поэтому я не думаю, что ситуация изменится без научных прорывов.
Вы путаете причину и следствие. Отсутствие новых процессоров — это последствия огромного багажа несовместимого кода.
Вывести новую архитектуру на рынок — это титанические инвестиции. А вот если бы основные современные платформы были бы построены на промежуточном коде, то новые процессоры бы выходили ежеквартально.

pd>Тут не знаю, однако сомневаюсь. Если Итаниум был значительно лучше других, Linux и софт бы на него спортировали без проблем.
Это проблема курицы и яйца. Вот есть итаниум — он дорогой, потому что его мало выпускают.
Выпускают мало потому, что его мало покупают.
Покупают мало потому, что он дорогой, и под него нет софта.
Софта под него нет потому, что его очень мало, и производителям тупо невыгодно заниматься поддержкой ещё одной платформы.

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Вот это поясни. Верификатор, что, в рантайме работает ? Тогда это уж никак не статический верификатор, а просто динамический контроль индексов в стиле Java/C#

Вы никак не поймете простую вещь. Верификатор работает на этапе компиляции (ну, еще на этапе инсталляции происходит верификация промежуточного кода, но речь не об этом). Компилятор заставляет вставить рантайм-проверки в тех местах, где они нужны. Но это совершенно не эквивалентно тому, что есть в C#/Java! В управляемых языках проверки вставляются во всех местах, а в статически верифицированном коде — только там, где надо. Таких мест может быть на порядок меньше.

Здравствуйте, MTD, Вы писали:

MTD>Здравствуйте, Ziaw, Вы писали:

Z>>А задача армии дизайнеров и верстальщиков, сверстать дизайн в миллиметрах для каждого экрана.

MTD>Вот смотри. Палец среднестатистического человека, допустим имеет пятно контакта 5 на 5 мм, из этого следует, что надо кнопочку сделать 10 на 10 мм, условно. Потом, есть текст, известно, что он хорошо читается размером 7 мм, тоже условно. Если задавать размеры в мм, то и выглядеть везде будет одинаково и взаимодействовать будет возможно одинаково.

На одном экране помещается три кнопочки по 5мм в одну строку, на другом 50, в промежуточных — разное количество с разными полями между ними. Каждый интерфейс надо будет адаптировать под каждый экран.

MTD>Еще раз — 1 раз задать, получить одно и тоже везде. Теперь переходим к условным попугаям в пикселах — в зависимости от плотности пикселов размер меняется в разы, так что твой комментарий актуален сейчас, если перейти на миллиметры жизнь серьезно упроститься.

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

Сейчас например можно любой монитор отобразить на телевизоре или проекторе, как предлагаешь поступать в этих случаях?