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

O>1) Большинство (но не все) vnc серверы работают с экраном и прямоугольники для кэширования битмапов они "угадывают". Логично что в случае RDP, который в курсе где какие окна, такая гадалка работает намного лучше. Даже если все контролы — windowsless UI на Direct X, они все равно обычно поддерживают IAccessibility (правда пользуется ли этим RDP — хз).

WPF под RDC затачивали, а остальной windowless на платформе в исчезающих количествах.

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

C>На WinCE были ёмкостные экраны и альтернативные оболочки. Ничего фундаментального не мешало их допилить

Не мешало. Но не допилили же. А сторонние навески все равно как дырявый мешок с котом, да и тормозили дай боже.

O>>1) Большинство (но не все) vnc серверы работают с экраном и прямоугольники для кэширования битмапов они "угадывают". Логично что в случае RDP, который в курсе где какие окна, такая гадалка работает намного лучше. Даже если все контролы — windowsless UI на Direct X, они все равно обычно поддерживают IAccessibility (правда пользуется ли этим RDP — хз).
НС>WPF под RDC затачивали, а остальной windowless на платформе в исчезающих количествах.
Страницы отображаемые браузерами — это сплошной windowless, и я бы не сказал что Фаеркрап и Хромой — исчезающие количества...

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

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

V>>современный CISC в центральных процах продиктован ... особенностями сложившейся бизнес-модели распространения ПО, когда программы распространяются в виде готовых бинарников.

CC>Вай какой дурдом!
CC>CISC то тут каким боком?

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

V>>современный CISC в центральных процах продиктован ... особенностями сложившейся бизнес-модели распространения ПО, когда программы распространяются в виде готовых бинарников.
CC>Вай какой дурдом!
CC>CISC то тут каким боком?
Таким, что еслиб не нужно было прятать сырцы, то не надо было бы поддерживать x86 и вероятно изобретать такие технологии обфускации исходного кода как .NET и Java.

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

CS>Что-бы managed OS как-то работала этот managed GC heap должен покрывать всю память и все работать фактически в одном процессе — Android по факту.

Можно подобронее развернуть пассаж с андроидом ?

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

K>Абстрактное мышление и прочая математика как раз и начинаются с того, что ты видишь похожее в разном.
А просто мышление позволяет отличить чем одно похожее от другого отличается и не делать далекоидущих выводов без оснований.

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

V>>Увы, сейчас мы вернулись в нейтив в том самом первобытном кач-ве, как по мне.
CC>Нельзя ли раскрыть тему? В каком первобытном качестве? Потому как в моей окрестности ничего первобытного не наблюдается.

Распространение программ в низкоуровневом бинарном коде — это каменный век и есть. Помимо того, что это извечная дыра в безопасности, это, считай, бесконечная по весу гиря на ногах производителей процессоров. Это тот самый технологический тупик, который всех нас зажал в узкие рамки на ближайшие несколько десятилетий. В общей, вот этот груз "легаси-совместимости" на данном этапе невозможно никак перепрыгнуть. Это полная ж-па как она есть, сорри за обилие эпитетов. ))

В общем, идея относительно высокоуровневого байт-кода, снабжённым типизированным описанием, куда как более мощная ввиду заложенной в неё потенциально бесконечной гибкости. Прямо на конкретной железке из него при инсталляции можно генерить максимально-эффективный для данной конфигурации низкоуровневый код.

Т.е., не смотря на то, что у меня есть серьезная критика по многим моментам текущего стандарта байт-кода того же дотнета — это всё не столь принципиально, когда речь об идее. Сама идея сулила и продолжает сулить целую россыпь бенефитов. И как раз в первую очередь в плане загружаемых "на лету" по-настоящему переносимых и безопасных приложений (и/или их частей), что должно было стать стандартом де-факто работы гипотетического "современного компьютера".

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

V>Распространение программ в низкоуровневом бинарном коде — это каменный век и есть. Помимо того, что это извечная дыра в безопасности, это, считай, бесконечная по весу гиря на ногах производителей процессоров. Это тот самый технологический тупик, который всех нас зажал в узкие рамки на ближайшие несколько десятилетий. В общей, вот этот груз "легаси-совместимости" на данном этапе невозможно никак перепрыгнуть. Это полная ж-па как она есть, сорри за обилие эпитетов. ))

