[LC] Браузер Google Chrome будет использовать возможности графических чипов

[t.t]

И вообще ИМХО перенос всего и вся в веб тоже бред.

это почему? за вебом и гридами будущее

Откровенно говоря, Ваше «будущее» ничуть не более аргументировано, чем его «бред».

[Voral]

это почему? за вебом и гридами будущее

Угу и тогда сегодняшние бандиты и алигархи будут жалкими детьми по сравнению с хакерами (в СМИшном онимании), а игла МС покажется витаминкой Це по сравнению с деятельностью провйадеров....

Естественно это чисто ИМХО. И что объемы использования интернет будут только расти это верно....Но вот, что у нас остануться только терминалы.... мне б не хотелось.....

А небо ночью будет светиться от объемов передаваемой безпроводными путями информации...

[mix1m]

И вообще ИМХО перенос всего и вся в веб тоже бред.

это почему? за вебом и гридами будущее

Откровенно говоря, Ваше «будущее» ничуть не более аргументировано, чем его «бред».

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

[t.t]

И вообще ИМХО перенос всего и вся в веб тоже бред.

это почему? за вебом и гридами будущее

Откровенно говоря, Ваше «будущее» ничуть не более аргументировано, чем его «бред».

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

Тогда следует сделать одно уточнение: будущее для кого? Если для бизнеса, то вопросов больше не имею.

[frp]

это почему?

[ИМХО]
Возьмем например тот же Quake Live.
Недочеты связанные с веб:
1. Нужно ставить плагин для броузера.
Это неудобно. Кроме того, это требует от пользователя установки поддерживаемого броузера (вроде поддерживаются все, которые поддерживают плагины Netscape). Возникают проблемы с поддержкой (очень сложно поддержать зоопарк слабо совместимых между собой броузеров (сомневаюсь, что можно получить какую-либо техническую поддержку в случае использования броузера, отличного от IE, Opera, Firefox)).
[paranoid mode] Также это лишняя дыра в безопасности броузера. [/pananoid mode]
Ни одного из этих недостатков не может иметь обычное десктопное приложение.
2. [субъективно] С медленным интернетом (да и с быстрым иногда тоже) веб-приложения очень долго открываются. [/субъективно]. Это конечно зависит от того, какие веб-приложения, но к Quake Live (а также гугло-приложениям, RoundCube, MS Office Live, iCloud, приложения ВКонтакте и Facebook, TopCoder) это относится.
Преимуществ от веб в случае Quake Live не вижу.
Сферическое веб-приложение в вакууме, не требующее плагинов для броузера:
Недочеты связанные с веб:
1. Невозможность быстрой отрисовки интерфейса.
2. Ограниченность возможностей по созданию интерфейса.
3. Медленность JavaScript.
4. Не конфиденциально (о том, для чего вы используете приложение, знает как минимум сервер, на котором оно размещено, а в случае незащищенности соединения - все желающие).
5. Аргумент 2 от Quake Live
6. Несовместимость броузеров вызывает кучу проблем (особенно если нужно, чтобы долбанный IE 6 тоже работал).
Преимущества:
1. Возможность использовать с любого компьютера.
2. Сохранение информации на сервере, что устраняет проблему совместного доступа и т.д. и т.п.
3. За все операции администрирования, обновления, поддержки отвечает не пользователь, а админ сервера (хотя в некоторых случаях (Git+Trac+Sourceforge в пример) это создает проблемы пользователю, поэтому преимущество спорное).

за вебом и гридами будущее

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

Ага, и еще забыл упомянуть - веб приложения это тоже SaaS и он имеет все перечисленные когда-то Столлманом недостатки.

[watashiwa_daredeska]

1. Нужно ставить плагин для броузера.

Google Native Client. Плагин один раз и неограниченное использование приложений. Как с Flash.

2. [субъективно] С медленным интернетом (да и с быстрым иногда тоже) веб-приложения очень долго открываются. [/субъективно]. Это конечно зависит от того, какие веб-приложения, но к Quake Live (а также гугло-приложениям, RoundCube, MS Office Live, iCloud, приложения ВКонтакте и Facebook, TopCoder) это относится.

При правильном подходе к кешированию это должно пройти. А при переходе на преимущественно веб-приложения подход к кешированию должен улучшиться. Размер кеша по умолчанию должен стать не 50MB, как сейчас, а 5GB (чтобы было сравнимо с размером корневого раздела системы, куда ставится система и софт).

1. Невозможность быстрой отрисовки интерфейса.
3. Медленность JavaScript.

NaCl, упоминавшийся выше, эту проблему решает.

2. Ограниченность возможностей по созданию интерфейса.

Скорее, не интерфейса, а интеграции в существующие десктопные системы. Будет веб-ориентированная десктопная система, в которой специфицированы соответствующие API.

4. Не конфиденциально (о том, для чего вы используете приложение, знает как минимум сервер, на котором оно размещено, а в случае незащищенности соединения - все желающие).

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

6. Несовместимость броузеров вызывает кучу проблем (особенно если нужно, чтобы долбанный IE 6 тоже работал).

