Праздник у RMS
а просвятите меня, кто такой RMS? какой-то препод с вмика?
З.Ы. копирастеры скоро вообще нас загонят в OnLive/ChromeOs, или что-то подобное. Там нашим вообще только монитор будет на котором изображение отображается.
З.З.Ы. вообще конечно для пользователя это удобнее, потому такой подход и победит, !но! цена такого удобства - всё более и более тесный опускающийся на нас колпак.
З.Ы. копирастеры скоро вообще нас загонят в OnLive/ChromeOs, или что-то подобное. Там нашим вообще только монитор будет на котором изображение отображается.
З.З.Ы. вообще конечно для пользователя это удобнее, потому такой подход и победит, !но! цена такого удобства - всё более и более тесный опускающийся на нас колпак.
а просвятите меня, кто такой RMS? какой-то препод с вмика?Не, на вмике он всего одну лекцию прочитал.
Столлмен это.
http://stallman.org/
http://stallman.org/
а просвятите меня, кто такой RMS? какой-то препод с вмика?Гугл отменили? На первой странице есть персональная страница только одного человека. Остальное - аббревиатуры организаций и тому подобного.
Хотя на ВМК он однажды читал лекцию.
вообще конечно для пользователя это удобнее, потому такой подход и победитНапротив, это неудобно, так как у веб-приложений, выполняющихся в песочнице есть принципеальные ограничения по интерграции с системой и с другими приложениями.
Назови хоть один принципеальный момент, по которому полная замена десктопных приложений на веб-приложения была бы удобнее.
RMS = Root Mean Square, и каким боком тут этот мужик я совершенно не вдупляю.
Назови хоть один принципеальный момент, по которому полная замена десктопных приложений на веб-приложения была бы удобнее.1. На слабом железе (типа ARM-планшетов, жрущих мало энергии) можно получить приложения, требующие высокой производительности. Например, эффективное распознавание речи.
2. Данные могут быть существенно сохраннее на сервере с бесперебойным питанием, резервным копированием и так далее.
3. Совместная работа может быть проще реализована, хотя это слабый аргумент.
Понятно, что к этому всему прилагается пачка минусов, но всё же.
Самый простой плюс — что меньше надо думать, ввел один пароль, а комп сам вспомнил все настройки, приложения и все такое.
Назови хоть один принципеальный момент, по которому полная замена десктопных приложений на веб-приложения была бы удобнее.RDP.
И можно без браузера.
Всё равно уже сейчас куча такого барахла как дропбокс, синхронизация закладок, гуглдокс, почта и всякие прочие хранятся не у тебя. Тебе надо на любом компе в сети только залогинится, и всё - вот оно. Удобно же! В итоге всё просто объединится, чтобы логин только один раз вводить, и ежемесячно отлистывать хрустов.
просвятите
Вот, меня уже опередили насчёт одного пароля.
По первой ссылке какая-то восторженная статья по поводу новой возможности отдаться в анальное рабство, но по-сути ничего нет.
Я не понимаю как такое может работать. Вторая технология в общем случае здесь не к месту, поскольку далеко не всегда для доступа в сеть используется Wi-Fi, а если и используется, то чаще всего зашифрованная и чёрному ящику из процессора с wi-fi модулем в большинстве случаев не удастся самостоятельно выйти в сеть.
Значит cpu вынужден будет использовать ресурсы ОС для общения с сервером. А ОС не позволит прикладному ПО (браузеру) взаимодействовать напрямую с процессором. В свою очередь, браузер не позволит веб-приложению взаимодействовать напрямую с ОС.
Я не понимаю как такое может работать. Вторая технология в общем случае здесь не к месту, поскольку далеко не всегда для доступа в сеть используется Wi-Fi, а если и используется, то чаще всего зашифрованная и чёрному ящику из процессора с wi-fi модулем в большинстве случаев не удастся самостоятельно выйти в сеть.
Значит cpu вынужден будет использовать ресурсы ОС для общения с сервером. А ОС не позволит прикладному ПО (браузеру) взаимодействовать напрямую с процессором. В свою очередь, браузер не позволит веб-приложению взаимодействовать напрямую с ОС.
Иди к Педечке.
З.Ы. 30-50 лет назад компы были уделом людей в халатах...
З.Ы. 30-50 лет назад компы были уделом людей в халатах...
В свою очередь, браузер не позволит веб-приложению взаимодействовать напрямую с ОС.Это звучит логично. Но маркетологи обещали, что достаточно будет браузера, а низлежащая ось необязательна, а они знают свой продукт по идее лучше тебя. Значит есть такая возможность
Назови хоть один принципеальный момент, по которому полная замена десктопных приложений на веб-приложения была бы удобнее.физическая сохранность данных, актуальность данных - всё остальное можно сделать и локально, в том числе, и наличие единого логина.
Это возможно и без замены настольных приложений их веб-аналогами. См., например, как работает iOS App Store, там можно и полные резервные копии в iCloud кидать, однако все приложения исполняются локально при этом.
Не удивлюсь, если Mac OS X обзаведётся такой же фичей — Time Machine в облако (правда, объёмы данных там на полтора-два порядка больше, и вряд ли это появится прямо сейчас, но технически это возможно).
Не удивлюсь, если Mac OS X обзаведётся такой же фичей — Time Machine в облако (правда, объёмы данных там на полтора-два порядка больше, и вряд ли это появится прямо сейчас, но технически это возможно).
1. На слабом железе (типа ARM-планшетов, жрущих мало энергии) можно получить приложения, требующие высокой производительности. Например, эффективное распознавание речи.Не понял с чего это приложение в браузере будет работать быстрее нативного?
2. Данные могут быть существенно сохраннее на сервере с бесперебойным питанием, резервным копированием и так далее.Не вижу принципеальных проблем организовать централизованное хренение и автоматическую синхронизацию пользовательских данных и настроек на сервере для десктопных приложений.
3. Совместная работа может быть проще реализована, хотя это слабый аргумент.
Значит cpu вынужден будет использовать ресурсы ОС для общения с сервером. А ОС не позволит прикладному ПО (браузеру) взаимодействовать напрямую с процессором. В свою очередь, браузер не позволит веб-приложению взаимодействовать напрямую с ОС.принципиальных проблем это не создает
это стандартная проблема - наличие "человека по середине", и она имеет стандартное решение поднять секьюрный-канал(SSL или аналог) между веб-приложением и цпу, между веб-приложением и сервером, между цпу и сервером.
Всё равно уже сейчас куча такого барахла как дропбокс, синхронизация закладок, гуглдокс, почта и всякие прочие хранятся не у тебя. Тебе надо на любом компе в сети только залогинится, и всё - вот оно. Удобно же! В итоге всё просто объединится, чтобы логин только один раз вводить, и ежемесячно отлистывать хрустов.Я просил принципеальные моменты. Это всё возможно реализовать в декстопных приложениях.
Не вижу принципеальных проблем организовать централизованное хренение и автоматическую синхронизацию пользовательских данных и настроек на сервере для десктопных приложений.и чем это будет отличаться от веб-приложений? только тем, что в одном случае есть доп. стандартная прослойка (браузер а в другом нет?
Не вижу принципеальных проблем организовать централизованное хренение и автоматическую синхронизацию пользовательских данных и настроек на сервере для десктопных приложений.Вообще тот же RMS давно говорил, что синхронизация данных - это удобно и хорошо. Он не понимал другого, почему для этого процесса необходим гугль или другой большой брат. Ведь можно же написать открытый серверный софт (для некоторых протоколов уже открыто залить его на собственный сервак и работать уже с ним.
Я думаю, в конце концов всё к этому и придёт. Сначала казалось, что альтерантивы виндовсу нет, но виндовс перестал развиваться, а линукс растёт, и получает всё большую долю рынка. И всем стало понятно, что закрыть рынок десктопов невозможно.
Теперь вот пришёл гугль, он вовсю сотрудничает с открытым десктопом, но закрывает веб, собирая все данные вокруг себя. Сейчас вот кажется, что альтернативы гуглу (не как поисковику, а как почтовику) нет. Однако гугл уже прошёл стадию развития и перешёл к стадии окучивания пользователей и значит скоро открытые альтернативы будут догонять. Тот же ютуб сейчас фактически держится только на юристах
Сротишка такой сротишка.
Это звучит логично. Но маркетологи обещали, что достаточно будет браузера, а низлежащая ось необязательна, а они знают свой продукт по идее лучше тебя. Значит есть такая возможностьТо есть кроме обещаний маркетологов про этот продукт сейчас больше ничего не известно?
Тогда я чувстувую, это будет реализовано в виде плагина в браузер + драйвера в ОС, которые пользователю придётся поставить, чтобы пользоваться сервисом.
Маркетологи говорили что-нибудь про кроссплатформенность? Просто сказали, что нужен будет только браузер? Видимо, они имели в виду, что запускать придётся только браузер, а не то, что не будет на компе дополнительного софта, который, например, в случае ноутов будет просто предустановлен вместе с виндой. Это ж маркетологи.
Не понял с чего это приложение в браузере будет работать быстрее нативного?Я попутал веб-приложения и облачные, надо думать.
В качестве примера см. OnLive. Ну да, там желателен, наверное, какой-то локальный клиент, но он нужен только для того, чтобы передавать данные и показывать видео с сервера, а всё 3D создаётся сервером с мощным железом, так что браузер ничем не хуже.
Сначала казалось, что альтерантивы виндовсу нет, но виндовс перестал развиваться, а линукс растёт, и получает всё большую долю рынка.Можешь поделиться более-менее адекватными подсчётами процента пользователей различных ОС за последние несколько лет? Или хотя бы на текущий момент.
и чем это будет отличаться от веб-приложений? только тем, что в одном случае есть доп. стандартная прослойка (браузер а в другом нет?прослойка отнюдь не стандартна и ужасно не подходит для реализации приложений не информационого характера. Вот скажем, когда ты мне покажешь 3d редактор уровня макса, майи или блендера, тогда поверю. Учти, что он должен умно работать с несколькими мониторами, трёхмерными мышами, перьями. Хранить 40 гиговые сцены частично в памяти, частично сбрасывая в собственный файл подкачки, интегрироваться с двумерным редактором для рисования текстур.
То есть теоретически, всё это можно реализовать на эмуляторе машины тьюринга, но что-то мне кажется ни один программист не назовёт такой выбор средств логичным.
С другой стороны веб может работать как терминал, оставляю всю работу в другом месте, но зачем это принудительное разделение? А если я хочу на одном компьютере всё это получить? И чем тогда веб-терминал будет лучше обычного vnc?
Теперь их процессор ещё и wifi умеет.А АМДшный умеет видео.
Скоро процессор будет такая коробочка, к которой подключается компьютер.
(Хотя для некоторых уже так: http://www.press.bmwgroup.com/pressclub/p/us/pressDetail.html?outputChannelId=9&id=T0124889EN_US&left_menu_item=node__6608)
это стандартная проблема - наличие "человека по середине", и она имеет стандартное решение поднять секьюрный-канал(SSL или аналог) между веб-приложением и цпу, между веб-приложением и сервером, между цпу и сервером.Что это за бред? Между веб-приложением и цпу лежит браузер и ОС. И тот, и другой слой создают песочницу Если бы это ограничение было бы возможно обойти без модификации браузера и ОС, то получить рутовый доступ к любой системе бы означало всего лишь прислать жертве ссылку.
и чем это будет отличаться от веб-приложений? только тем, что в одном случае есть доп. стандартная прослойка (браузер а в другом нет?Тем, что само приложение будет нативным, храниться на компьютере пользователя и интегрироваться с его окружением.
Хотя, более принципеальным отличием было бы, пожалуй, взаимодействие с сервером синхронизации по открытому протоколу + открытое ПО этого самого сервера синхронизации.
В качестве примера см. OnLive. Ну да, там желателен, наверное, какой-то локальный клиент,Ещё есть gaikai, кстати.
Терминалы были изобретены в прошлом веке и отлично работали. И я признаю, что за ними есть ниша. Более того я даже призываю всех пользователей, которые сами не могут настроить компьютер и не хотят учиться, переходить на терминалы. Я не понимаю другое. Почему эта методика, древняя как гавно мамонта, современными макертологами превозносится как новейшая разработка?
В моём представлении об идеальном мире рисуется совсем другая картинка. На каждом компьютере стоит открытый серверный и открытый клиентский софт. Серверный софт, объединяя ресурсы всех доступных пользователю компьютеров, обеспечивает расчёт задач, передавая избыток мощностей платно/бесплатно/на бартерной основе другим пользователям, клиентский софт пользователь использует для получения доступа к своему кластеру или мощностям чужого, шифруя при этом данные, проходящие через третьи руки, плюс он может управлять своими машинами, включать/выключать, устанавливать уровень избыточности хранения данных, уровень энергопотребления и прочее. Необходимость гугла в этом мире сомнительна, он может быть, конечно, полезным массовым провайдером серверных услуг и продавать их клиентам, но по конкурентной а не монопольной цене. Веб протоколы тоже явно займут не самую главную роль, потому что из-за своей убогой основы не могут являться базой для коммуникации кластеров и связи произвольных форм отображения гуя и серверной частью.
> прослойка отнюдь не стандартна и ужасно не подходит для реализации приложений не информационого характера.
тоже самое говорили про наличие ОС 20 лет назад.
зы
вообще, если взять только принципиальные моменты, то:
ОС для пользователя предоставляет стандартизацию доступа к хранимым данным.
консоль предоставляет стандартизацию доступа к выводимым в виде plain-текста данным.
браузер предоставляет стандартизацию доступа к выводимым rich-текстовым данным
тоже самое говорили про наличие ОС 20 лет назад.
Вот скажем, когда ты мне покажешь 3d редактор уровня макса, майи или блендера, тогда поверю. Учти, что он должен умно работать с несколькими мониторами, трёхмерными мышами, перьями.как ты считаешь - это частные временные проблемы? или это системные проблемы присущие такой прослойке как браузер?
зы
вообще, если взять только принципиальные моменты, то:
ОС для пользователя предоставляет стандартизацию доступа к хранимым данным.
консоль предоставляет стандартизацию доступа к выводимым в виде plain-текста данным.
браузер предоставляет стандартизацию доступа к выводимым rich-текстовым данным
Ты о чём вообще? мы - о простых смертных пользователях, типа диззи. А нёрды, программисты, 3д дизайнеры и пр. по-прежнему будут сидеть на монстрах.
или это системные проблемы присущие такой прослойке как браузер?они присущи. Потому что браузер - это даже не виртуальная машина, а набор костылей. Я не сомневаюсь в полезности middleware но недоумеваю, как в этой роле указалось убожище под названием http с протоколом обмена html
Что это за бред? Между веб-приложением и цпу лежит браузер и ОС. И тот, и другой слой создают песочницув общем случае, drm - это тоже песочница. и к drm-данным никто кроме самой песочницы не может получить доступа.
соответственно, я утверждаю, что такую песочницу можно сделать при произвольной ОС если есть поддержка процессора для этого.
RMS = Root Mean Square, и каким боком тут этот мужик я совершенно не вдупляю.контекст. Контекст раздела, контекст темы, контекст предложения. Как RootMeanSquare может бегать и подпрыгивать?
Я не сомневаюсь в полезности middleware но недоумеваю, как в этой роле указалось убожище под названием http с протоколом обмена htmlтут всё упирается в то, что в разнородной быстро-меняющейся среде - эффективными могут быть только текстовые протоколы.
у тебя есть более эффективные текстовые альтернативы для http, html, js?
Я попутал веб-приложения и облачные, надо думать.Понял о чём ты.
В качестве примера см. OnLive. Ну да, там желателен, наверное, какой-то локальный клиент, но он нужен только для того, чтобы передавать данные и показывать видео с сервера, а всё 3D создаётся сервером с мощным железом, так что браузер ничем не хуже.
С точки зрения удобства облачные приложения с тонким клиентом будут проигрывать толстому клиенту из десктопного приложения + синхронизации. Во-первых, вряд ли удастся достичь такой же отзывчивости, как у десктопных. Во-вторых, приложение не сможет работать в моменты отсутствия сети.
Хотя, конечно, копирастам на это пофиг и они будут всеми силами это продвигать.
У облачного приложения, конечно, таких ограничений, как у веб-приложения на интеграцию с платфорой и другими приложенями уже не будет.
Почему эта методика, древняя как гавно мамонта, современными макертологами превозносится как новейшая разработка?Раньше каналы не позволяли передавать гонять потоковое видео туда-сюда, да и мощностей на воспроизведение цифрового видео 20 лет назад не хватало (или едва хватало).
А сейчас инфраструктура позволяет организовать достаточно низкую задержку (в Штатах в случае OnLive ну и терминал обладает существенно большими мощностями нынче.
Что-то новое здесь вполне себе есть.
На каждом компьютере стоит открытый серверный и открытый клиентский софт.каждое клиентское приложение живет в своей песочнице или нет?
текстовые альтернативы для http, html, js?для http вроде что-то предлагало гугль. А если уйти от запроса-ответ на асинхронность, то 0mq+json ничгео себе текстовый протокол.
html - язык форматирования данных, использующий xml. Альтернатива известна много лет как - s-exp. Более современная альтернатива - json. Основная проблема html - бесполезность как роли универсала, так и в роли конкретного протокола. Например для просмотра книг куда лучше годится fb2, и стоило бы просто научить общий протокол сводиться к частной схеме. Если же мы хотим иметь некоторую общую универсальную схему, то html опять же не лучше, потому что плохо решает проблему размещения виджетов на экране, советую посмотреть на qml для сравнения (текстовый формат размещения виджетов для среды qt)
js имеет море текстовых альтернатив. Для тех, кто в танке, большая часть языков программирования - текстовые. И есть ряд более удобных скриптовых языков, тот же питон, или более быстрое си, которое тоже текстовое.
второй принципиальный момент:
ОС обеспечивают песочницу для каждого юзера,
браузер обеспечивает песочницу для каждого приложения.
ОС обеспечивают песочницу для каждого юзера,
браузер обеспечивает песочницу для каждого приложения.
С точки зрения удобства облачные приложения с тонким клиентом будут проигрывать толстому клиенту из десктопного приложения + синхронизации. Во-первых, вряд ли удастся достичь такой же отзывчивости, как у десктопных. Во-вторых, приложение не сможет работать в моменты отсутствия сети.1. На данном этапе развития технологий — конечно, не удастся. Но уменьшить задержку до пары десятков миллисекунд более чем реально (со временем — уж точно будет реально равно как и увеличить разрешение с 720p. Решаемая проблема.
2. На это, как я сейчас вижу, мало кто оглядывается (это плохо, конечно же). Многие игры требуют подключения к интернету просто для запуска, даже если в них нет мультиплеера (Ubisoft любит такое). То есть подключение к интернету считается чем-то всегда присутствующим.
Есть другие плюсы у толстых клиентов. Мы, например, сейчас совсем-совсем не обсуждаем взаимодействие приложений и user experience в ОС.
контекстта шо ви говорите
"среднеквадратичность" это вполне себе хнс'ная тема, в широком смысле потребителей всей этой лабуды
а не только "создателей"
так что за контекстом иди-ка ты в development со своим Столманновским RMS если хочешь чтоб тебя сходу поняли, а то мне, например, прыгающий RMS немного разрушает моск
Раньше каналы не позволяли передавать гонять потоковое видео туда-сюда,А сейчас учёные научились передавать интернет со скоростью, превыщающей скорость света? Давай поспорим, что при равном скиле игрок на десктопе порвёт в кваку игрока на терминале, как игрок на мышке обыгрывает пользующегося геймпадом, если только терминал не в том же кампусе, что и сервак, но тогда работает мой принцип - даёшь в каждую семью по собственному небольшому облаку на базе открытых платформ.
"среднеквадратичность" это вполне себе хнс'ная тема, в широком смысле потребителей всей этой лабудыКак раз в девелопменте или стади уместнее было бы обсуждение числовым методик, чем в софте
а не только "создателей"
так что за контекстом иди-ка ты в development со своим Столманновским RMS если хочешь чтоб тебя сходу поняли, а то мне, например, прыгающий RMS немного разрушает моск
html - язык форматирования данных, использующий xml. Альтернатива известна много лет как - s-exp. Более современная альтернатива - json.оба не устойчивы к ошибкам. в частности, к ошибкам escape-инга, когда забыли сделать экранизацию служебных символов.
> советую посмотреть на qml для сравнения (текстовый формат размещения виджетов для среды qt)
чем он принципиально лучше?
> Для тех, кто в танке, большая часть языков программирования - текстовые. И есть ряд более удобных скриптовых языков, тот же питон, или более быстрое си, которое тоже текстовое.
необходима возможность интерпретации кода прямо в текстовом представлении.
опять же нужна устойчивость к ошибкам в коде
чем питон принципиально лучше, чем js?
А сейчас учёные научились передавать интернет со скоростью, превыщающей скорость света? Давай поспорим, что при равном скиле игрок на десктопе порвёт в кваку игрока на терминале, как игрок на мышке обыгрывает пользующегося геймпадом, если только терминал не в том же кампусе, что и сервак, но тогда работает мой принцип - даёшь в каждую семью по собственному небольшому облаку на базе открытых платформ.Понятно, что там будет лаг, превышающий таковой при простом соединении толстых клиентов по сети. Но уже сейчас он достаточно небольшой, чтобы значительная часть игроков могла играть даже в multiplayer без особых трудностей, а дальше, при увеличении толщины каналов и уплотнении сетки серверов (у OnLive не один сервер задержки будут только уменьшаться.
в стади RMS ассоциируется с "отклонениями"
тут RMS ассоциируется с мощностью
и только в девелопменте он может ассоциироваться со Столлманом, потому как "числовые методики" относятся опять же к стади скорее, нежели к девелопменту
тут RMS ассоциируется с мощностью
и только в девелопменте он может ассоциироваться со Столлманом, потому как "числовые методики" относятся опять же к стади скорее, нежели к девелопменту
опять же нужна устойчивость к ошибкам в кодевау. А писать так, чтобы компилировалось не пробовали?
ээ люди, а что такого есть в json, чего нет в xml, и чем он лучше?
ээ люди, а что такого есть в json, чего нет в xml, и чем он лучше?xml - это чиловекописабельный формат, а json ещё и чиловекочитабельный.
вау. А писать так, чтобы компилировалось не пробовали?это создает высокий порог входа, а в быстро-развивающемся мире среда с высоким порогом входа сразу скатывается на обочину.
выигрывает среда: в которой можно делать и проги с ошибками, и без ошибок - при том, вторые работают быстрее и лучше, чем первые.
выигрывает среда:Если бы говнокод не поддерживался на государственном уровне, в условиях либертианства вторая среда бы проиграла
2. На это, как я сейчас вижу, мало кто оглядывается (это плохо, конечно же). Многие игры требуют подключения к интернету просто для запуска, даже если в них нет мультиплеера (Ubisoft любит такое). То есть подключение к интернету считается чем-то всегда присутствующим.Ну это следствие того, что здесь вступают в конфликт комерческие интересы с удобством пользователя. И последнее оказывается у комерческого ПО не в приоритете. А свободное ПО на этом поприще пока практически не встречается, к сожалению.
Есть другие плюсы у толстых клиентов. Мы, например, сейчас совсем-совсем не обсуждаем взаимодействие приложений и user experience в ОС.Если я правильно понял, то облачным приложением, на примере OnLive, считается приложение, устанавливаемое на компьютер пользователя, но производящее бОльшую часть вычислений на сервере, а не на клиенте. В таком случае с точки зрения пользователя десктпоное приложение с синхронизацией и облачное приложение будут неотличимы.
Если бы говнокод не поддерживался на государственном уровне, в условиях либертианства вторая среда бы проигралакак раз нет. чем больше свободы, тем быстрее выигрывает среда, которая одновременно мягка к ошибка и дает плюшки за отсутствие ошибок. потому что такая среда собирает нубов, которые в ней же и остаются.
Если бы говнокод не поддерживался на государственном уровне, в условиях либертианства вторая среда бы проигралазачем мне как разработчику выбирать среду, в которой меня будут наказывать за ошибки, если я могу выбрать среду, где не будут наказывать?
и зачем мне как пользователю выбирать среду, которая не дает работать из-за малейшей неточности в коде, вместо той, которая предупреждаем меня, что в коде есть ошибки. но позволяет спокойно работать дальше?
как раз нет. чем больше свободы, тем быстрее выигрывает среда, которая одновременно мягка к ошибка и дает плюшки за отсутствие ошибок. потому что такая среда собирает нубов, которые в ней же и остаются.Ну давай представим на миг, что государстве перестало вмешиваться, поставим такой мысленный эксперимент.
И наконец-то крякеры могут со спокойной совестью искать уязвимости и монетизировать их. Долго протянет система, прощающая программистам ошибки? Ведь сейчас фактически государство покрывает плохих программистов и наказывает хороших.
зачем мне как разработчику выбирать среду, в которой меня будут наказывать за ошибки, если я могу выбрать среду, где не будут наказывать?Лично я выбираю потому, что она лучше ищет ошибки за меня. Нет такой среды, которая могла бы только обнаруживать ошибки и уведомлять. Потому что уведомить можно только о первой ошибке, весь остальной код после этого становится неверефицируемым и искать там ошибки становится проблематично.
Так что либо среда ищет много ошибок вместо тебя, либо она много прощает. А дальше всего лишь вопрос в том, какой продукт ты хочешь предоставить - качественный или нет. Общеэкономическая теория гласит, что чем больше гавнорпродукта, тем больше ВВП и всё будет пучком, вот государство и поддерживает некачественные товары
И наконец-то крякеры могут со спокойной совестью искать уязвимости и монетизировать их. Долго протянет система, прощающая программистам ошибки? Ведь сейчас фактически государство покрывает плохих программистов.как раз устойчивость к ошибкам помогает от крякеров. если в C любую малейшую ошибку можно использовать злонамеренно, то в скриптах можно эксплуатировать уже намного меньший процент ошибок.
от крякеров помогает развитая система песочниц, и мониторинг деятельности софта.
гонения на софт с ошибками от крякеров помогают слабо.
зы
дырявость веб-приложений обусловлена не ошибками, а тем что нет песочницы для доступа к кукам, отвечающих за секьюрность.
и также отсутствием возможности создавать песочницы на уровне js.
Потому что уведомить можно только о первой ошибке, весь остальной код после этого становится неверефицируемым и искать там ошибки становится проблематично.это справедливо только для монолитного софта, а не для софта который построен как большое кол-во вложенных в друг-друга песочниц.
> советую посмотреть на qml для сравнения (текстовый формат размещения виджетов для среды qt)Ему нет нужды сохранять совместимость с форматами, не предназначенными для отображения пользовательского интерфейса
чем он принципиально лучше?
второй принципиальный момент:Этим как раз и обеспечивается возможность интеграции с платформой и друг другом - основное преимущество десктопных (и облачных) программ помимо быстродействия по сравнению с веб.
ОС обеспечивают песочницу для каждого юзера,
браузер обеспечивает песочницу для каждого приложения.
Понятно, что степень доверия к ним должна быть выше, чем к веб-приложениями. Это, например, возможно достичь использованием свободных приложений. Но, как я уже сказал, таких (насколько мне известно) пока нет. Да и закрытых-то почти нет, а те, что есть, целостную платформу не обеспечивают.
ОС обеспечивают песочницу для каждого юзера,Некоторые ОС обеспечивают песочницу для каждого приложения
браузер обеспечивает песочницу для каждого приложения.
Некоторые браузеры позволяют запускаться бинарями (activex а теперь ещё и новая технология интеля) в системном окружении.
Ну давай представим на миг, что государстве перестало вмешиваться, поставим такой мысленный эксперимент.такое уже есть, называется веб.
сейчас в вебе без проблем монетизируется произвольная дыра, и государство особо с этим не борется.
и мы видим, что в вебе в ответ на это все больше развивается идея песочниц, а давайте напишем код без ошибок, подпишем каждый кусочек кода отдельной подписью и т.д. - этим как раз занимаются большие корпорации, а не веб.
В таком случае с точки зрения пользователя десктпоное приложение с синхронизацией и облачное приложение будут неотличимы.Реализация всё же может быть различной. Сейчас попробую пояснить, что я имею в виду.
Возьмём, например, какую-нибудь кроссплатформенную софтину, компилируемую под разные ОС без изменений и написанную на каком-нибудь популярном фрэймворке (Qt, GTK, да хоть Adobe AIR). Фрэймворки эти предоставляют разработчику «окошечко», в котором один и тот же код будет работать одинаково, и, таким образом, не нужно писать разные версии кода для разных платформ.
Но у пользователей под разными платформами разные привычки. То, что вполне сносно в винде, смотрится в макоси ущербно (например, вчера баловался с Inkscape в макоси, а у него drag&drop не работал, если в него файл тащить из Finder'а). Это помимо неиспользования полезных фич OS X 10.7 и ощутимых тормозов на неплохом, вообще гвооря, железе.
Так и с «облачными» приложениями: да, можно написать софт, который только тяжёлые вычисления отдаёт на сервер, а с системой взаимодействует как обычное нативное приложение. OnLive как раз, я считаю, не является образцом хорошей «облачной» программы. Это просто «окно в мир», где ты можешь запустить какую-нибудь игрушку, любую на свой выбор. Он функционирует совершенно независимо от ОС. И ведь гораздо проще сделать аналог OnLive — простое «окошечко», которое будет выводить результаты работы программы, а серверу будет просто отдавать информацию о нажатых клавишах. Эдакий чёрный ящичек. Зато кроссплатформенность легко обеспечить.
Некоторые ОС обеспечивают песочницу для каждого приложениякакое это отношение имеет к обсуждению, какие принципальные моменты предоставляет браузер и ОС?
Некоторые браузеры позволяют запускаться бинарями (activex а теперь ещё и новая технология интеля) в системном окружении.
Этим как раз и обеспечивается возможность интеграции с платформой и друг другом - основное преимущество десктопных (и облачных) программ помимо быстродействия по сравнению с веб.в идеале, же хочется, чтобы приложение, по умолчанию, жило в песочнице, и при этом ему можно дать права на интеграцию с другими приложениями с произвольной степенью гранулярности.
или я не прав?
и это довольно близко к тому, что продвигает гугл (при этом да, мне тоже не нравится vendor lock)
Кстати, о песочницах: Эпл с ноября (вроде) требует, чтобы все приложения в Mac App Store были в песочнице. Заодно в OS X 10.8 она даёт опциональную возможность запретить установку приложений не из App Store.
Интересно, как антивирусы будут распространяться, если мак наберёт достаточную привлекательность для вирусописателей.
Интересно, как антивирусы будут распространяться, если мак наберёт достаточную привлекательность для вирусописателей.
какое это отношение имеет к обсуждению, какие принципальные моменты предоставляет браузер и ОС?Прямое. Ты выбрал не правильную различительную черту. Нормальные ОС предоставляют механизм песочницы на уровне приложения, нормальные браузеры предоставляют механизм песочницы на уровне приложения. Так что браузеры не имеют уникальной ниши
Нормальные ОС предоставляют механизм песочницы на уровне приложения, нормальные браузеры предоставляют механизм песочницы на уровне приложения. Так что браузеры не имеют уникальной нишиты куда-то пропустил первый принципиальный момент, что браузер предоставляет стандартизацию доступа к выводимому rich-контенту, в частности, возможность сделать закладку на почти произвольный экран, и скопировать произвольные выводимые на экран данные
Нормальные ОС предоставляют механизм песочницы на уровне приложения, нормальные браузеры предоставляют механизм песочницы на уровне приложения.кстати тут принципиальный момент - это просто возможность, или это де факто всегда применяется. и соответственно, большинство софта построено с учетом этого.
Я как-то не понял о каком государстве вы с Айвенго говорите? w3c чтоли так обзываете?
Я как-то не понял о каком государстве вы с Айвенго говорите? w3c чтоли так обзываете?утверждает, что сейчас вирусов мало, потому что с вирусописателями борется FBI и управление К. а если бы они не боролись, то вирусов было бы в миллион раз больше.
в идеале, же хочется, чтобы приложение, по умолчанию, жило в песочнице, и при этом ему можно дать права на интеграцию с другими приложениями с произвольной степенью гранулярности.У тебя сейчас десктопные приложения работают в песочнице? (например SELinux или AppArmor в GNU/Linux, jail во FreeBSD, chroot во всех UNIX-like, наверняка должны быть аналоги для Win и Mac[там наверяка есть chroot как минимум])
или я не прав?
Думаю, что не работают и тебя это не напрягает. А если в системе появится демон (сервис который бы производил аутентификацию на сервере и затем постоянную синхронизацию данных всех приложений с сервером через октытые протоколы, то тебя бы сразу стало напрягать, что приложения работают не в песочнице? Почему?
Реализация всё же может быть различной. Сейчас попробую пояснить, что я имею в виду.По-моему ты как раз доказал, что различий с точки зрения пользователей не будет. Как десктопное+синхронизация, так и облачное можно писать нативно, а можно игнорируя особенности платформы.
[...]
Так и с «облачными» приложениями
Ему нет нужды сохранять совместимость с форматами, не предназначенными для отображения пользовательского интерфейсатогда ты опять сравниваешь не сравнимые вещи.
язык, который выбран в качестве общего протокола - с языком, который не выбран в качестве общего протокола.
язык, который выбран в качестве общего и который уже используется продолжительное время - не может не иметь неудачных моментов, потому что из-за необходимости обеспечивать совместимость со старым кодом, он не может мгновенно от них избавиться.
соответственно, если мы сегодня выбираем в качестве общего стандарта python и qml, то через 5 лет выяснится, что в них есть неудачные моменты M1, M2.. MN, и с этим ничего нельзя быстро сделать.
Кстати, о песочницах: Эпл с ноября (вроде) требует, чтобы все приложения в Mac App Store были в песочнице. Заодно в OS X 10.8 она даёт опциональную возможность запретить установку приложений не из App Store.Если это будет единственный штатный способ установки программ, то антивирусы будут не нужны при таком подходе вне зависимости от привлекательности для вирусописателей.
Интересно, как антивирусы будут распространяться, если мак наберёт достаточную привлекательность для вирусописателей.
Но такая система будет означать крайне ограниченную интерграцию программ (или отсутствие оной а значит наверняка приделают костыль в виде вопроса: "Приложение хочет иметь доступ туда и туда. Разрешить?", примерно как это сейчас задаётся в Андроиде.
Ведь можно же написать открытый серверный софт (для некоторых протоколов уже открыто залить его на собственный сервак и работать уже с ним.свой сервак неудобно поддерживать
то есть корпоративный ит-отдел это сможет (и они делают)
а лично для себя не очень удобно, нужно личного админа где-то искать и за всё платить
а большой брат делает бесплатно, ему нужно только чтоб ты рекламы немного почитал
Если это будет единственный штатный способ установки программ,Вот же, положила:
Заодно в OS X 10.8 она даёт опциональную возможность запретить установку приложений не из App Store.Mac App Store ещё довольно долго не будет достаточно популярным, да и Adobe, например, сама свой софт продаёт.
Ну и сейчас вирусы через уязвимости браузеров попадают на компы — вполне возможно, что и в макось они смогут попадать как-нибудь по-хитрому.
По-моему ты как раз доказал, что различий с точки зрения пользователей не будет.Да, похоже, в самом деле так и есть. В общем, в любом случае хочу больше нативных приложений под все системы.
одно дело, когда под данную платформу один большой брат, который неизвестно что с твоими данными делает, так как сервер даже в бинарном виде публично недоступен.
Другое дело, когда таких больших братьев будет масса и они будут работать на идентичном открытом ПО.
При этом вполне возможно так разработать ПО и протоколы так, что доступа к данным пользователя у "больших братьев" не будет, а на их серверах всё будет лежать в зашифрованном виде.
А для пользователя это будет выглядеть как в ролике, рекламирующем ChromeOS, где пострадало несколько ноутбуков.
Другое дело, когда таких больших братьев будет масса и они будут работать на идентичном открытом ПО.
При этом вполне возможно так разработать ПО и протоколы так, что доступа к данным пользователя у "больших братьев" не будет, а на их серверах всё будет лежать в зашифрованном виде.
А для пользователя это будет выглядеть как в ролике, рекламирующем ChromeOS, где пострадало несколько ноутбуков.
У тебя сейчас десктопные приложения работают в песочнице? Думаю, что не работают и тебя это не напрягает.сейчас используется разумный компромисс, и зависит от степени доверия к приложениям.
большинство часто-используемых приложений работает в общей не админской песочнице,
всякая херотень живет под SandBox-ом или в виртуалке.
и меня напрягает:
например, что updater-ы Java-ы и Flash-а хотят от меня админских прав, и при этом я не могу их запихать в песочницу парой кликов.
и что саму java-у и flash я не могу запихать в отдельную доп. песочницу,
или что какой-нибудь trillian хочет общий пароль от google-аккаунта, и при этом ему нельзя дать доступ только на отслеживание новых сообщений в gtalk.
Чем, по сути, веб-приложение отличается от десктопного? Тем что написано на яваскрипте и работает в браузере по протоколу HTTP? В последнее время это не совсем так, реализована песочница для нативного кода native client, таким образом, с определёнными ограничениями могут работать вполне десктопные когда-то приложения вроде quake. В том же браузере есть поддержка веб-сокетов для постоянных соединений, всякие облачные службы печати и пр. Что отличает его от операционной системы, часть кода которой написано на скриптах? В общем-то, некая ограниченность возможностей, вопрос в том, чего будет достаточно для 95% приложений.
Ну и сейчас вирусы через уязвимости браузеров попадают на компы — вполне возможно, что и в макось они смогут попадать как-нибудь по-хитрому.Да, но тут единственный разумный подход - это исправить эту уязвимость в браузере и автоматически обновиться.
Но никак не записать сигнатуры всего использующего эту уязвимость кода в базу, распространить всем эту базу, а потом весь поступающий код для песочницы сканировать не предмет наличия сигнатуры.
Первый подход 100% надёжен, а второй не гарантирует, что найдены все уязвимости, тратит время и ресурсы на сканирование.
xml - это чиловекописабельный формат, а json ещё и чиловекочитабельный.я тока в последнем не помню хорошего валидирования и отображения, скажем, на объекты. К тому же зачем вообще нужны человеко(чита|писа)бельные языки для передачи данных?
Браузеры-то более-менее шустро обновляются, проблема чаще во флэше каком-нибудь. Тем более, что он, зараза, не в песочнице.
К тому же зачем вообще нужны человеко(чита|писа)бельные языки для передачи данных?потому что передачу данных пишут человеки.
одно дело, когда под данную платформу один большой брат, который неизвестно что с твоими данными делает, так как сервер даже в бинарном виде публично недоступен.Что-то такое начал пилить Фицпатрик, у него это называется camlistore, есть и diaspora, но это только соцсеть. Да и ранее пытались использовать DHT как хранилище для произвольных данных.
Другое дело, когда таких больших братьев будет масса и они будут работать на идентичном открытом ПО.
Ну давай представим на миг, что государстве перестало вмешиваться, поставим такой мысленный эксперимент.
И наконец-то крякеры могут со спокойной совестью искать уязвимости и монетизировать их. Долго протянет система, прощающая программистам ошибки? Ведь сейчас фактически государство покрывает плохих программистов и наказывает хороших.
Можно тупому жирафу объяснить, какое государство поддерживает js и не поддерживает py или вы о чём?
Я тут подумал... да, ты прав: было бы здорово если бы каждое приложение имело свою песочницу + гибкий механизм по настройки "стенок" между этими песочницами вплоть до полного их убирания между группами приложений.
Но вряд ли гибкую настройку реально сделать на основе браузера. Хотя бы потому, что человек за день может открыть сотни и тысячи страниц и он не захочет настраивать эти ограничения для каждой. А вот десктопные приложения ставятся редко и среди них уже сейчас реально что-то подобное сделать. Так что осталось к ним приделать синхронизацию с сервером и это будет почти что идеал.
Но вряд ли гибкую настройку реально сделать на основе браузера. Хотя бы потому, что человек за день может открыть сотни и тысячи страниц и он не захочет настраивать эти ограничения для каждой. А вот десктопные приложения ставятся редко и среди них уже сейчас реально что-то подобное сделать. Так что осталось к ним приделать синхронизацию с сервером и это будет почти что идеал.
потому что передачу данных пишут человеки.На сервере сидят и вручную отвечают на запросы?
Хотя бы потому, что человек за день может открыть сотни и тысячи страниц и он не захочет настраивать эти ограничения для каждой.так для этой тысячи приложений обычно и не хочется ничего настраивать(достаточно того, что пусть они сидят в самом жестком наборе песочниц).
настроить интеграцию хочется же только для приложений с которыми работаешь часто, а таких уже единицы.
Как минимум тем же, чем по словам no_name отличается Inkscape в Маке от нативного приложения. Тем, что никогда не будет интегрировано в среду.
А вот, например, с моей точки зрения: всё чаще встречаю в веб подобия плавающих окон, перекрывающих часть контента, вплоть до присутствия заголовков и "крестиков". Десктопные приложения тоже, как правило, пишутся под прадигму перекрывающихся окон, но ion из них успешно делает тайлы. А с веб-приложениями я вынужден мириться с плавающими окнами, либо не пользоваться веб-приложением.
В этом и есть их принципеальная ущербность.
UPD. Кстати, этот же пост можно считать и ответом для DG.
Представляешь себе, чтобы в браузере можно было настроить интерграцию тамошних окошек с оконной системой?
А вот, например, с моей точки зрения: всё чаще встречаю в веб подобия плавающих окон, перекрывающих часть контента, вплоть до присутствия заголовков и "крестиков". Десктопные приложения тоже, как правило, пишутся под прадигму перекрывающихся окон, но ion из них успешно делает тайлы. А с веб-приложениями я вынужден мириться с плавающими окнами, либо не пользоваться веб-приложением.
В этом и есть их принципеальная ущербность.
UPD. Кстати, этот же пост можно считать и ответом для DG.
Представляешь себе, чтобы в браузере можно было настроить интерграцию тамошних окошек с оконной системой?
На сервере сидят и вручную отвечают на запросы?вручную разбираются, а как правильно написать код, который правильно формирует/разбирает правильную последовательность символов.
нечеловекочитабельные форматы плохи тем, что программист не видит, что он допустил ошибку или неточность при генерации или разборе таких данных.
например, чтобы понять- насколько файл doc сгенерен грязно - это надо сильно постараться, а в том же docx любому видно насколько ужасен генеренный файл.
А с веб-приложениями я вынужден мириться с плавающими окнами, либо не пользоваться веб-приложением.либо можешь написать или заказать написание функционала ion-а под плавающие окна в браузере.
Эм, это не всегда возможно.
Он, мне кажется, имеет в виду не полноценные окна, а закос под окошки (например, модальные появляющиеся то тут, то там.
Он, мне кажется, имеет в виду не полноценные окна, а закос под окошки (например, модальные появляющиеся то тут, то там.
либо можешь написать или заказать написание функционала ion-а под плавающие окна в браузере.Это будет работать под всеми веб-приложениями, использующими по-умолчанию перекрывающиеся окна? Как такое сделать, расскажи?
Представляешь себе, чтобы в браузере можно было настроить интерграцию тамошних окошек с оконной системой?принципиальной проблемы нету. не делается лишь потому, что пока есть более актуальные задачи, которые необходимо решить.
При этом вполне возможно так разработать ПО и протоколы так, что доступа к данным пользователя у "больших братьев" не будет, а на их серверах всё будет лежать в зашифрованном виде.Откуда возьмётся ключ для дешифровки после того, как ноутбук сломается или пропадёт?
А для пользователя это будет выглядеть как в ролике, рекламирующем ChromeOS, где пострадало несколько ноутбуков.
Это будет работать под всеми веб-приложениями, использующими по-умолчанию перекрывающиеся окна? Как такое сделать, расскажи?сам по себе html, по умолчанию, не перекрывается, перекрытие делается через специальный аттрибут z-order, соответственно такие элементы можно отслеживать и предоставлять для них спец. обслуживание, в частности вывод в отдельной песочнице.
Эм, это не всегда возможно.Да, именно так. Например, очень часто картинки при клике по ним увеличиваются в таком импровизированном окне. А я, например, хочу, чтобы это "окно" перекидывалось в другой фрейм и могло закрыться по моему стандартному хоткею.
Он, мне кажется, имеет в виду не полноценные окна, а закос под окошки (например, модальные появляющиеся то тут, то там.
Я не представляю какими изменениями в веб-стандартах + разрешениями от пользователя можно достичь такой интеграции.
Например, очень часто картинки при клике по ним увеличиваются в таком импровизированном окне.Ага, меня тоже не радует такое поведение. Особенно бесит, когда такое окошко открывается секунды полторы (типа плавно а потом меняет свои размеры между фотками такое же время.
Думаю, это довольно частная фича, этого (в десктопном приложении) может не быть на другой платформе, например. Т.е., вполне можно и десктопное приложение написать так, чтобы у тебя это сделать не получалось. С другой стороны свободное десктопное приложение можно пропатчить и пересобрать, если очень хочется, а вот с веб-приложением, даже свободным, это может не пройти (за исключением случая, когда это твоя личная инсталляция, конечно).
А я, например, хочу, чтобы это "окно" перекидывалось в другой фрейм и могло закрыться по моему стандартному хоткею.имея навыки html/js-программиста для конкретного сайта это можно уже сейчас сделать.
посмотреть какая ссылка генерится для большой фотки, и через grease monkey навесить свой обработчик клика для показа большой фотки, и открывать большую фотку как новую страницу.
и при решении такой задачи как раз помогает, что все форматы текстовые
Откуда возьмётся ключ для дешифровки после того, как ноутбук сломается или пропадёт?В качестве ключа можно использовать пароль, какие проблемы? Это уже нюансы. Я говорю про принципеальную возможность сделать такую систему, когда "большой брат" не сможет видеть данные пользователя, а для пользователя это будет также легко, как залогиниться в веб-почте.
выигрывает среда: в которой можно делать и проги с ошибками, и без ошибок - при том, вторые работают быстрее и лучше, чем первые.Ты зываешь об одном важном выводе теории информации: чтобы распознать и нейтрализовать ошибки в данные изначально должна быть заложена избыточность. В вебе её настолько много, что пользоваться ею становится уже неудобно.
В качестве ключа можно использовать пароль, какие проблемы?Проблема в том, что типичный пароль подобрать таким образом с ресурсами "большого брата" - дело минут. Средний пользователь не сможет запомнить пароль, содержащий достаточно много энтропии. А бумажку потеряет вместе с ноутбуком.
Это не нюанс, а принципиальная сложность.
В вебе её настолько много, что пользоваться ею становится уже неудобно.это потому что пока отстают алгоритмы, которые умеют выделять избыточность.
вернее отстает понимание, как эти алгоритмы можно переложить в практическую плоскость.
Я это обычно решаю через плагин типа Image Popup: наводишь мышку, через секунду там полная картинка. Убрал мышку — картинка исчезла. Но не на всяком сайте работает.
Но бывают и другие окошки, не менее мерзкие.
Но бывают и другие окошки, не менее мерзкие.
утверждает, что сейчас вирусов мало, потому что с вирусописателями борется FBI и управление К. а если бы они не боролись, то вирусов было бы в миллион раз больше.И так оно и есть. Потому что помимо эфемерной борьбы есть какие-то избирательные посадки и штрафы, что действует запугивающе, плюс у людей создаётся негативное мнение о хороших программистах посредством СМИ, их сравнивают с ворами и убийцами. Соответственно аудитория тех, кто готов проверять на крепость чужие программы сильно суживается. Нелегальность их деятельности заставлят таиться, нельзя построить открытую и удобную архитектуры вроде гитхаба для написания эксплойтов, что снижает эффективность их. На самом деле цензура веба - вещь очень действенная и спасает очень многие коммерческие проекты.
Т.е., вполне можно и десктопное приложение написать так, чтобы у тебя это сделать не получалось.Для этого надо специально постараться. Например, сделать одно большое окно, а в нём уже (желательно без стандартных средств тулкита) рисовать окна. Если писать стандартно, то такого не получится.
С другой стороны свободное десктопное приложение можно пропатчить и пересобрать, если очень хочется, а вот с веб-приложением, даже свободным, это может не пройти (за исключением случая, когда это твоя личная инсталляция, конечно).Да, это тоже существенно! Десктопное приложение с синхронизацией я тоже смогу патчить сколько угодно пока не меняю используемый протокол для синхронизации.
ты куда-то пропустил первый принципиальный момент, что браузер предоставляет стандартизацию доступа к выводимому rich-контенту, в частности, возможность сделать закладку на почти произвольный экран, и скопировать произвольные выводимые на экран данныечасто закладку сделать нельзя, а если и сделаешь, то она будет бесполезна.
Копирование данных есть - и это часть базовой идеи html. html создан для представления данных, тут спорить нечего. Но он не создан для написания приложений. Вы можете скоприовать данные, да, это полезно. Но зачем, скажем, копировать органы управления? html не подразумевает механизмов создания или стандартизации органов управления (формы - это смешно). Для них неприменима твоя замечательная идея о копировании, у них другие факторы удобства, например настраиваемость пользователем, которые html дать не может
Ну, если пользователь сам своей приватности не хочет помочь, то ему уже никто не поможет.
Впрочем, брутфорсить по паре минут всех пользователей того же гугла, думаю, займёт немало времени.
Впрочем, брутфорсить по паре минут всех пользователей того же гугла, думаю, займёт немало времени.
с определёнными ограничениями могут работать вполне десктопные когда-то приложения вроде quakeвидел я этот квейк. Запили бинарный код в плагин для браузера и назвали веб приложением. Важно то, что веб не даёт никаких удобств для реализации десктопных приложений через веб, только усложняет её. Веб можно использовать для деплоя приложения как например jnlp, но задеплоенные приложения от этого не станут веб-приложениями. Веб запилили для создания информационных систем и в этой роли он чудесен. Десктопные приложения на нём писать ужасно. Страдает программист, от убогости программы страдает пользователь, страдает компьютер у которого сильно проседает производительность. Вы никогда не замечали, что флеш-видео тормозит там, где в большем разрешении не тормозит видео, проигрываемое нативным плеером?
Но бывают и другие окошки, не менее мерзкие.основная проблема сейчас, что html не предназначен для описания web-2.0 приложений. соответственно, каждый реализует веб 2.0 как-то по своему, в меру своей испорченности (например, динамическое изменение, навигацию, окна, анимацию и т.д. и соответственно со стороны клиента не получается достоверно определить. что чем является.
Но зачем, скажем, копировать органы управления?то есть я не должен хотеть копировать название пункта меню?
вот сейчас говнопрограммисту пишут говносайты. Если хорошие программисты эти сайты сломают, они не смогут выложить результат и получить заслуженный бонус за это, им придётся через кардеров действовать или ещё по какой тёмной схеме
Можно тупому жирафу объяснить, какое государство поддерживает js и не поддерживает py или вы о чём?
Вот именно, что для конкретного сайта. А для всех десктопных приложений это делается в одном месте - коде оконного менеджера.
Ну и с картинками это же только пример. Таких "фич" масса.
Эти окошки на худой конец во флеше могут нарисовать. Тогда точно абзац - ничего не сделаешь.
Ну и с картинками это же только пример. Таких "фич" масса.
Эти окошки на худой конец во флеше могут нарисовать. Тогда точно абзац - ничего не сделаешь.
> Запили бинарный код в плагин для браузера и назвали веб приложением
Есть важное отличие от того же флеша: он безопасен. И, опять же, открытость: если флеш тормозной, но уж какой есть, такой есть, то приложение под native client можно оптимизировать и пересобирать. А интеграция с какими-нибудь механизмами ОС — дело времени.
Есть важное отличие от того же флеша: он безопасен. И, опять же, открытость: если флеш тормозной, но уж какой есть, такой есть, то приложение под native client можно оптимизировать и пересобирать. А интеграция с какими-нибудь механизмами ОС — дело времени.
свой сервак неудобно поддерживатьфактически сейчас все этим занимаются. Потому что обычной десктопный комп сочетает в себе и сервера и клиента, эти функции ещё не разнесены
Есть важное отличие от того же флеша: он безопасен.если ты про плагин для браузера, то разочарую, нет. Он столь же опасен, как и флеш, который тоже плагин для браузера. Единственное отличие - кваку писали пряморукие программисты
Впрочем, брутфорсить по паре минут всех пользователей того же гугла, думаю, займёт немало времени.В фоновом режиме, на временно незанятых делом узлах.
Эти окошки на худой конец во флеше могут нарисовать. Тогда точно абзац - ничего не сделаешь.К счастью, сайтов на флэше сейчас стало поменьше по сравнению, скажем, с 2007 годом каким-нибудь.
Почему? http://googleonlinesecurity.blogspot.com/2008/12/native-clie...
Там безопасность на уровне инструкций.
Там безопасность на уровне инструкций.
К счастью, сайтов на флэше сейчас стало поменьше по сравнению, скажем, с 2007 годом каким-нибудь.госуслуги на флеше
Oh shi~
Почему? http://googleonlinesecurity.blogspot.com/2008/12/native-clie...я говорил про известный веб-проект по привнесению кваки в браузер. Он не использует NaCl. Сам подход NaCl сомнителен, поскольку вместо песочницы он использует хаки и машинное преобразование программ, действенность которых нельзя доказать
Там безопасность на уровне инструкций.
часто закладку сделать нельзя, а если и сделаешь, то она будет бесполезна.
html не подразумевает механизмов создания или стандартизации органов управления (формы - это смешно).я не говорю, что то, что есть - оно идеально.
я говорю, что браузер добавляет ряд принципиальных вещей, которых не было до этого. и эти принципиальные вещи приближают нас к некому идеальному софту.
основная проблема сейчас, что html не предназначен для описания web-2.0 приложений. соответственно, каждый реализует веб 2.0 как-то по своему, в меру своей испорченности (например, динамическое изменение, навигацию, окна, анимацию и т.д. и соответственно со стороны клиента не получается достоверно определить. что чем является.Да, я же о том и говорю. Веб уже ушёл в том направлении, когда его уже нельзя нормально интегрировать в систему.
Если бы сделали единый обязательный тулкит для веб-приложений, то да, можно было бы говорить о какой-то интеграции. Но в данном случае, мне кажется, это сродни реанимациии трупа. Лучше приделать к десктопным приложениям возможность синхронизации.
Веб уже ушёл в том направлении, когда его уже нельзя нормально интегрировать в систему.есть тот же WAI-ARIA http://www.w3.org/WAI/intro/aria.php в качестве попытки все это дело стандартизовать.
зы
стоит еще помнить, что сейчас основные деньги крутятся в приложениях для мобильников, а десктопы - это динозавры (временно или навсегда - пока не понятно а озвученные тобой проблемы и решения (в виде desktop-приложений) специфичны только для десктопов.
я говорил про известный веб-проект по привнесению кваки в браузер. Он не использует NaCl.http://nacl-quake.appspot.com/
> Сам подход NaCl сомнителен, поскольку вместо песочницы он использует хаки и машинное преобразование программ, действенность которых нельзя доказать
почему хаки и почему нельзя доказать?
есть тот же WAI-ARIA http://www.w3.org/WAI/intro/aria.php в качестве попытки все это дело стандартизовать.Это отлично. Но вопрос сколько веб-сайтов пользуются этим стандартом и сколько хотя бы планируют?
Вообще тот идеал, про который мы говорим, видимо, называется semantic web.
стоит еще помнить, что сейчас основные деньги крутятся в приложениях для мобильников, а десктопы - это динозавры (временно или навсегда - пока не понятно а озвученные тобой проблемы и решения (в виде desktop-приложений) специфичны только для десктопов.Во-первых, это связано с относительно новым и ещё не поделённым рынком, а не с устареванием десктопов.
Во-вторых, не вижу причин, чтобы для мобильных устройств синхронизация данных нативных приложений была бы менее актуальна.
Во-вторых, не вижу причин, чтобы для мобильных устройств синхронизация данных нативных приложений была бы менее актуальна.менее актуальны понятия - нативные приложения, ОС и т.д.
> Во-первых, это связано с относительно новым и ещё не поделённым рынком, а не с устареванием десктопов.
есть вариант интеграции мобильника с телевизором. пользовательское управление на мобильнике, вывод чего-то большого на телевизоре.
для гиков: мобильник + большая экранная панель (со своими примитивными мозгами) + сервер.
в обоих вариантах нет десктопа.
есть вариант интеграции мобильника с телевизором. пользовательское управление на мобильнике, вывод чего-то большого на телевизоре.Кстати, у Apple есть реализация такого. В частности, дистанционное управление айтюнсом на компе и беспроводной вывод инфы на Apple TV (это без компьютера уже).
для гиков: мобильник + большая экранная панель (со своими примитивными мозгами) + сервер
Сам подход NaCl сомнителен, поскольку вместо песочницы он использует хаки и машинное преобразование программ,вообще, мне кажется здесь присутствует непонимание как устроена произвольная песочница (виртуализация и т.д.).
Любая песочница устроена ровно так же: есть набор инструкций для которых доказано, что они из песочницы выйти не могут, а инструкции выходящие из песочницы либо запрещаются, либо эмулируются.
NaCl меня расстраивает тем, что там как раз все отдано на откуп разработчику приложения. пользователь даже громкость звука для приложения не может настроить, не говоря про какие-то менее явные вещи
Проблема в том, что типичный пароль подобрать таким образом с ресурсами "большого брата" - дело минут. Средний пользователь не сможет запомнить пароль, содержащий достаточно много энтропии. А бумажку потеряет вместе с ноутбуком.можно сгенерить большой длинный ключ (которым шифровать данные для закачки в сеть ключ порезать на N-частей и сложить в сеть в N-разных мест.
при этом пока жив мобильник - ключ доступен из него, если же мобильник умер, то есть процедура (в том числе может быть и длительная) для собирания ключа из N-мест в единое целое.
зы
например, даже если эти N-мест генерятся из пароля как N-аккаунтов на двух независимых сайтах, то уже перебирать затрахаешься.
ззы
я не зря подчеркнул, что если мобильник умер, то достаточно длительного способа восстановления - в частности при этом может применяться техника: изначально к паролю приписывается N-рандомных бит, которые сразу же забываются, а при восстановлении происходит перебор этих N-рандомных бит.
вот сейчас говнопрограммисту пишут говносайты. Если хорошие программисты эти сайты сломают, они не смогут выложить результат и получить заслуженный бонус за это, им придётся через кардеров действовать или ещё по какой тёмной схемене думаю, что от отмены этого количество говнопрограммистов уменьшится. Скорей часть из них мигрирует в кулхацкеров и действительно талантливым взломщикам будет выделиться сложнее.
действительно талантливым взломщикам будет выделиться сложнееда ладно, сейчас полно всяких программистов, и созданная движуха только способствует самореализации талантливых.
можно сгенерить большой длинный ключ (которым шифровать данные для закачки в сеть ключ порезать на N-частей и сложить в сеть в N-разных мест.серьёзная заморочка прямо на старте
при этом пока жив мобильник - ключ доступен из него, если же мобильник умер, то есть процедура (в том числе может быть и длительная) для собирания ключа из N-мест в единое целое.
то есть порог вхождения
гуглосервисами пользуются как раз для того, чтобы не регистрироваться вместо этого на куче сайтов
серьёзная заморочка прямо на стартеэто не должен делать пользователь, это должно сделать клиентское ПО.
то есть порог вхождения
Зачем компании стараться не иметь доступ к данным пользователя, если для пользователя это будет выглядеть одинаково? Кто захочет разобраться поднимет нужный сервер себе сам.
Зачем компании стараться не иметь доступ к данным пользователя, если для пользователя это будет выглядеть одинаково?если именно в этом их услуга и состоит и они за это хотят денег, то почему бы и нет?
зы
банки же предоставляют ячейки, и при этом гарантируют, что они в них не смотрят. в чем разница с приведенной ситуацией?
Тут клиент понимает, что это так и он за это платит, здесь же чем со стороны хитрый алгоритм со стороны отличается от слов CEO "ваши данные в сохранности, мамой клянусь"?
Тут клиент понимает, что это так и он за это платит, здесь же чем со стороны хитрый алгоритм со стороны отличается от слов CEO "ваши данные в сохранности, мамой клянусь"?клиент же не сам по себе понимает, что банк не имеет доступа к ячейкам - а из-за того, что есть определенная процедура (схема работы) и экспертное мнение, что такая процедура обеспечивает достаточную надежность.
с данными всё тоже самое:
например, если "банк данных" предоставляет клиентское ПО, которое шифрует данные на клиенте и на сервере хранит зашифрованные данные и при этом ключ на сервер не передается - это обеспечивает экспертное мнение, что данная схема гарантирует надежность от утечки данных.
менее актуальны понятия - нативные приложения, ОС и т.д.Не вижу чем эти понятия менее актуальны. Есть ОС (Android; iOS под каждую свои нативные приложения (на java под Dalvik; на objC, вроде). В них есть какая-то интеграция с окружением. Есть настраиваемая песочница. Всё тоже самое.
Правда сейчас эта песочница реализована каким-то странным образом, ставя человека перед дилеммой либо разрешить приложению всё, что оно хочет, либо приложение вообще не запустится. Так что эффективность такой песочницы очень сомнительна. Нужно лишь убедить пользователя, что приложение ему крайне нужно и он покорно ему всё разрешит.
(По крайней мере так было в Android. Хотели как-то заказать доставку в ресторане, а на сайте было написано, что через мобильное приложение скидка, решили попробовать его поставить, а оно хотело доступ ко всем контактам, так что заказывали в итоге через сайт без скидки).
есть вариант интеграции мобильника с телевизором. пользовательское управление на мобильнике, вывод чего-то большого на телевизоре.Добавить к этому ещё что-нибудь вот такое и чем это принципеально будет отличаться от десктопа?
для гиков: мобильник + большая экранная панель (со своими примитивными мозгами) + сервер.
в обоих вариантах нет десктопа.
Только сейчас ты на этом вряд ли сможешь что-то делать, кроме как играть в игры, смотреть видюшки, да сёрфить в инете.
Да и сколько людей занимаются подобной интеграцией? Думаю, с точки зрения обычного человека, это такое же гикство.
Зачем компании стараться не иметь доступ к данным пользователя, если для пользователя это будет выглядеть одинаково? Кто захочет разобраться поднимет нужный сервер себе сам.Идею, что можно реализовать систему, в которой информация на сервере синхронизации хранится в недоступном для провайдера сервиса виде, высказывал я. Но я не призывал прямо вот всех заставлять этим шифрованием пользоваться (в связи с этим также не понимаю сути претензий Гадфазера по поводу того, что большинство паролей некриптостойки). Но такая возможность для желающих должна быть. И не провайдеры сервиса должны стараться её обеспечить, а разрабочки протоколов, по которым такая синхронизация будет происходить. Тогда это будет надёжно и проверяемо, а не "мамой клянусь".
А вот как раз то, что сейчас делает google и прочие в виде "политики конфиденциальности" - действительно заявления в стиле "мамой клянусь". И не важно в каком виде у них там это хранится, так как им оно доступно нешифрованным.
Есть ОС (Android; iOSв каких реальных сценариях пользователь взаимодействует с этой ОС?
под каждую свои нативные приложения (на java под Dalvik; на objC, вроде).в каких реальных сценариях проявляется, что это именно нативные приложения, а не, например, веб-приложения с поддержкой offline-работы?
> Добавить к этому ещё что-нибудь вот такое и чем это принципеально будет отличаться от десктопа?
тем, что здесь появляется задача переноса данных и переноса выполнения кода между машинами: что требует согласованности версий кода между машинами, прозрачного автоматического развертывание кода, поддержка разнородных устройств и т.д.
и вот это больше присуще для веб-приложений, чем для десктоп-приложений.
Добавить к этому ещё что-нибудь вот такое и чем это принципеально будет отличаться от десктопа?попробую зайти с другой стороны:
как, например, в виде десктопного софта реализовать фичу "семейный фотоальбом" для семьи мама+папа+два ребенка с возможностью добавления и обработки фоток каждым членом семьи?
тем, что здесь появляется задача переноса данных и переноса выполнения кода между машинами: что требует согласованности версий кода между машинами, прозрачного автоматического развертывание кода, поддержка разнородных устройств и т.д.поклёп, java код нихрена не веб, но умеет переноситься между машинами, обновляться по сети и поддерживать разнородные устройства. Так что это присуще для всех клиент-серверных приложений.
и вот это больше присуще для веб-приложений, чем для десктоп-приложений.
Что уникального в мобильных приложениях? Так это средство продажи. По сути мобильные приложения - это обыкновенные десктопные приложения, только работающие на рынке с платным и безальтернативным менеджером пакетов. Менеджер пакетов сделал всю работу по дистрибуции мобильных приложений, в результате чего веб потерял одну из своих функций. Так что если ты видишь веб как apt-get, только хуже и платный, то непонятно зачем он тебе будет нужен.
как, например, в виде десктопного софта реализовать фичу "семейный фотоальбом" для семьи мама+папа+два ребенка с возможностьюНу поставьте альфреску, для него были вполне себе десктопные клиенты.
Вся суть в том, что там, где не хватает десктопного софта, должно использоваться клиент-серверное ПО, но вовсе не обязательно облачное.
Кстати, если ты посмотришь на андроид, то заметишь, что он бежит от веба в противоположенном направлении. Гугл разрабатывает свой стандарт представления ГУЯ, свой стандарт хранения и передачи данных, свои абстракции пользовательского окна и фонового процесса. На самом деле андроид сдк предоставляет альтернативу вебу, правда работающую только под андроидом.
в каких реальных сценариях пользователь взаимодействует с этой ОС?Напрямую не взаимодействует почти никогда, а вот косвенно — постоянно. ОС распределяет ресурсы так, чтобы это было незаметно для пользователя, однако же и так, чтобы при этом сохранять, например, заряд аккумулятора.
это не должен делать пользователь, это должно сделать клиентское ПОесли ПО может автоматически спрятать ключ без вмешательства клиента,
то большой брат сможет автоматически оттуда ключ достать
выигрывает среда, которая одновременно мягка к ошибка и дает плюшки за отсутствие ошибок. потому что такая среда собирает нубов, которые в ней же и остаются.Хомячок-ориентированное программирование? Ужжжас.
Смотри, к чему такой подход приводит.
Для начала, у нас есть "стандарт" языка программирования. Он не обязательно должен быть оформлен именно в виде официального стандарта, просто некоторый документ который признан всеми и который описывает язык. Но... внезапно, оказывается что он язык не описывает. Поскольку программы не удовлетворяющие ему (= содержащие ошибки) тоже работают!
Далее, когда у нас оказывается более одного компилятора (интерпретатора внезапно выясняется, что ошибочные программы они обрабатывают по-разному. Итого, у каждого компилятора свой диалект, существенно отличающийся от других диалектов языка.
Собственно смотрим, что сейчас происходит с вебом: сайты написанные криворукими веб-программистами нормально работают в одном браузере и выглядят как говно в другом. Как раз результат того, что нет нормально специфицированного ядра языка, на котором можно писать так, чтобы одинаково работало везде, а говнокод поощряется подходом (пиши как можешь, мы как-нибудь отрендерим твой сайт).
И не нужно говорить про "плюшки". Если у человека хватает самодисциплины, чтобы в такой мягкой системе писать полностью корректные программы, то и сразу начать их писать он сможет. Зато здесь ему приходится полностью самому за этим следить, а там про кучу проблем ему будет сообщать компилятор сразу (автоматизация, однако).
Да и начинать писать на более строгом языке проще. Если ты что-то написал не так, на строгом языке, компилятор сразу ругнулся и сказал где проблема, а на нестрогом все "работает", просто не так, как надо, и поди пойми где и что не так.
если ПО может автоматически спрятать ключ без вмешательства клиента,это верно, если у большого брата бесконечные ресурсы, а это не так.
то большой брат сможет автоматически оттуда ключ достать
Гугл разрабатывает свой стандарт представления ГУЯ, свой стандарт хранения и передачи данных, свои абстракции пользовательского окна и фонового процесса.так это понятно, им надо прямо сейчас уметь писать ПО для мобильников. при этом готовой доступной технологии для этого нет, вот они и изобретают велосипед.
Поскольку программы не удовлетворяющие ему (= содержащие ошибки) тоже работают!так можно надо просто включить в стандарт, как именно происходит восстановление от сбоев и проблема будет решена..
Смотри, к чему такой подход приводит.к чему он приводит - известно, проблема в другом - что обратный подход вообще не работает.
Вся суть в том, что там, где не хватает десктопного софта, должно использоваться клиент-серверное ПО, но вовсе не обязательно облачное.какие преимущества есть у клиент-серверного приложения не оформленного, как веб-приложение?
так можно надо просто включить в стандарт, как именно происходит восстановление от сбоев и проблема будет решена..Т.е. стандарт должен однозначно описывать, как произвольный текст интерпретировать как программу на данном языке программирования?
По-моему проще, действительно, научить программу читать мысли пользователя.
К тому же, как только ты специфицируешь в стандарте поведение в некотором случае, данный случай перестает быть ошибкой как таковой.
к чему он приводит - известно, проблема в другом - что обратный подход вообще не работает.Что-что? Вокруг нас все
Возможность хорошей реализации взаимодействия с ОС и другими клиентскими приложениями.
[Адвокат Дьявола Mode ON]
Fun fact: стандарт HTML5 специфицирует восстановление парсера при ошибках:
Fun fact: стандарт HTML5 специфицирует восстановление парсера при ошибках:
Error handling
An HTML5 (text/html) browser will be flexible in handling incorrect syntax. HTML5 is designed so that old browsers can safely ignore new HTML5 constructs.[citation needed] In contrast to HTML 4.01, the HTML5 specification gives detailed rules for lexing and parsing, with the intent that different compliant browsers will produce the same result in the case of incorrect syntax.[51] Although HTML5 now defines a consistent behavior for "tag soup" documents, those documents are not regarded as conforming to the HTML5 standard.[51]
The HTML spec (versions 5 and previous) define rules for how user agents should handle the rendering of content. To my knowledge, the HTML 5 spec has the richest definition for how exceptional cases should be handled.
Что-что? Вокруг нас все языки программирования "среды" позволяют писать программы с ошибками?то, что ты считаешь, что статически-типизированные программы не имеют ошибок - ты глубоко заблуждаешься.
ошибок не имеет (почти совсем не имеет) какая-нибудь верифицируемая Ада, но так на ней никто и не пишет, кроме каких-то специфичных областей.
Данная ветка обсуждения началась с поста. Там однозначно идет речь про ошибки компиляции/интерпретации. Откуда ты взял здесь статическую типизацию - я не знаю.
Т.е. стандарт должен однозначно описывать, как произвольный текст интерпретировать как программу на данном языке программирования?однозначность как раз необязательна, хочешь однозначности - пиши без ошибок.
необходима локализация ошибок - чтобы ошибка не распространялось дальше определенного контекста.
в частности, одним из надежных языков считается эрланг, потому что там эта работа проделана, и отдельные части кода изолированы друг от друга и ошибки не распространяются сразу на всю работу программы.
Собственно смотрим, что сейчас происходит с вебом: сайты написанные криворукими веб-программистами нормально работают в одном браузере и выглядят как говно в другом. Как раз результат того, что нет нормально специфицированного ядра языка, на котором можно писать так, чтобы одинаково работало везде, а говнокод поощряется подходом (пиши как можешь, мы как-нибудь отрендерим твой сайт).смешались в кучу - кони, люди...
однозначного вывода нет, потому что стандарт при своей разработке не описал кучу разных мелких моментов, к ошибкам это никакого отношения не имеет.
Данная ветка обсуждения началась с этого поста. Там однозначно идет речь про ошибки компиляции/интерпретации. Откуда ты взял здесь статическую типизацию - я не знаю.потому что только статически-типизированные языки (а еще лучше - верифицируемые) обеспечивают задачу, чтобы ошибка не доехала до пользователя, во всех остальных случаях - все ошибки (не объявлена переменная, выход за границу массива, не совпадают типы и т.д.) возникают у пользователя, который с этим ничего сделать уже не может.
За редким исключением, когда "программа" пришла извне и пользователь не имеет возможности ее исправить (ага, веб он именно здесь).в современном мире - 99.9% программ приходит извне, и у пользователя нет возможности их исправить.
в современном мире - 99.9% программ приходит извне, и у пользователя нет возможности их исправить.из этого ведь не следует, что нужно пытаться проектировать виртуальные машины, защищающие от ошибок в программах на уровне машинного кода?
Если отвлечься от html, можешь представить тьюринг-полный язык, обладающий описываемым тобой свойством устойчивости к ошибкам?
Возможность хорошей реализации взаимодействия с ОС и другими клиентскими приложениями.браузер же сам по себе этой задаче не мешает. достаточно включить галку: дать для данного js-приложения доступ к ОС такой же, как для нативного приложения.
Из трех процитированных тобой (первая цитата) предложений, ты два почему-то проигнорировал.
Поэтому повторю еще раз: разговор идет про ошибки компиляции. Они называются "ошибки компиляции" потому что происходят во время компиляции. Еще их называют синтаксические ошибки. И как они могут дойти до пользователя незамеченными я слабо себе представляю.
Поэтому повторю еще раз: разговор идет про ошибки компиляции. Они называются "ошибки компиляции" потому что происходят во время компиляции. Еще их называют синтаксические ошибки. И как они могут дойти до пользователя незамеченными я слабо себе представляю.
выход за границу массива, не совпадают типы и т.д.Это уже ошибки исполнения. Они называются ошибками исполнения потому что возникают во время исполнения. И если разработчик ленив и не протестировал программу, то они действительно могут дойти до пользователя.
не объявлена переменнаяТы ведь имел ввиду не инициализированную переменную, да? Как не объявленная может дойти до пользователя я слабо себе представляю.
браузер же сам по себе этой задаче не мешает. достаточно включить галку: дать для данного js-приложения доступ к ОС такой же, как для нативного приложенияТого, кто такую галку введет в браузер вирусо- и антивирусо-писатели будут боготворить. Быть может даже часовенку построят в его честь.
А здравомыслящие люди будут хотеть расстрелять, но кто же им даст.
из этого ведь не следует, что нужно пытаться проектировать виртуальные машины, защищающие от ошибок в программах на уровне машинного кода?нужно, конечно.
или ты предпочитаешь, чтобы от таких ошибок падали самолеты, взрывались ракеты, а стиральная машинка плевалась кипятком у тебя на кухне в тебя и твоих детей?
> Если отвлечься от html, можешь представить тьюринг-полный язык, обладающий описываемым тобой свойством устойчивости к ошибкам?
устойчивость к ошибкам достигается построением устойчивой структуры программы, язык же может помогать (или мешать) такую структуру строить (в частности, exception-ы вместо кода ошибки, foreach вместо goto и т.д. - упрощают построение такой структуры).
Того, кто такую галку введет в браузер вирусо- и антивирусо-писатели будут боготворить. Быть может даже часовенку построят в его честь.такая галка есть во всех браузерах, но при этом сделано так, чтобы эту галку мог включить только подкованный человека. в ряде браузеров необходимо сначала поставить плагин, в ряде - запустить с определенными опциями, где-то пересобрать браузер и т.д..
А здравомыслящие люди будут хотеть расстрелять, но кто же им даст.
в частности, можно взять Chromeless Browser - это как раз и есть браузер с доступом к ОС.
Поэтому повторю еще раз: разговор идет про ошибки компиляции. Они называются "ошибки компиляции" потому что происходят во время компиляции. Еще их называют синтаксические ошибки. И как они могут дойти до пользователя незамеченными я слабо себе представляю.что такое ошибки компиляции для скриптовых языков?
> Они называются ошибками исполнения потому что возникают во время исполнения.
ага, а масло - масленное.
это ошибки исполнения только в таких бедных языках, как C/C++, java, c# (и уж тем более в скриптах например. в верифицируемых языках, в частности в ATS - эти ошибки возникают при компиляции на фазе верификации программы.
> Ты ведь имел ввиду не инициализированную переменную, да? Как не объявленная может дойти до пользователя я слабо себе представляю.
открой для себя языки: js, php, python, bash и т.д. (или любые другие скриптовые)
> Ты ведь имел ввиду не инициализированную переменную, да?
опять же неинициализированная переменная может дойти до пользователя в C/C++, но не может в c#.
зы
вообще, я вижу - что ты знаешь только 1-2 языка и соответственно весь мир судишь, исходя из знаний этих двух языков, и из того как эти 1-2 языка устроены.
нужно, конечно.с такой точки зрения среды уже есть (тот же nacl но они не могут исправить ошибку (в смысле выдать верный результат максимум, что они могут — не пустить программу сломать что-то чужое, а допереть, как программа, по идее, должна работать, им не под силу.
или ты предпочитаешь, чтобы от таких ошибок падали самолеты, взрывались ракеты, а стиральная машинка плевалась кипятком у тебя на кухне в тебя и твоих детей?
язык же может помогать (или мешать) такую структуру строить (в частности, exception-ы вместо кода ошибки, foreach вместо goto и т.д. - упрощают построение такой структуры).это кажется функциями мощного ide: такие контекстные подсказки "не забудь обработать исключение", проверка синтаксиса на лету. Где тут восстановление от ошибок?
Инструменты, позволяющие отловить разные ошибки полуавтоматически существуют, но они не умеют сами их исправлять, вариантов слишком много.
с такой точки зрения среды уже есть (тот же nacl)nacl не защищает от ошибок в самом nacl (например, от того, что разработчики nacl забыли про какие-то недокументированные возможности каких-то инструкций). или другими словами nacl дает только один уровень защиты - соответственно, если по каким-то причинам он протекает, то дальше следует полный отказ.
, но они не могут исправить ошибку (в смысле выдать верный результат максимум, что они могут — не пустить программу сломать что-то чужое, а допереть, как программа, по идее, должна работать, им не под силу.программирование пошло из математики, и поэтому часто неявно считается, что верным может быть только точный результат.
в физике(и тем более - в задачах, еще более близким к практике) верным считается ответ и с понижением точности.
возьмем, например - машину. верная(исправная) машина - это двигатель работает && тормоза работают && лампочка правой передней нижней фары работает.
дальше если произошла ошибка в фаре (возникло замыкание) - то верным считается ответ: двигатель работает && тормоза работают.
ошибка (пробитый цилиндр) - делает верным ответ: тормоза работают.
вот это устойчивая система: для каждой ошибки зафиксировано к какому понижению точности правильности ответа она приводит.
> они не могут исправить ошибку (в смысле выдать верный результат
могут исправить и до точного результата. в частности, в критических задачах (самолеты и т.д.) используется троирование (для одной и той же задачи используется три модуля написанных тремя разными командами) - и если в одном модуле ошибка, то она исправляется с помощью двух других.
для декларативных программ (которые знают каким должен быть результат) возможны более сложные схемы резервирования: когда ошибочный модуль подменяется другим с падением производительности (например, если диагностирована ошибка в процессоре в функции деления, то эта инструкция может быть заменена на "ручную" функцию деления, которая делит в столбик используя функции процессора +/-,* и т.д.)
> программирование пошло из математики, и поэтому часто неявно считается, что верным может быть только точный результат.
я думаю, это более четко определяется тем, что все абстракции восходят к машине тьюринга, которая детерминированна.
> то она исправляется с помощью двух других.
это защита от аппаратной ошибки, программа там уже доказана.
я, по-моему, уже спрашивал: можешь привести пример некоторого языка (пусть не во всех деталях который исправляет какую-нибудь ошибку, при этом это язык программирования, а не разметки?
я думаю, это более четко определяется тем, что все абстракции восходят к машине тьюринга, которая детерминированна.
> то она исправляется с помощью двух других.
это защита от аппаратной ошибки, программа там уже доказана.
я, по-моему, уже спрашивал: можешь привести пример некоторого языка (пусть не во всех деталях который исправляет какую-нибудь ошибку, при этом это язык программирования, а не разметки?
то кажется функциями мощного ide: такие контекстные подсказки "не забудь обработать исключение", проверка синтаксиса на лету. Где тут восстановление от ошибок?сетевой сбой - это ошибка или нет? и способ восстановления стандартный - попробовать еще раз. и здесь помогают исключения, делая такой способ восстановления простым.
void OnClickButton(..)
{
Try=>server.GetData;
}
T Try<T>(Func<T> f, int tryCount = 3)
{
for (int i = 0; i < tryCount; ++i)
{
try
{
return f;
}
catch (NetworkException exc)
{
if (i == tryCount - 1)
throw;
}
}
}
это программист сам заложил логику, что нужно сделать 3 попытки и потом отвалиться. или программист написал только первые 4 строчки, а остальное додумал компилятор?
открой для себя языки: js, php, python, bash и т.д. (или любые другие скриптовые)В этих языках объявлять (declare) переменные вообще не нужно. Откуда там могут взяться не объявленные переменные, если там такого понятия не существует?
опять же неинициализированная переменная может дойти до пользователя в C/C++, но не может в c#.Ты начал неспешно опровергать свои более ранние утверждения? Молодец, хвалю.
зызы
вообще, я вижу - что ты знаешь только 1-2 языка и соответственно весь мир судишь, исходя из знаний этих двух языков, и из того как эти 1-2 языка устроены.
вообще я вижу - что ты не читаешь посты на которые отвечаешь, а еще и головой не думаешь, когда пишешь
Кстати, про 1-2 языка программирования ты ошибся.
это защита от аппаратной ошибки, программа там уже доказана.ню-ню, верификация (доказательство) кода не защищает от ошибок в спецификации. при этом для многих задач - спецификация кода больше самого кода, а т.к. кол-во ошибок пропорционально размеру, то в такой спецификации их больше, чем в самом коде.
и тот же Ариан-5 долбанул в 94-ом из-за ошибки в спецификации, а не из-за аппаратной ошибки.
вообще, при построении устойчивых систем используется то, что для каждой подсистемы можно оценить вероятность обнаружения еще одной ошибки, в частности через закономерность - чем меньше система, и чем дольше и шире она уже эксплуатируется без ошибок, то тем меньше вероятность наличия в ней еще одной ошибки.
и целиковая система строится так, чтобы:
во-первых, все модули были изолированы друг от друга,
во-вторых: чтобы критически-важные узлы были построены из подсистем для которых оценка наличия ошибки самая низкая,
и такая система защищает от большого кол-ва и ошибок спецификации, и от аппаратных ошибок.
В этих языках объявлять (declare) переменные вообще не нужно. Откуда там могут взяться не объявленные переменные, если там такого понятия не существует?а ключевое слово var в js для чего необходимо? или что делает строка error_reporting(E_STRICT); в php?
зы
объявлять нужно, но большинство интерпретаторов используют технику восстановления от таких сбоев - считая, что необъявленная переменная и неинициализированная переменная - является объявленной и инициализированной значением по умолчанию.
или программист написал только первые 4 строчки, а остальное додумал компилятор?а в чем разница?
и то, и другое - описывается простым алгоритмом: если в трассе исполнения есть использование модулей, которые подтверждены случайным сбоям, то для восстановления после сбоя можно использовать алгоритм повторного вызова.
нужен ли для реализации этого алгоритма профессионал с 10-ти летним опытом и тремя высшими образования или достаточно простого автоматного алгоритма зависит только от самого языка: насколько в коде достаточно информации, чтобы это правило можно было применить автоматически.
если в языке кол-во трасс исполнения растет экспонециально даже для простого кода, и даже библиотечные функции не имеют спецификаций своего поведения, то никакой самый умный компилятор уже не поможет.
просвятите
и такая система защищает от большого кол-ва и ошибок спецификации, и от аппаратных ошибок.Опять же, защита заключается в откате на некое стандартное поведение. Например, при сложении двух чисел происходит переполнение, но программа не падает, однако, если программист имел ввиду сложение по модулю, Наличие спецификации (из которой можно выводить некоторые суждения) — это уже другой уровень, я предполагал наличие некоторой программы как набора инструкций.
и то, и другое - описывается простым алгоритмом: если в трассе исполнения есть использование модулей, которые подтверждены случайным сбоям, то для восстановления после сбоя можно использовать алгоритм повторного вызова.а если функция может выдать неверный результат со второго раза? или вообще не выдать, или у нас ОСРВ, и лишнего времени нет, потому что предыдущая функция сработала только с 5го раза? Не уверен, что все возможные варианты использования программы возможно предусмотреть в компиляторе.
а ключевое слово var в js для чего необходимо?ок, с js промахнулся. Тем не менее, по отношению к трем другим языкам мое утверждение остается верным.
зыНе буду говорить про php, ибо писал на нем слишком мало, но в bash и python просто нет синтаксических конструкций для объявления переменной. То, что некоторое первое присваивание в своей программе ты сам можешь считать объявлением - это уже логика тебя как программиста, но никак не свойство языка. Еще ты можешь вспомнить про 'global' в питоне, но едва ли это можно считать объявлением переменной.
объявлять нужно, но интерпретатор использует технику восстановления от такого сбоя - считая, что необъявленная переменная и неинициализированная переменная - является объявленной и инициализированной значением по умолчанию.
А так да, почти любая программа есть ошибка, ибо процессор ее не может выполнить, но у нас есть компилятор/интерпретатор, которой использует процедуру восстановления от такого сбоя и превращает ее в поток машинных инструкций.
Мой тезис, в целом, следующий: восстановление от ошибок возможно реализовать, отказавшить от значительного количества свобод. Например, если воспользоваться сборщиком мусора, то в общем, можно посчитать, что это защитит нас от ошибок с повторным освобождением памяти, но наложит другие ограничения (например, недетерминированность по времени выполнения). Соответственно, чем более сложная защита, тем больше будет ограничений, т.е. "с ошибками" можно будет писать очень простые программы (которые опытный программист сможет написать и без ошибок). А инструмент должен быть продуктивным в руках профессионала, иначе он останется уделом новичков.
например, недетерминированность по времени выполненияА к ARC в Objective-C ты как относишься?
Опять же, защита заключается в откате на некое стандартное поведение.не фальсифицируемое утверждение. в частности, термин "стандартное".
лучше сказать, что откат заключается в переходе на поведение, которое меньшее из зол. в частности, при этом меньшим из зол является вариант, когда происходит наименьшее схлопывание информации.
рассмотрим программу с ошибкой как композицию двух функций: Fвостановление-от-ошибки * Fс-ошибкой.
если Fс-ошибкой схлопывает информацию (например, содержит функцию halt, которая все множество программ с ошибкой переводит в 32бита-информации то восстановить ничего уже нельзя.
если же Fс-ошибкой возвращает всю информацию (в частности, каким будет ответ если сделать те или иные допущения, и какие были при этом сделаны допущения то функция восстановления после сбоя может использовать уже большое кол-во алгоритмов восстановления после сбоя.
Например, при сложении двух чисел происходит переполнение, но программа не падает, однако, если программист имел ввиду сложение по модулю,в идеале, при наличии соответствующих ресурсов - здесь вообще можно разветвить исполнение и посчитать оба варианта, и пусть функция восстановления сама разбирается какой вариант более правильный.
А к ARC в Objective-C ты как относишься?я на objective c не программировал, так что точно ответить не могу, но судя по тому, что я прочитал, там нужно определенным образом работать с циклическими ссылками, т.е., либо считать, что они могут в любой момент исчезнуть, либо управлять ими вручную (__unsafe_unretained). То есть, это полуавтоматический инструмент, если пользоваться только им, это ограничит сложность реализуемых программ.
в идеале, при наличии соответствующих ресурсов - здесь вообще можно разветвить исполнение и посчитать оба варианта, и пусть функция восстановления сама разбирается какой вариант более правильный.Дело не в ресурсах а в логике. Например, в программе возникло деление на 0 — недопустимая ситуация, программа завершается. Но вдруг программист хотел, чтобы при нуле результат деления был равен первому аргументу. А может единице или π? Эту информацию нельзя извлечь из исходной программы, это извлекается либо из метаинформации (спецификации, например либо пишется непосредственно, это и есть алгоритм. Перебор всяких вариантов может помочь, но в ограниченном количестве случаев, в других случаях такой подход может сделать только хуже.
Если логика идет из спецификации, то там, опять же, вступают в силу машинные ограничения, даже на функциональных языках очень легко написать программу, которая хоть и корректна (с т.з. итогового результата но выполняется невероятно медленно.
а если функция может выдать неверный результат со второго раза? или вообще не выдать, или у нас ОСРВ, и лишнего времени нет, потому что предыдущая функция сработала только с 5го раза? Не уверен, что все возможные варианты использования программы возможно предусмотреть в компиляторе.ты считаешь, что все эти варианты учитывает программист когда пишет программу? серьезно?
проблема в том, что программист способен обработать на несколько порядков меньше вариантов, чем компилятор.
при этом компилятор дополнительно достаточно легко масштабируется еще на несколько порядков для обсчета большего кол-ва вариантов (использование кластера, можно поставить обсчитывать программу хоть на неделю/месяц и т.д.)
ps
опять же проблема в том, что программисты в отличие от инженеров считают, по умолчанию, что в их продуктах нет ошибок, а это не так.
инженер знает, что дом, мост, автомобиль и т.д. имеют кучу "ошибок" (в частности, ошибок вызванных физическим износом, коррозией и т.д.) - и соответственно закладывает охренительный запас прочности, чтобы эти ошибки не привели к критической проблеме.
программист же считает, что ошибок не бывает, и строит программы на соплях, и первый залетевший дятел рушит всю систему.
для кода справедлива средне-потолочная оценка, что 1кб кода содержит одну ошибку. соответственно, если винда имеет 2гб кода, то значит там 2миллиона ошибок, если NaCl имеет спецификацию в 40кб, значит там 40 ошибок.
и необходимо строить код так, чтобы он оставался работоспособным не смотря на эти ошибки, которые в нем присутствуют.
Знаете, мне сейчас кажется, что RMS бегает по аудтории, подпрыгивает, грызёт ногти на ногах, и говорит всем: "а я вас предупреждал"
fixtd
соответственно закладывает охренительный запас прочностипро заклад прочности я дальше немного написал (про производительность) — действительно, невозможно защититься от всех возможных ошибок, вопрос в стоимости.
Но вдруг программист хотел, чтобы при нуле результат деления был равен первому аргументу.помнишь ранее говорилось, что кол-во ошибок растет от кол-ва кода? из этого следует, что для программы необходимо иметь следующих набор спецификаций :
спецификация в 1 терм - что такое правильная программа на данном уровне точности;
спецификация в 3 терма - что такое правильная программа на данном уровне точности;
спецификация в 8 термов - --//--
спецификация в 20 термов - --//--
...
спецификация в 400кб термов
код в 1мб термов
имея такой набор спецификаций, можно достаточно достоверно восстановить, что действительно хотел программист когда пропустил деление на 0.
Например, если воспользоваться сборщиком мусора, то в общем, можно посчитать, что это защитит нас от ошибок с повторным освобождением памяти, но наложит другие ограничения (например, недетерминированность по времени выполнения).тут возникает вопрос уместности.
если программа уже использует функции для обращения по сети, или файловые операции, то говорить о какой-то детерминированности по времени можно уже только с некой точностью, например, что время работы будет не больше таймаута T, если GC обеспечивает тот же порядок временной детерминированности, то не понятно откуда взялось утверждение про ограничение свобод.
ты считаешь, что все эти варианты учитывает программист когда пишет программу? серьезно?А зачем тогда вообще нужен программист? Пусть компилятор пишет программу.
проблема в том, что программист способен обработать на несколько порядков меньше вариантов, чем компилятор.
при этом компилятор дополнительно достаточно легко масштабируется еще на несколько порядков для обсчета большего кол-ва вариантов (использование кластера, можно поставить обсчитывать программу хоть на неделю/месяц и т.д.)
для кода справедлива средне-потолочная оценка, что 1кб кода содержит одну ошибку. соответственно, если винда имеет 2гб кода, то значит там 2миллиона ошибок, если NaCl имеет спецификацию в 40кб, значит там 40 ошибок.Я думаю для кода, написанного одним программистом, закрытого кода, написанного группой программистов и для открытого кода разрабатываемого большим комьюнити программистов эта оценка будет сильно отличаться.
и необходимо строить код так, чтобы он оставался работоспособным не смотря на эти ошибки, которые в нем присутствуют.Ну это уже обсуждалось в .
А зачем тогда вообще нужен программист? Пусть компилятор пишет программу.программист необходим чтобы сформулировать задачу, или другими словами - специфицировать, что есть правильный результат при том или ином уровне точности. для остального, в худшем достаточно кодировщика, в лучшем - компилятора.
ок, с js промахнулся. Тем не менее, по отношению к трем другим языкам мое утверждение остается верным.что делает опция set -o nounset для bash?
или что делает строка error_reporting(E_STRICT); в php?
почему питон выдает ошибку (причем не unset, а именно not defined)?
результат: Ошибка выполнения время: 0.03s память: 5860 kB сигнал: -1
File "prog.py", line 1, in <module>
x * 3;
NameError: name 'x' is not defined
Кстати, про 1-2 языка программирования ты ошибся.программирование на большем кол-ве языков должно быть дать понимание, что деление ошибок на ошибки компиляции/исполнения зависит от языка, и не зависит от самого вида ошибки.
и не писать чуши:
что синтаксические ошибки для произвольных языков являются ошибками компиляции
Они называются "ошибки компиляции" потому что происходят во время компиляции. Еще их называют синтаксические ошибки.или что выход за массив и несовпадение типов есть для любого языка ошибкой исполнения
выход за границу массива, не совпадают типы и т.д.или что ошибку "undefined variable" для произвольного языка не может увидеть пользователь
Это уже ошибки исполнения.
Как не объявленная может дойти до пользователя я слабо себе представляю.
"not defined", а не "not declared". Это именно инициализированность проверяется.
set -o unset в баше заставляет его трактовать использование неинициализированной переменной как ошибку. Опять нет ничего про объявление.
Заметь, я сразу предположил, что ты имел ввиду именно это.
set -o unset в баше заставляет его трактовать использование неинициализированной переменной как ошибку. Опять нет ничего про объявление.
Заметь, я сразу предположил, что ты имел ввиду именно это.
Это именно инициализированность проверяется.это вкусовщина терминологии.
в таких языках ситуация, что переменная используется до ее объявление/инициализации отображается на две ситуации из других языков (переменная задекларирована; переменная задекларирована, но не инициализирована)
соответственно, обе трактовки этой ситуации - и второй и первый способ - одинаково верны.
Желаешь попридираться к словам? Лучше вникай в смысл того, что тебе говорят. В контексте много чего изменится.
Так например, какой смысл упоминать про случаи, когда несовпадение типов отлавливается при компиляции, если мы строчкой выше уже выяснили, что ошибки компиляции нам в данном случае не интересны? Позанудствовать? Или поумничать?
Так например, какой смысл упоминать про случаи, когда несовпадение типов отлавливается при компиляции, если мы строчкой выше уже выяснили, что ошибки компиляции нам в данном случае не интересны? Позанудствовать? Или поумничать?
соответственно, обе трактовки этой ситуации - и второй и первый способ - одинаково верны.Я изначально пытался выяснить, какую же трактовку ты имел ввиду. В ответ на это ты начал мне доказывать, что моя трактовка неверна, а в ЯП я ничего не понимаю.
Желаешь попридираться к словам? Лучше вникай в смысл того, что тебе говорят. В контексте много чего изменится.я хочу, чтобы человек представлял границы своих утверждений.
например, ты начал с деления на стадии компиляции и исполнения, и при этом неявно использовал, что ошибки компиляции не возникают у пользователя - при этом это верно только для достаточно узкого класса программ, которые не используют генерацию кода в рантайме.
А началось все совсем не с этого. А вот с чего:
--------
ты:
нужна устойчивость к ошибкам в коде
айвенго:
вау. А писать так, чтобы компилировалось не пробовали?
ты:
это создает высокий порог входа, а в быстро-развивающемся мире среда с высоким порогом входа сразу скатывается на обочину.
выигрывает среда: в которой можно делать и проги с ошибками, и без ошибок - при том, вторые работают быстрее и лучше, чем первые.
айвенго:
Если бы говнокод не поддерживался на государственном уровне, в условиях либертианства вторая среда бы проиграла
ты:
как раз нет. чем больше свободы, тем быстрее выигрывает среда, которая одновременно мягка к ошибка и дает плюшки за отсутствие ошибок. потому что такая среда собирает нубов, которые в ней же и остаются.
--------
Именно на сформулированные тобой в этом диалоги тезисы я и отвечал. Именно этого контекста и придерживался. Тем не менее далее ты почему-то игнорировал данный контекст, внес откуда-то пользователя, начал обобщать все на все.
--------
ты:
нужна устойчивость к ошибкам в коде
айвенго:
вау. А писать так, чтобы компилировалось не пробовали?
ты:
это создает высокий порог входа, а в быстро-развивающемся мире среда с высоким порогом входа сразу скатывается на обочину.
выигрывает среда: в которой можно делать и проги с ошибками, и без ошибок - при том, вторые работают быстрее и лучше, чем первые.
айвенго:
Если бы говнокод не поддерживался на государственном уровне, в условиях либертианства вторая среда бы проиграла
ты:
как раз нет. чем больше свободы, тем быстрее выигрывает среда, которая одновременно мягка к ошибка и дает плюшки за отсутствие ошибок. потому что такая среда собирает нубов, которые в ней же и остаются.
--------
Именно на сформулированные тобой в этом диалоги тезисы я и отвечал. Именно этого контекста и придерживался. Тем не менее далее ты почему-то игнорировал данный контекст, внес откуда-то пользователя, начал обобщать все на все.
Тем не менее далее ты почему-то игнорировал данный контекст, внес откуда-то пользователя,вот этот утверждение не понятно, потому что ранее под средой понималась среда, которая отвечает за взаимодействие между программистом и пользователем.
или другими словами взаимодействие между программистом и пользователем можно представить как:
есть программист - он пишет код и запихивает его в черный ящик,
есть пользователь - который решает какую-то свою задачу, доставая из этого же черного ящика инструменты, которые необходимы для решения задачи пользователя (и которые как-то были сформированы из того кода, который запихал в черный ящик программист).
вот этот черный ящик и есть среда из цитаты.
соответственно, если эта среда позволяет использовать пользователю для успешного решения задач пользователя даже черновые полуфабрикаты программиста (с ошибками и т.д.) , то развитие идет быстро за счет быстрой обратной связи;
если не позволяет, то развитие идет очень медленно.
зы
и здесь, в частности, проявляется, например, разница между скриптовыми языками и компилируемыми языками.
(при этом скриптовый вариант кода, можно рассматривать как компилируемый вариант кода, к которому добавили ряд способов восстановления от сбоев компиляции)
например, не полностью написанное решение на компилируемом языке часто не может быть скомпилировано, и соответственно не может использовать пользователем вообще.
недописанное скриптовое же решение - может уже использоваться хотя бы на небольшом множестве задач, стоящих перед пользователем.
при этом готовой доступной технологии для этого нет, вот они и изобретают велосипед.если нет ни одного велосипеда, а есть, скажем, только самокаты, то следует ли удивляться тому, что кто-то наконец изобрел велосипед?
какие преимущества есть у клиент-серверного приложения не оформленного, как веб-приложение?Свобода действий. Веб сковывает, потмоу что его стандарты неудобны для общего применения. Веб удобен для информационных приложений, но не для выражения произвольного десктопного приложения. Для этого нужен какой-то другой стандарт, другое middleware, у которого с вебом будет только одна схожесть - они оба стандарты middleware. Тот же самый андроид API учёл кучу проблем веба, если им пытаться заменить приложение, выбрал более удобный язык программирования, чем js (потому что практически любой язык удобднее js учёл так же физические особенности устройств ввода-вывода и стал гораздо удобнее для написания программ для мобильников чем веб.
Ну и наконец, WoW - это клиент-серверное приложение, попробуй оформить его как веб-приложение, мне будет интересно на это посмотреть.
И да, должны сохраниться основные преимуещства веба - рабочие ссылки на каждую страницу, возможность скопировать текст и изменить внешний вид посредством css. Единственное, для чего на мой взгляд хватит веба, - это распространения вова, возможность его скачать и запусть одной кнопкой из браузера. Но ты думаешь иначе и мне интересно узнать какой путь для превращения клиента ВоВа в веб-приложение ты видишь
Я вообще не понимаю, каким образом разговор перешёл к абсолютному обнаружению всех ошибок? Изначально я говорил, что хорошие языки позволяют найти больше ошибок на этапе компиляции, больше а не все. Более того, из-за сравнения хороших языков с убогим js, подразумевалось что от улучшения поиска ошибок не страдает выразительность языка.
программист же считает, что ошибок не бываетименно поэтому программисты изобрели статические анализаторы и модульное тестирование
Вообще до встречи с тобой, я видел только программистов, которые априори считают любую программу ошибочной и постоянно практикуют ту или иную методику борьбы с ненайденными ошибками
например, не полностью написанное решение на компилируемом языке часто не может быть скомпилировано, и соответственно не может использовать пользователем вообще.неверно. Вот я пользователь и имею пару ебилдов в локальном реопзитории, которые перед сборкой патчили ошибочные программы, написанные на компилируемом языке
И да, в самом коде я не разбирался, заплатки наложил грязно и поверх
именно поэтому программисты изобрели статические анализаторы и модульное тестированиевот именно что они ведут лицемерную борьбу: мы используем супер-мега технологию, и поэтому в нашем ПО нет ошибок.
Вообще до встречи с тобой, я видел только программистов, которые априори считают любую программу ошибочной и постоянно практикуют ту или иную методику борьбы с ненайденными ошибками
ой, пользователи нашли ошибку? вот вам патч, и уж теперь у нас точно нет ошибок, это была последняя. пользователи опять нашли ошибку? вот вам еще один патч и вообще, мы уже используем супер-мега-технологию 2 и поэтому ошибок уже совсем нет. ой, хакеры нашли ошибку?..
и всё это - вместо того чтобы встать и признаться: в наших программах есть ошибки, мы еще не знаем где именно, но они там точно есть, поэтому были предусмотрены такие-то и такие-то шаги, чтобы эти ошибки не портили жизнь пользователю.
вот именно что они ведут лицемерную борьбу: мы используем супер-мега технологию, и поэтому в нашем ПО нет ошибок.Ни разу не видел таких программистов, разве что только маркетологов, но было бы непрелично претензии к маркетологам адресовать программистам?
Все прекрасно понимают, что ошибок просто стало меньше. И все предусматривают механизмы поведения пользователя в случае обнаружения ошибок.
Ни разу не видел таких программистов, разве что только маркетологов, но было бы непрелично претензии к маркетологам адресовать программистам?здесь уже ты лицемеришь, отказываясь признать, что программистам(да, и людям вообще) свойственно считать, что в их коде(в их работе) ошибок резко меньше (и можно считать, что их там нет совсем) по сравнению с кодом(с работой) соседа.
чтобы далеко не ходить, приведу в качестве примера то, что было уже в треде - слова (хотя против него я ничего не имею он как программист утверждает, что есть новая супер-мега технология NaCl в которой нет ошибок безопасности.
И все предусматривают механизмы поведения пользователя в случае обнаружения ошибок.чего? это ты про окно с кнопкой: отправить ошибку программистам?
чтобы далеко не ходить, приведу в качестве примера (хотя против него я ничего не имею он как программист утверждает, что есть новая супер-мега технология NaCl в которой нет ошибок безопасности.я имел ввиду, что технологически NaCl построен таким образом, что защищает от ошибок. Это, конечно, не доказано математически, но дает явно большую уверенность, чем тот же ActiveX.
я имел ввиду, что технологически NaCl построен таким образом, что защищает от ошибок.с этим не спорю.
вопрос в другом - если мы признаем, что в NaCl есть ошибки безопасности, то что сделано для того, чтобы эти ошибки не портили жизнь пользователю (в частности, не приводили к поражению всей системы?)
А что для этого может быть сделано? Если, например, в некотором демоне есть ошибка переполнения буфера, то что можно сделать, чтобы пользователь не пострадал? Разве что на уровне ОС как-то определять эти переполнения. А ещё можно программировать так, чтобы избегать таких ошибок. Думаю, какие-нибудь дампы памяти отправляются разработчикам в случае крэшей — вот и все.
А что для этого может быть сделано?в инженерке для избежания утечки используется паттерн двух пакетов.
жидкость помещается в один пакет, всё это в другой. пространство между пакетами тоже заполняется каким-то индикаторным веществом.
и при этом мониторится попадание жидкости в пространство между пакетами (это означает что пакет 1 один порвался, и включается режим тревоги и попадание индикаторного вещества за пакет 2 (это означает, что протек пакет 2, и тоже включается режим тревоги)
при этом используется, что если вероятность протекания одного пакета за большой период(например, 5 лет) близка к 1, то вероятность протекания двух пакетов за тот же период уже 1/1800(если принять скорость обнаружения и замены пакета - как 1 день). за счет включения тревоги и изменения режима работы в момент тревоги, этот показатель еще на несколько порядков можно понизить.
кстати, такой подход уже в IT используется в виде raid-а.
в переводе на программирование - это означает, что для обеспечения безопасности используется последовательно две разнородные системы. при этом контролируются нарушения первого периметра. Для того, чтобы убедиться, что вторая система не дырявая, она используется как первая (доступная для внешних атак) в других применениях.
Для того, чтобы повысить мотивацию искать дыры только в одной системе (а не сразу в двух одновременно) между двумя периметрами располагаются некритичные системы, которые могут представлять интерес для взлома.
в переводе на браузер это может выглядеть как:
первый периметр - NaCl,
второй периметр - запуск NaCl в виде отдельного процесса с минимумом прав,
пробитие первого периметра позволяет, например, управлять браузером: открывать новые окна, менять их размеры и т.д.
как гарантированно контролировать пробитие NaCl надо подумать.
использование второго периметра в качестве первого допустим не придумали, поэтому он просто выставлен на бессрочный конкурс для взлома за вознаграждение (хотя такой вариант один из самых слабых)
Весь вопрос в том, чем за это придется платить. Здесь я имею ввиду любые связанные затраты и неудобства, в первую очередь время и стоимость разработки, затрачиваемые при работ ресурсы (память, процессорное время скорость работы и время отклика, удобство использования.
Твой "паттерн двух пакетов" не применяется для обычных бытовых предметов: слишком дорого, а цена утечки невелика (ну прохудился чайник, ну натекла лужа - вытер лужу, купил новый чайник).
Это как с безопасностью. Бесполезно рассуждать в черно-белых тонах: опасно-безопасно. Есть риски, есть контрмеры которые призваны эти риски снижать. Абсолютно безопасности не бывает, а контрмеры выбирают те, которые дают приемлемый уровень риска при минимальных затратах. Так, например, большинство людей не считают разумной контрмеру "ходить всегда в каске" как защиту от риска, что кирпич на голову упадет. Неудобств много, а риск невелик (благодаря низкой вероятности). В то же время для строителей это разумная контрмера, потому что там вероятность получить кирпичем по голове уже существенно выше.
Здесь так же: абсолютной защиты от абсолютно всех ошибок не бывает. В зависимости от цены возможной ошибки в программе выбираются те или иные способы им противодействовать. Так например, большинство разработчиков десктопных приложений не считают разумным проводить полное формальное доказательство корректности своих программ (ибо цена ошибки не очень велика в то же время в NASA критичные части программ полностью доказывают (ибо от этого зависят жизни людей). И даже после этого случаются ошибки (забыли проверить что величины передаются в одних и тех же единицах измерения в доказательствах - получили проблемы в 1998 году с Mars Climate Orbiter).
Твой "паттерн двух пакетов" не применяется для обычных бытовых предметов: слишком дорого, а цена утечки невелика (ну прохудился чайник, ну натекла лужа - вытер лужу, купил новый чайник).
Это как с безопасностью. Бесполезно рассуждать в черно-белых тонах: опасно-безопасно. Есть риски, есть контрмеры которые призваны эти риски снижать. Абсолютно безопасности не бывает, а контрмеры выбирают те, которые дают приемлемый уровень риска при минимальных затратах. Так, например, большинство людей не считают разумной контрмеру "ходить всегда в каске" как защиту от риска, что кирпич на голову упадет. Неудобств много, а риск невелик (благодаря низкой вероятности). В то же время для строителей это разумная контрмера, потому что там вероятность получить кирпичем по голове уже существенно выше.
Здесь так же: абсолютной защиты от абсолютно всех ошибок не бывает. В зависимости от цены возможной ошибки в программе выбираются те или иные способы им противодействовать. Так например, большинство разработчиков десктопных приложений не считают разумным проводить полное формальное доказательство корректности своих программ (ибо цена ошибки не очень велика в то же время в NASA критичные части программ полностью доказывают (ибо от этого зависят жизни людей). И даже после этого случаются ошибки (забыли проверить что величины передаются в одних и тех же единицах измерения в доказательствах - получили проблемы в 1998 году с Mars Climate Orbiter).
А ещё можно программировать так, чтобы избегать таких ошибок.вот это непонятное утверждение. это как?
Использовать безопасные функции (_printf_s проверять программы valgrind, например.
Твой "паттерн двух пакетов" не применяется для обычных бытовых предметов: слишком дорого, а цена утечки невелика (ну прохудился чайник, ну натекла лужа - вытер лужу, купил новый чайник).ты взял пример (небольшая лужа) который сам по себе некритичный.
ты лучше возьми критичные примеры: смерть от удара током, пожар и т.д.
и там все это применяется.
например, для защиты от ударов тока одновременно применяется:
УЗО,
использование напряжения, которое обычно не приводит к смертельным повреждениям,
изготовление силового шнура питания как целикового изделия с проверкой, что он выдерживает на разрыв силу в Nкг,
заземление,
скрытие контактов под напряжением от прямого доступа человеком (изоляция проводов, утопление контактов в розетку и т.д.)
ТБ (не менять лампочку при включенном рубильнике и т.д.)
и т.д.
для того, чтобы чайник не вызвал пожар одновременно используется:
он отключается без воды,
используется предохранитель, который расплавляется при перегреве и отключает подачу тока,
так же проверяется, что чайник только плавится, но не загорается при отказе датчика отключения и предохранителя
и т.д.
зы
просто значительная часть подходов была внедрена еще до твоего рождения, поэтому ты считаешь, что это всё само собой разумеющееся (что, например, провода в доме должны быть скрыты изоляцией, а ведь это тоже лишние деньги, лишний материал и т.д.)
программирование молодая отрасль , и поэтому надежность пока менее актуально, чем "а давайте мы еще вот такую офигенную фичу забабахаем!"
Использовать безопасные функции (_printf_s проверять программы valgrind, например.при этом вероятность ошибки пропорциональна кол-ву производимого кода, и это означает, что рано или поздно ошибка появится
зы
при этом если используется другой подход: например, запуск через NaCl, то вероятность ошибки пропорциональна размеру самого NaCl-а, а не кол-ву кода, который через NaCl запускается.
Весь вопрос в том, чем за это придется платить. Здесь я имею ввиду любые связанные затраты и неудобства, в первую очередь время и стоимость разработки, затрачиваемые при работ ресурсы (память, процессорное время скорость работы и время отклика, удобство использования.пока я плохо понимаю, что может быть для пользователя(физика и юрика) критичнее, чем утечка (и потеря) личных данных: банковские счета, ноу-хау, скелеты в шкафу и т.д.
и как это компенсируется тем, что html теперь рендерится не за 300мс, а за целых 200мс? а программа стоит не 100 баксов, а целых 79.99?
пока я плохо понимаю, что может быть для пользователя(физика и юрика) критичнее, чем утечка (и потеря) личных данных: банковские счета, ноу-хау, скелеты в шкафу и т.д.Чтобы это понять, нужно понять разницу между угрозой (threat) и риском (risk). Риск определяется не только потерями в случае происшествия, но и вероятностью его (происшествия).
Чтобы это понять, нужно понять разницу между угрозой (threat) и риском (risk). Риск определяется не только потерями в случае происшествия, но и вероятностью его (происшествия).и в какую вероятность ты, например, оцениваешь риск взлома веб-приложением FireFox-а с получением прав Firefox-а за 5 лет?
или в какую вероятность оцениваешь взлом репозитария *nix за 10 лет?
и т.д.
ты взял пример (небольшая лужа) который сам по себе некритичный.Ну собственно, и что?
<...>
и т.д.
Я никогда не утверждал, что там никаких мер предосторожности не применяется.
Я говорил что конкретная ("паттерн двух пакетов", как ты ее назвал) не применяется.
И, черт побери, она действительно не применяется.
Но да, есть другие контрмеры, которые по соотношению снижение рисков - затраты оказались хороши и применяются.
зыЯ так не считаю. Не нужно считать других идиотами.
просто значительная часть подходов была внедрена еще до твоего рождения, поэтому ты считаешь, что это всё само собой разумеющееся (что, например, провода в доме должны быть скрыты изоляцией, а ведь это тоже лишние деньги, лишний материал и т.д.)
и в какую вероятность ты, например, оцениваешь риск взлома веб-приложением FireFox-а с получением прав Firefox-а за 5 лет?Я не являюсь специалистом в этой области, чтобы давать сколь нибудь авторитетные оценки. Более того, оценка будет отличаться в зависимости от того, кто враги.
или в какую вероятность оцениваешь взлом репозитария *nix за 10 лет?
и т.д.
Если человек опасается хулиганства какого-нибудь случайного школьника - это одно, если же от него что-то нужно спецслужбам - совсем другое. Разумные меры предосторожности в этих случаях тоже будут отличаться.
У меня в данный момент нет врагов, которые бы были готовы тратить время и деньги на взлом моего браузера (да и нет там ничего ценного). Поэтому мне следует опасаться только случайного хулиганства. Для того, чтобы я пострадал, необходимо совпадение: нашли эксплойт в фаэрфоксе, хулиган выбрал меня, он сумел заставить меня открыть зловредный сайт до того, как я обновил браузер. Я решил, что совпадение всех этих событий достаточно маловероятно, чтобы не тратить каких-либо денег на платный "более безопасный" браузер или полностью отключать все скрипты (плагином NoScript например, хотя им я тоже пользуюсь на работе для отрезания рекламы). Единственная дополнительная предосторожность, которую я применяю - не открывать ссылки из спам-писем (они мне все равно не интересны, так что "затраты" нулевые).
Весь тред не осилил, поэтому не знаю было ли: http://ursa-tm.ru/forum/index.php?/topic/21310-
весь тред осиливать и не надо было. Начиная с поста кротишки пошёл флейм
годная ссылка
годная ссылка
Оставить комментарий
yroslavasako
Знаете, мне сейчас кажется, что RMS бегает по аудтории, подпрыгивает и говорит всем: "а я вас предупреждал"То, что раньше называли бредом сумасшедшего, сегодня может стать реальностью.
Две новости на хабре.
То есть интел хвастается своей новой ДРМ-закладкой для работы которой будет достаточно только сайта (наконец-то пользователей линукса перестанут обижать)
Теперь их процессор ещё и wifi умеет.
Складываем дважды два, аппаратные закладки и сеть - и получаем что пользователь интела уже не владелец своего компьютера.
Знаете, а ведь именно об этом любил пошутить RMS. Боюсь, правда, что теперь эти шутки будут уже и не так смешны. А кто знает, может он и с самого начала был серьёзен, когда говорил об угрозах заплаток в cpu.