Т.е. вот, если смотреть на шаг вперед, предположим, появились более дешевые нетбуки с сетевой Chrome ОС.
Из соображений конкуренции у МС появилась своя сборка Windows CE сразу после загрузки запускающая браузер Gazelle.
Debian и Ubuntu поставили еще на некоторый процент нетбуков.
Ожила конкуренция на рынке ОС.
Юзерам стало еще проще сделать в вебе то, для чего раньше надо было скачивать и ставить программу.
И - как и было предсказано, все стали искать сервисы, заменящие им софт.
Но сервисы тормозят. Медленно работают видеоредакторы, бухгалтерия, электронные таблицы, компиляторы.
Вы пробовали фотку отредактировать веб-редакторе? Или он-лайн 3D-планировщиком воспользоваться для создания модели квартиры?
И будут тормозить, потому, что нужен быстрый и оптимизированный х86-код.
Как именно может работать x86-код в сетевых сервисах?
1. Можно попытаться все посчитать в облаке и прислать результат клиенту. Лично я пробовала конвертеры с ю-тубы, конвертирующие видео по ссылке с ютуба у себя на серверах и выдающие на скачку результирующий файл. Это тоже долго.
В чем там дело не совсем ясно, но реально быстрых вычислений в облаке тоже видимо придется подождать еще. Наверное уже все технически можно, просто дорого получается.
К тому же, и производителям софта дорого и долго переделывать свой софт под облачные вычисления.
2. Предположим, из браузера стало доступно выполнение x86-кода прямо со странички. Google уже делал Native API для браузеров. Такие сетевые сервисы стали бы работать быстро. (и загружать свой код или его апдейты юзеру при заходе на сайт один раз)
Тогда можно работать в браузере, как будто в реальном приложении.
Компании-производители софта относительно быстро могут переделать свой С++ софт под сетевые сервисы (не то, что под облачные вычисления).
Однако, в этом случае, также станет возможным получть синий экран прямо зайдя на сайт. Или отформатировать диск C: попав на зараженный хост.
То есть, доступность сетевых сервисов также сделает более уязвимым клиента.
Собственно, оба эти пути не способствуют быстрому и легкому появлению сетевых сервисов для сетевых ОС. В этом случае новая ОС может остаться просто интересным решением для тех, кому "Google Docs и GMail хватает".
9 комментариев:
Реально не всё так плохо со скоростью работы кода на клиенте, особенно в хроме. Хром (как и другие современные браузеры) это очень неплохая альтернатива фреймворкам типа java/.Net. Есть доступ к настольным базам данных, есть к коммуникациям (пока только по HTTP, но впереди светят и WebSockets). Есть 2D графика в виде Canvas. Ну а JavaScript на V8 по скорости работы уже оставил далеко позади таких старых монстров как Python. Если учесть что его роль - не числодробление, не просчёт растровой и векторной графики а просто "склеивание" всех компонентов вместе то ИМХО его производительности будет за глаза хватать для создания вполне шустрых приложений.
мне новость про Chrome OS напомнила статью об Emacs на Dobbs Code Talk. Там есть такая фраза:
EMACS later ('84?) added such nicities as a command line interpreter,
an email reader, and a newsgroup reader. I would log into a machine,
start up EMACS, and never leave it! Everything was so easy! And the
scripting language was Lisp! It was a cinch to do anything at all.
A number of my EMACS modes and commands are still in use today.
Т.е. подобное уже было сделано, следовательно это можно как минимум повторить.
To Left: со скоростью нормально, я сама пользуюсь Google Docs в Chrome.. но, все на интерпретаторы не переведешь.
вот и хотелось бы предугадать дальнейшее развитие возможности вычислять в сетевых приложениях :)
Скажем так, нынче грань между интерпретатором и компилятором ну очень узка. К примеру, какJavaScript так и Java/C# выполняют JIT-компиляцию для байткода (а выполняется уже нативный для данной системы код) . Единственная разница - у Java/C# этот байткод генерится в отдельной фазе (компиляции) которая по времени разнесена с исполнением. Но реально эта фаза не так уж критична по времени. Так что конечно .Net/Java JS вряд ли когда догонит, но дойти до состояния когда будет проигрывать по скорости меньше порядка - ИМХО вполне реально. Но самое главное даже не это. Главное что с развитием инфраструктуры на стороне браузера всё меньше остаётся задач где производительность JS реально критична. ИМХО как раз всё идёт к тому чтобы перевести всё на интерпретаторы :)
Светлана, вашему дерзкому полёту мысли мешает жёсткая привязка к Windows и X86 платформе Wintel. Смотрите на вещи шире и жить станет намного веселее :-)
Из соображений конкуренции у МС появилась своя сборка Windows CE сразу после загрузки запускающая браузер Gazelle.
Далеко не сразу и намноооого менее стабильная и быстрая, чем та же Ubuntu. И где "сразу" появятся приложения!? Репозитории armel у Debian и Ubuntu уже есть, а где всё это у Майкрософт!? Без тени иронии - мне просто интересно.
Debian и Ubuntu поставили еще на некоторый процент нетбуков.
Начнём с того, что Ubuntu УЖЕ предустановлена на ряд нетбуков. По своему Toshiba NB100 могу сказать: убунта там смотрелась очень хорошо и работала отлично. Желание поставить Дебиан было скорее из привычки.
Ожила конкуренция на рынке ОС.
Не так: Майкрософт стала чуть меньше бессовестно давить конкурентов. Но это лирика.
Но сервисы тормозят.
Вы неправы. Они работают весьма быстро и хорошо. Особенно гугловские сервисы. Google Docs меня впечатляют.
Медленно работают видеоредакторы, бухгалтерия, электронные таблицы, компиляторы.
Ну вы, конечно, дали стране угля! :-) Это зачем же мне загружать гигабайтный видеоролик в Сеть!? А попытка сделать это с бухгалтерией просто чудовищна: это не то, что можно делать достоянием общественности :-)
Вы пробовали фотку отредактировать веб-редакторе?
А это надо? Не стоит всё тащить в веб. Что-то должно остаться и на местах.
Однако, в этом случае, также станет возможным получть синий экран прямо зайдя на сайт. Или отформатировать диск C: попав на зараженный хост.
Диски ЦЭ есть не у всех; это проблема ОС, которые провоцируют бардак и не приучают к разделению прав и привилегий.
Я позволю себе немного помечтать в другом направлении.
Вот у гугла есть такой сервис, который позволяет читать отсканированные книги, в которых можно искать по словам, но которые нельзя скачать на локальную машину.
Такой современный вариант библиотеки - мне кажется, что у этого сервиса намного больший потенциал, чем кажется.
To Left: Смутно представляю себе обработку мультимедиа или игровой движок на интерпретаторах в ближайшие года 3.
To Virens: Вы не поняли.
Загружать видеоролик или бухгалтерию в сеть не придется и при этом с ними можно будет работать прямо в браузере.
Это как раз второй вариант развития событий - Native x86 Client.
Интерпретатор - это не приговор, если у нас есть возможность дописывать к нему нативный код. Возьмём, к примеру, обработку мультимедиа. Естественно, если обработка каждого пиксела изображения в HDTV потоке будет делаться скриптом, то о FPS > 1 можно только мечтать. Но легко можно дать возможность из скрипта создавать микропрограммы для GPU или DSP. Точно так же как в современных играх 3D-эффекты не пишутся на С++ - они пишутся на языке который заточен под GPU, задача С++ кода - только залить его в GPU и дёрнуть его на исполнение.
To Left: B опять приходим к варианту 2 - возможности выполнять нативный код (и GPU-код в т.ч.) на клиенте.
Непонятно только, чем этот вариант будет отличаться от создания браузера с хорошо задокументрованной и легкой в эксплуатации уязвимостью? ;-)
А кто вообще сказал, что гугловцы начнут делать все на интерпретаторах. Они же в конце концов не дураки. В частности думаю, что google docs может легко стать десктопным приложением. Да и вообще полагаю, что привычная нам всем граница desctop/web размоется окончательно. Примеры уже есть: Wow, Google Earth. То будут совсем другие времена.
Отправить комментарий