Можно подробнее, в чем принципиальные преимущества байт-кода? Когда он появился основным бонусом называлась переносимость java-апплетов, однако она мало используется на практике. Проблемы безопасности можно устранить и без байт-кода, если ты о переполнении буфера или привелегиях записи в память.

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

O>Cyberax видимо имеет ввиду что в приложениях, увешанных скинами как новогодняя елка, разницы между рдп и vnc будет немного, т.к. и там и там по сети гонятся jpg-шки или зипованные bmpшки.

Скорее ближе к PNG, бо основу трафика составляет зазипованная разница, да еще отдельно по цветовым слоям.


O>1) Большинство (но не все) vnc серверы работают с экраном и прямоугольники для кэширования битмапов они "угадывают".

Зачем "угадывать", если есть mirror driver?
Он достоверно "знает", какие области экрана изменились.
В RDP аналогично.

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

lpd>Можно подробнее, в чем принципиальные преимущества байт-кода?

В его абстракции и строгой типизированности.


lpd>Проблемы безопасности можно устранить и без байт-кода

Угу, но только за счёт внешней инфраструктуры. Т.е. получая приложения исключительно из т.н. "доверенных источников". Называя вещи своими именами — кормя при этом дармоедов — содержателей таких магазинов приложений. ))

Ну и, с высоты птичьего полёта — при такой насильственной централизации теряется тот самый элемент распределённости, легковесности, самоорганизации и т.д., который был двигателем бурного развития ПО предыдущие лет 30. Собсно, вот этот заповедник дикой природы под название Linux пока еще жив ровно по этой причине, несмотря на кучу своих фатальных недостатков — из-за полной свободы. Они как бы продлевают прошлые времена на сегодняшнюю реальность. С одной стороны это махровое олдскульство, с другой стороны, это "свобода предпринимательства" в плане ПО-технологий. ))

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

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

lpd>>Можно подробнее, в чем принципиальные преимущества байт-кода?

V>В его абстракции и строгой типизированности.

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

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

S>Здравствуйте, c-smile, Вы писали:


CS>>Делать весь Office в C# не реально по многим причинам. Собственно по тем же что создание HTML/CSS renderers на managed языках и средах. Попытки неоднократные были и в Java и в C# — не взлетело ни разу.

S>Почему нельзя? Можно, только железо нужно соответствующее.

Ну вот тебя самого ничего в твоей фразе не цепляет?

Смотри: имеем сейчас native имплементации HTML/CSS которые работают на существующем железе. Но вот для C# (Java, whatever) имплементации HTML/CSS нужно железо в разы (а во сколько раз кстати?) лучше.

Выводы сделаешь сам?

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Здравствуйте, Cyberax, Вы писали:

C>>На WinCE были ёмкостные экраны и альтернативные оболочки. Ничего фундаментального не мешало их допилить

НС>Не мешало. Но не допилили же.

Не допилили потому что вместо условно "сделать iphone" на том что есть была поставлена задача "счастья всем и бесплатно". Совершенно не удивителен следуюший шаг: Bill Gates: "Only Socialism Can Save the Climate" (что в общем-то правда наверное, но это отдельная тема).

НС>А сторонние навески все равно как дырявый мешок с котом, да и тормозили дай боже.

Тормозили от того что не было GPU графики поддержанной OS. GDI как не поддерживал alpha blending и antialiasing так и не поддерживает. А делать fullscreen rasterization на тех CPU — никаких ресурсов не хватит.
Но даже в тех условиях мой HTMLayout на WinCE работал вполне достойно.


Вот был у меня такой WinCE девайс:


Вполне себе прорыв по тем временам.

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

V> Помимо того, что это извечная дыра в безопасности
Дыра в безопасности зависит от ошибок в коде а не от бинарности.

V> это, считай, бесконечная по весу гиря на ногах производителей процессоров.
Чота как та производители нифига не опечалены этим фактом.