Это проблемы разработчиков, а не пользователей. В простейшем случае, ограничат спектр платформ, хотя бы на первом этапе. Точно также, как сейчас раздельно запускают версии ПО для Win/Lin/Mac.

Ага, и еще забыл упомянуть - веб приложения это тоже SaaS

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

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

Деньги — достаточно серьезная причина :)

[/dev/random]

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

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

[Bluetooth]

Ага, и еще забыл упомянуть - веб приложения это тоже SaaS

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

Честно говоря, меня больше интересует терминал, чем веб пародия на терминал

Деньги — достаточно серьезная причина

Разумеется. Но тут явно имелась ввиду техническая причина. (:

Ага, и еще забыл упомянуть - веб приложения это тоже SaaS и он имеет все перечисленные когда-то Столлманом недостатки.

А это какие? Ссылочку можно?

[/dev/random]

А это какие? Ссылочку можно?

http://www.gnu.org/philosophy/who-does-tha...ally-serve.html

[mix1m]

Деньги — достаточно серьезная причина

Разумеется. Но тут явно имелась ввиду техническая причина. (:

ну что такое "техническая причина"? В большинстве своем, технические причины сводятся к деньгам

Тогда следует сделать одно уточнение: будущее для кого? Если для бизнеса, то вопросов больше не имею.

мне кажется, что любое успешное бизнес-решение, которое можно хоть как-то впарить массам - обязательно впарится=)
Так вот и вижу какое-нить объявление в каком-нить вконтакте: "Пожертвуй нам часть своего процессорного времени и получи.. (не знаю.. что-нить получи=))"

[watashiwa_daredeska]

провайдер приложения получает их в открытом виде.

В открытом виде их получает код на клиенте. Провайдер приложения их не получает.

Конечно, теоретически, он не должен их у себя хранить. Но это он так утверждает. И верить ему на слово оснований нет.

Он их вообще не должен получать. Если он их получает, то это уже spyware, а с этим проблемы есть и сейчас. MS и других проприетарщиков несколько раз ловили за руку за отсылкой персональной информации о пользователе куда не надо.

[t.t]

Тогда следует сделать одно уточнение: будущее для кого? Если для бизнеса, то вопросов больше не имею.

мне кажется, что любое успешное бизнес-решение, которое можно хоть как-то впарить массам - обязательно впарится=)

Согласен. Но это проблемы масс. А быть ли частью массы — личный выбор каждого.

Конечно, теоретически, он не должен их у себя хранить. Но это он так утверждает. И верить ему на слово оснований нет.

Он их вообще не должен получать. Если он их получает, то это уже spyware, а с этим проблемы есть и сейчас. MS и других проприетарщиков несколько раз ловили за руку за отсылкой персональной информации о пользователе куда не надо.

Так о том и речь, что SaaS в этом смысле ничем не лучше проприетащины.

[Bluetooth]

Деньги — достаточно серьезная причина

Разумеется. Но тут явно имелась ввиду техническая причина. (:

ну что такое "техническая причина"? В большинстве своем, технические причины сводятся к деньгам

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

мне кажется, что любое успешное бизнес-решение, которое можно хоть как-то впарить массам - обязательно впарится=)

Конечно. Главное, чтобы нашлись люди, которым будет интересно это впаривать.

[t.t]

мне кажется, что любое успешное бизнес-решение, которое можно хоть как-то впарить массам - обязательно впарится=)

Конечно. Главное, чтобы нашлись люди, которым будет интересно это впаривать.

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

[Bluetooth]

мне кажется, что любое успешное бизнес-решение, которое можно хоть как-то впарить массам - обязательно впарится=)

Конечно. Главное, чтобы нашлись люди, которым будет интересно это впаривать.

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

Да, в большинстве случаев все именно так

[watashiwa_daredeska]

Так о том и речь, что SaaS в этом смысле ничем не лучше проприетащины.

Погоди, Тихон, я не понимаю. Я как раз говорю, что нифига подобного. Эти вещи вообще в разных плоскостях лежат. Вполне можно SaaS'ить СПО точно также, как и проприетарщину.

[deadhead]

Эти вещи вообще в разных плоскостях лежат. Вполне можно SaaS'ить СПО точно также, как и проприетарщину.

Есть и другое мнение ;-)

[frp]

Он их вообще не должен получать.

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

[t.t]

Так о том и речь, что SaaS в этом смысле ничем не лучше проприетащины.

Погоди, Тихон, я не понимаю. Я как раз говорю, что нифига подобного. Эти вещи вообще в разных плоскостях лежат. Вполне можно SaaS'ить СПО точно также, как и проприетарщину.

А с какой стати к публичному серверу SaaS, который говорит, что использует только свободное ПО, должно быть больше доверия, чем к разработчику проприетарщины, говорящему, что у него нет закладок?

[watashiwa_daredeska]

Мне в голову приходит только одна идея - шифровать в JavaScript-скрипте на стороне клиента, но это очень даже не труЪ.

Да, на стороне клиента. Но почему обязательно в Javascript?

А с какой стати к публичному серверу SaaS, который говорит, что использует только свободное ПО, должно быть больше доверия, чем к разработчику проприетарщины, говорящему, что у него нет закладок?

