Здравствуйте, 0x7be, Вы писали:
V>>А какая адекватная замена C/C++? 0>Какой-то другой язык, в котором из-за эволюционного развития не было бы таких ужасов
Конкретнее, что должен иметь этот язык программирования или даже не иметь. Чисто абстрактно можно вообразить, что есть такая система в которой программа сама создаётся под текущие плохо сформулированные требования, но это уже из области фантастики. К тому же в топике не сказано о замене аппаратной части, то есть мы имеем дело всё с тем же зоопарком из x86, x64, arm и так далее, и видеокарты у нас от зелёных и красных, а не квантовые суперкомпьютеры.
Или какое там было недавно обсуждение. Вот есть у нас некий новый язык программирования, но в нём нет множественного наследования. Кто-то скажет хорошо, а кто-то из-за отсутствия альтернативы начнёт его изобретать заново. Тоже самое с процедурной парадигмой, ну выкинем мы её и оставим обобщённое, а вместо функционального будем использовать объектно-ориентированное. Уровень абстракции повысился, а дальше мы наблюдаем, как программисты уже без нас изобретают процедурное и функциональное программирование.
Так-то если подумать, вот я например, лишил программистов .NET и Java. Сейчас уже признано, что нативный код быстрее. Тем не менее без наглядного примера ту же JIT-компиляцию переизобретут заново, причём ещё и будут всё это использовать. Получается идти нужно по пути создания ПО превосходящее всё имеющееся. А обычное урезание изобретённого приведёт лишь к тому, что люди так и так потратят время на переизобретение. Собственно говоря сейчас и без всяких допущений программирование движется этим путём.
Здравствуйте, 0x7be, Вы писали:
PD>>Железо осталось. Без изменений. 0>А чего так? Я пощупал немного MC68000 — после Intel`а просто рай какой-то. Всё просто и без затей.
Просто предлагаю обсудить только софт, чтобы не уходить в сторону.
От железа не так уж сильно софт в наше время зависит. Появись сейчас для десктопов новый процессор, принятый миром — и очень скоро Linux вместе с Windows для компьютеров на этом процессоре будут готовы. Практически с тем же API и теми же средствами.
А само железо обсуждать, в особенности линейку x86/x64 — так тут и обсуждать нечего. Если бы мой демиург пересоздал этот процессор в том же виде, в каком он сложился в ходе эволюции 4004 -> 8008 -> 8080 -> 8086 -> 80286 -> 80386 -> и далее, то это был бы не демиург, а идиот.
Здравствуйте, velkin, Вы писали:
V>Если в микроволновке примитивный микроконтроллер, тогда используется Си. А если, что покруче, тогда можно поставить линукс или что-то подобное. Обычной микроволновке нужна только машина состояний, здесь можно обойтись и без ОС.
ОС может понадобиться для того, чтобы этой микроволновкой управлять с мобилы. При этом программа микроволновки говорит внешнему окружению, что она микроволновка, умеет включаться, устанавливать мощность из определенного диапазона, умеет крутить гриль и говорить где она расположена. Соответственно я, как разработчик для умного дома могу написать софт, позволяющий на запрос "дай мне пожрать пиццы" достать пиццу из холодильника и поместить в микроволновку, разогреть и далее принести мне на стол. И это будет работать корректно если у меня есть микроволновка, холодильник и робот, который занимается перетаскиванием пищи. При этом микроволновка, холодильник, робот, друг о друге ничего не знают. Если у меня дома нет робота — система управления умным домом скажет что извини, у меня нет устройства для заполнения устройства приготовления пищи. Давай ка сам таскай, но посоветует купить робота.
Здравствуйте, elmal, Вы писали:
E>ОС может понадобиться для того, чтобы этой микроволновкой управлять с мобилы. При этом программа микроволновки говорит внешнему окружению, что она микроволновка, умеет включаться, устанавливать мощность из определенного диапазона, умеет крутить гриль и говорить где она расположена.
Разве для этого микроволновке нужна ОС? И нужно ли все ломать и начинать сначала, что бы появилась такая функциональность?
В 1999 вопросы коммуникации вещей предлагалось решать радиочастотными метками и простейшими протоколами.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Просьба все же оставаться в рамках темы. Ни железо, ни тем более внешний мир этому демиургу возможности изменять я не давал
А зря. Потому что современное железо является таковым по большей части из-за груза совместимости с написанным ранее ПО.
Здравствуйте, vdimas, Вы пис
V>А зря. Потому что современное железо является таковым по большей части из-за груза совместимости с написанным ранее ПО.
Тут 2 момента
Во-первых, архитектуру x86/x64 предложили бы переделать все, тут сомнения нет, нечего обсуждать.А какую именно нужно — на эту тему и без того обсуждений немало
Во-вторых, я не вполне согласен с тезисом. Линукс где только не работает, и появись новый процессор -будет и на нем работать. Windows тоже
А все, что выше ОС — так это совсем слабо от процессора зависит
PD>Что из того, что заложено в существующее ПО, сделано так, как и надо было бы "по уму" сделать, и что надо было бы сделать иначе, да только , увы, невозможно — мешают проклятая compatibility и огромные наработки ?
Всякий раз чётко решать, для кого делается пользовательское ПО (начиная от операционных систем) — мультяшно-однооконно-пальцетычное для тех кому напрягать мозг больно и страшно, или "инженерное" для не имеющих такой патологии. Если очень надо, то выпускать 2 разные версии. Но не пытаться сводить эти "2 мира, 2 морали" к наиглупейшему общему знаменателю, как делают микрософт с апле и на поводу у них толпа подражателей.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Что бы Вы из существующего сделали в практически том же виде, в каком оно существует сейчас и что сделали бы по-другому ?
Изобрел бы Фортран 77, наверное. Но с зарезервированными словами и без умолчаний.
И никаких GOTO. Арифметический IF — наше всё!
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Железо осталось. Без изменений.
Что ж так мелочиться то? Развитие железа зашло в жестокий тупик, а недавние (но наверняка не последние) уязвимости уже забивают крышку гроба гвоздями.
Нужно новое железо!
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Что бы Вы из существующего сделали в практически том же виде, в каком оно существует сейчас и что сделали бы по-другому ? Как уже упоминали — переделал бы JavaScript.
То есть оставил бы его очень похожим в общем, но починил бы мелочи — все эти автоприведения в сравнениях и прочий WTF, который сейчас не могут выкинуть из-за backwards compatibility. Cама по себе идея иметь HTML5+JS для мобильных приложений — здравая. Мелочи портят всю картину.
Сделал бы SQL строготипизированным.
Отказался бы от аппаратной изоляции в ОС, оставив только софтную с верификацией. Аппаратная защита — дорогая и небезопасная (см. Meltdown). Статическая верификация значительно надёжнее.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Pavel Dvorkin, Вы писали:
S> Отказался бы от аппаратной изоляции в ОС, оставив только софтную с верификацией. Аппаратная защита — дорогая и небезопасная (см. Meltdown). Статическая верификация значительно надёжнее.
Не будет медленно ?
И провокационный (зная твое отношение к этому) вопрос.
HTTP не изменил бы ? Или, может, на что-то иное заменил ?
Здравствуйте, Pavel Dvorkin, Вы писали: PD>Не будет медленно ?
Будет быстрее. Потому что нет переключений между кольцами для syscall. PD>И провокационный (зная твое отношение к этому) вопрос. PD>HTTP не изменил бы ? Или, может, на что-то иное заменил ?
Вот не знаю. HTTP2 вышел после того, как я перестал читать RFC на протоколы; поэтому не знаю, какие там приняты меры. В целом, HTTP/1.1 уже весьма прекрасен. Не знаю, что такое нужно делать, чтобы упереться в его ограничения в клиент-серверных приложениях.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Pavel Dvorkin, Вы писали: PD>>Не будет медленно ? S>Будет быстрее. Потому что нет переключений между кольцами для syscall.
А защита ? Ты предлагаешь ее на чисто софтверном уровне делать ? Но тогда и проверять каждый раз придется с использованием ПО, это вряд ли будет быстро
char * p = чему-то
*p = 0;
И как здесь на софтверном уровне проверять, имею ли я право доступа туда ? Встраивать на каждый mov команды проверки ?
PD>>И провокационный (зная твое отношение к этому) вопрос. PD>>HTTP не изменил бы ? Или, может, на что-то иное заменил ? S>Вот не знаю. HTTP2 вышел после того, как я перестал читать RFC на протоколы; поэтому не знаю, какие там приняты меры. В целом, HTTP/1.1 уже весьма прекрасен. Не знаю, что такое нужно делать, чтобы упереться в его ограничения в клиент-серверных приложениях.
Вопрос не в ограничениях, а в архитектуре. Тебе не кажется, что тот же интерфейс GET с параметрами можно бы на что-то более элегантное заменить ? И заодно Header переделать.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>>Не будет медленно ? S>>Будет быстрее. Потому что нет переключений между кольцами для syscall.
PD>А защита ? Ты предлагаешь ее на чисто софтверном уровне делать ? Но тогда и проверять каждый раз придется с использованием ПО, это вряд ли будет быстро
PD>char * p = чему-то PD>*p = 0;
PD>И как здесь на софтверном уровне проверять, имею ли я право доступа туда ? Встраивать на каждый mov команды проверки ?
Очевидно, доступ по произвольному адресу и арифметика указателей (да и вообще трактовка указателей как чисел) в прикладном коде полностью запрещается. В системном коде можно оставить ограниченные возможности манипуляции указателями, безопасность операций с которыми гарантируется статическим верификатором (но такое — "char * p = чему-то" — в любом случае запрещается).
ARK>Очевидно, доступ по произвольному адресу и арифметика указателей (да и вообще трактовка указателей как чисел) в прикладном коде полностью запрещается. В системном коде можно оставить ограниченные возможности манипуляции указателями, безопасность операций с которыми гарантируется статическим верификатором (но такое — "char * p = чему-то" — в любом случае запрещается).
Как ты себе это представляешь ?
Можно, конечно, не использовать указатели в Яве, С# или JS -коде , где их и нет. Так ведь в jvm, .net самой или браузере не запретишь же!
Если вообще запретить указатели (машинные адреса) в юзермоде — придется для каждой команды, работающей с памятью, переключаться в режим ядра. Это будет фантастическая просадка скорости.
А перенести jvm и т.д. в режим ядра — это просто будет означать перенос всей работы в ядро. После этого о безопасности ядра говорить будет сложно.
CM>Что ж так мелочиться то? Развитие железа зашло в жестокий тупик, а недавние (но наверняка не последние) уязвимости уже забивают крышку гроба гвоздями. CM>Нужно новое железо!
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Можно, конечно, не использовать указатели в Яве, С# или JS -коде , где их и нет. Так ведь в jvm, .net самой или браузере не запретишь же!
Почему нет? Запретишь. Просто делать что угодно будет нельзя (например, просто прибавить к указателю единицу и обратиться по этому адресу).
PD>А перенести jvm и т.д. в режим ядра — это просто будет означать перенос всей работы в ядро. После этого о безопасности ядра говорить будет сложно.
Да, речь именно о переносе всего в режим ядра (собственно, никаких "колец" уже и не будет). Безопасность обеспечивается статической верификацией (как в Singularity или Rust).