V> Это тот самый технологический тупик, который всех нас зажал в узкие рамки на ближайшие несколько десятилетий. В общей, вот этот груз "легаси-совместимости" на данном этапе невозможно никак перепрыгнуть. Это полная ж-па как она есть, сорри за обилие эпитетов. ))
Мда, куча эмоций а толком ничего и не сказано.
Задайся лучше вопросом почему никто не заморочился идеей перекомпиляции. По сути что P-code что машинный — один фиг, описание что надо сделать в итоге. Может потому что отличия не только в инструкциях?
Чтобы получить максимум производительности на другой архитектуре надо писать логику, которая будет использовать преимущества этой архитектуры.

V>В общем, идея относительно высокоуровневого байт-кода, снабжённым типизированным описанием, куда как более мощная ввиду заложенной в неё потенциально бесконечной гибкости.
Дада, такая гибкая что на ногах еле стоит.
Между "гибким" байт кодом и негибким native я предпочту тот апп что написан под native.

V>Прямо на конкретной железке из него при инсталляции можно генерить максимально-эффективный для данной конфигурации низкоуровневый код.
Это в теории. На практике же выясняется что ещё на этапе проектирования софта происходит заточка под определённые структуры данных, cache line, alignment, подбираются алгоритмы под pipeline и прочия и прочия.
Вот куда не плюнь, а максимально эффективный код как то всё больше ICC генерит а не всякие там ngen.

V>Сама идея сулила и продолжает сулить целую россыпь бенефитов.
Угу, в стиле: видит око да зуб неймёт. Сколько лет прошло а идея всё никак не реализует свой потенциал.
Сколько было крику про run anywhere но реальность внесла коррективы.

V> И как раз в первую очередь в плане загружаемых "на лету" по-настоящему переносимых и безопасных приложений (и/или их частей), что должно было стать стандартом де-факто работы гипотетического "современного компьютера".
Надеюсь никогда не станет. Ибо до сих пор где правильный кошерный бинарь: мало ест и работает быстро. Где байт-код — тормоза и пожирание памяти.
Какая самая большая проблема в тех же браузерах? Правильно, Javascript.

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

lpd>>Можно подробнее, в чем принципиальные преимущества байт-кода?
V>В его абстракции и строгой типизированности.
Нельзя ли поконкретнее? Потому что эта фраза "абстрактна и как то типизирована" но смысла несёт маловато.
Как эти баззворды транслируются в то, что надо конечному юзеру? Производительность, low energy consumption например?

lpd>>Проблемы безопасности можно устранить и без байт-кода
V>Угу, но только за счёт внешней инфраструктуры. Т.е. получая приложения исключительно из т.н. "доверенных источников". Называя вещи своими именами — кормя при этом дармоедов — содержателей таких магазинов приложений.
Т.е. ты считаешь что на байт-коде нельзя написать трояна или следящее за тобой приложение?

V>Собсно, вот этот заповедник дикой природы под название Linux пока еще жив ровно по этой причине
Он жив исключительно на life support от крупных компаний, которые его поддерживают для использования в своих целях.

V>из-за полной свободы.
А где свобода то? И накой она юзеру?

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

CC>>CISC то тут каким боком?
K>Аналогичное явление в другой области.
K>Абстрактное мышление и прочая математика как раз и начинаются с того, что ты видишь похожее в разном.

Parser error: logicless expression detected.

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

CC>>CISC то тут каким боком?
O>Таким, что еслиб не нужно было прятать сырцы, то не надо было бы поддерживать x86 и вероятно изобретать такие технологии обфускации исходного кода как .NET и Java.

Обфускация? Необходимость прятать сурсы?
Поднимите руки кто всерьёз писал на ассемблере.
Потому что как то с пониманием что как и почему происходит на низком уровне устроено у вас какое то странное.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Клиенты RDP есть под все приличные платформы, включая красноглазую и голубую.
Клиентов бесплатных полным полно везде, подтверждаю.

Здравствуйте, Ночной Смотрящий, Вы писали:

CC>>Можно быстро слабать UI но вот пользоваться им будет кошмарно неудобно.
НС>Во-первых не факт что на JS даже со всем хипстер-гавном типа ангуляра выдет быстрее

Ещё раз. Я не про скорость лабания или выдавания. Я про дизайн.
Можно сделать чтобы пользоваться было удобно а можно сделать вырвиглазно, когда хочется поймать автора и ещё раз переломать ему руки, чтоб таки в этот раз они срослись правильно.