Не обязательно использовать только СПО. Главное, чтобы ПО, отдаваемое пользователю было свободным. Это может быть проверяемо и электронно подписываемо, причем не только SaaS-провайдером.

[frp]

Да, на стороне клиента. Но почему обязательно в Javascript?

Есть кроссплатформенные кроссбразерные альтернативы (ActionScript для Flash-приложений ничем не лучше)?

Главное, чтобы ПО, отдаваемое пользователю было свободным.

Плюсов от этого немного. Хоть и клиентская часть свободная, это нам ничего не говорит о том, что из себя представляет серверная часть.

[Bluetooth]

Так о том и речь, что SaaS в этом смысле ничем не лучше проприетащины.

Погоди, Тихон, я не понимаю. Я как раз говорю, что нифига подобного. Эти вещи вообще в разных плоскостях лежат. Вполне можно SaaS'ить СПО точно также, как и проприетарщину.

А с какой стати к публичному серверу SaaS, который говорит, что использует только свободное ПО, должно быть больше доверия, чем к разработчику проприетарщины, говорящему, что у него нет закладок?

А к чему не развернуть свой SaaS сервер на свободном ПО? Публичные сервисы вообще не могут вызывать доверия. Впрочем, если никому не доверять, то можно вообще сразу закопаться в землю.

Главное, чтобы ПО, отдаваемое пользователю было свободным. Это может быть проверяемо и электронно подписываемо, причем не только SaaS-провайдером.

ДЕйствительно, может. Но будет ли?

Да, на стороне клиента.

А я плохо представляю, как будет работать приложение с пользовательскими данными, если оно не сможет их расшифровать? Или прямо с шифрованными работать?

Плюсов от этого немного. Хоть и клиентская часть свободная, это нам ничего не говорит о том, что из себя представляет серверная часть.

Думаю, имелась ввиду и серверная, и клиентская часть.

[watashiwa_daredeska]

Есть кроссплатформенные кроссбразерные альтернативы (ActionScript для Flash-приложений ничем не лучше)?

Google Native Client, упомянутый выше. Идут работы по загрузке в него LLVM-кода, а не нативного.

Хоть и клиентская часть свободная, это нам ничего не говорит о том, что из себя представляет серверная часть.

А серверная часть — дело провайдера, по большому счёту. Диск со свободным Debian не станет менее свободным, если куплен в магазине, использующем проприетарную 1С.

ДЕйствительно, может. Но будет ли?

Как говорится, карты в руки, делайте, чтобы было :)

[t.t]

Всё-таки я не совсем понимаю. Если нешифрованные данные существуют только на стороне клиента, это означает, что и ПО, работающее с этими данными, должно запускаться на стороне клиента. Это очень хорошо и правильно, только непонятно, при чём здесь SaaS. (:

[mix1m]

Да, на стороне клиента. Но почему обязательно в Javascript?

Есть кроссплатформенные кроссбразерные альтернативы (ActionScript для Flash-приложений ничем не лучше)?

есть апплеты еще)

А я плохо представляю, как будет работать приложение с пользовательскими данными, если оно не сможет их расшифровать? Или прямо с шифрованными работать?

приложению пользовательские данные "непосредственно" не нужны (если это не построение отчетов на сервере или че-нить подобное).

[t.t]

А я плохо представляю, как будет работать приложение с пользовательскими данными, если оно не сможет их расшифровать? Или прямо с шифрованными работать?

приложению пользовательские данные "непосредственно" не нужны (если это не построение отчетов на сервере или че-нить подобное).

Простите, а кому они вообще тогда нужны?

[mix1m]

А я плохо представляю, как будет работать приложение с пользовательскими данными, если оно не сможет их расшифровать? Или прямо с шифрованными работать?

приложению пользовательские данные "непосредственно" не нужны (если это не построение отчетов на сервере или че-нить подобное).

Простите, а кому они вообще тогда нужны?

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

[t.t]

А к чему не развернуть свой SaaS сервер на свободном ПО? Публичные сервисы вообще не могут вызывать доверия.

На своём сервере у меня ssh есть. Я не понимаю, зачем мне там какой-то SaaS.

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

См. мой вопрос парой постов выше: если расшифровка данных, а соответственно и работа с ними, происходит на стороне клиента, то при чём здесь вообще сервер?

[Bluetooth]

А я плохо представляю, как будет работать приложение с пользовательскими данными, если оно не сможет их расшифровать? Или прямо с шифрованными работать?

приложению пользовательские данные "непосредственно" не нужны (если это не построение отчетов на сервере или че-нить подобное).

Простите, а кому они вообще тогда нужны?

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

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

На своём сервере у меня ssh есть. Я не понимаю, зачем мне там какой-то SaaS.

Ну, типа "удобно" Мне-то тоже не нужен. Но это мне.

[t.t]

На своём сервере у меня ssh есть. Я не понимаю, зачем мне там какой-то SaaS.

Ну, типа "удобно" Мне-то тоже не нужен. Но это мне.

Я о том и говорю, что это больше похоже на очередную «хавку» для «пипла», чем на что-то действительно стоящее.