Dalvik чисто технически другая машина. Это регистровая VM, в отличии от стековой JVM. Здесь совершенно по другому складывается логика. У них своя стандартная библиотека, не особо пересекающаяся с Java. Докопаться могли до алгоритмов уборки мусора и общим управлением памятью, если патенты на это есть. И в принципе все, привязка к нативному коду тоже будет своей из-за специфики машины. Оптимизация байт-кода — это либо что-то общее как у всех, либо заточенное под регистровую VM, тут не должно быть пересечений. Все остальное это либо своя логика, либо реализовано нативно и вне Dalvik.
Похоже победили юристы, а не технари. Гугл изначально сказал, что Android на Java с собственными модификациями, что позволило привлечь кучу народа (о! там Java, я ее уже умею писать под Андроид!). Это маркетинговый ход. У Dalvik больше сходства с Parrot, чем с JVM. Но кого интересуют технические детали, когда пахнет хорошими деньгами?
Yahoo очень старая компания, стоит у истоков сети. Скорее всего у них большой пакет патентов в области поиска, семантической сети и т.д. Получив все это, MS сможет давить на Google. Думаю потому это все и стоит таких раздутых денег (потомки еще посмеются над очередным IT пузырем, на этот раз патенты).
Никак. Через 2-3 недели все забудут, а дальше качественная реклама и все пойдет как надо. Это не первый и не последний «скандал», и не только для Sony. Следствием обычно бывает несущественная рябь на продажах.
Это не так. Весь код на Haskell всегда детерминирован и чист (в рамках логики). К примеру getLine::IO String это всегда одно и то же значение типа IO String, не зависимо от времени или каких либо других сторонних факторов. putStr::String -> IO() всегда возвращает одно и тоже значение типа IO () для одной и той же строки. Выражение:
(getLine >>= putStr)::IO ()
в принципе без выполнения, даже на этапе написания кода, всегда будет возвращать значение типа IO (). Детерминизм, type-safety, верификация, все присутствует и никаких поблажек. А потом пользователь перенесет получившееся значение, в свой «не чистый» мир, глянув в него. И тут открылись файлы, прочитались строки, заработали SOAP соединения со всеми случайными сбоями и т.д. «Чистая» программа к тому моменту уже «отработала», выдав одно из бесконечно возможных значений типа IO (). А значение — это один из бесконечно возможных сценариев работы императивной программы со всем вводом и выводом. С некоторыми оговорками можно сказать, что переход из «чистого» мира происходит когда Haskell программа транслируется в C/машинный код (императивный, шаг за шагом код), результат которого наоборот зависит от окружающей обстановки. А монады (типы, о которых мы можем ничего не знать, кроме определенных операций >>=, return и т.д.), позволяют завернуть понятие «все возможные значения/сценарии Х» в некоторое не известное значение монадного типа.
Не все монады «не известны». Maybe тоже монад (тут важно наличие конструктора типов, операций >>=, return, fail etc) со вполне известными вариантами. Просто монады, помимо других задач, элегантно решают проблемы не детерминированного мира (позволяют не знать о себе ничего).
Для кого все три статьи остались неясны, монады проще понять «на пальцах».
Пусть есть некоторый алгебраический тип, к примеру:
data Maybe a = Nothing | Just a
Мы знаем из чего состоит тип, значит можем на прямую рассмотреть case value of с альтернативами для Just a и Nothing. Исходя из этих знаний, мы можем сделать функцию f::Maybe a -> a, выдав значение по умолчанию для Nothing. Это чистые значения.
А теперь представим что есть некий алгебраический тип, о котором мы ничего не знаем, только лишь конструктор. Значит f::IO String действительно может быть какой угодно альтернативой в IO, о которой мы ничего не знаем. Это может быть прочтенная строка с консоли, ошибка, что угодно. Заметим, что мы даже не можем предполагать, что значение с типом IO String это действительно какая то альтернатива IO, нет это всегда одно значение, но оно «многолико». Именно поэтому getLine::IO String это значение (функция без аргументов), которое может «прочесть любую строку с консоли» — прочтенная строка будет строкой/ошибкой/etc для наблюдателя (наблюдатель не находиться в «чистом» мире), в самой программе оперируется чистое значение «все возможные варианты IO» (ключевые: суперпозиция, посыл к квантовой физике)
Раз мы не знаем что есть в IO или в любом другом «неизвестном типе»/монаде, значит нельзя что либо сделать со значением IO a. Для этого и есть оператор применения >>=, который достает а из монадного значения и применяет ее к функции f::a -> IO a если это возможно. Иначе (если к примеру IO String был ошибкой, а не прочитанной строкой) возвращает новое значение IO a, о котором мы ничего не знаем. Именно потому, что >>= может вернуть IO a «в обход» нашей f, f должна возвращать IO a. Т.е. однажды «испачкавшись» в монадах вы увязли до самого конца программы. В функциональной программе нет времени, т.е. нельзя стать наблюдателем и посмотреть что там в монадном значении (unsafe функции, те которые при «исключительных» значениях «не знают что делать» и оставлены на совесть программисту, мы не рассматриваем. это хак малодушных :), это не Haskell), значит нельзя избавиться от монада. На самом деле программа на Haskell всегда, не зависимо от времени, окружающего мира и т.д. отдает IO (), «многоликое» неизвестное значение, и завершается, мгновенно. После работы программы мы в своем мире с side-effects наблюдаем за полученным значением с типом IO () и видим один из «выпавших» вариантов: вывод на консоль, окошки и т.д. Даже если программа работает несколько суток, общается с пользователем и выкачивает чего из интернета, все равно в «чистом мире» Haskell программа уже отработала и вернула нам IO () со всем что мы видим, можем ввести и можем получить результат обратно. Там нет времени, там нет side-effects :)
Заметим, что зная тонкости внутренней реализации ввода/вывода (или любой сторонней либы, чего угодно), можно написать к примеру hasFailed::IO а -> Bool. Но это совсем не хорошо, т.к. из всего «бесконечного» множества вариантов IO a мы вдруг получили Bool, который всегда True | False, не зависимо от действий внешнего мира и времени. Таких функций быть не должно, это unsafe функции. Но может быть hIsClosed::Handle -> IO Bool, применяемая к IO Handle. Тогда логика скрыта в Handle, если там не что-то еще из бесконечного множество «чего то еще». Получил IO Bool мы можем сделать свою логику f::Bool -> IO SomethingElse или дальше катиться в потоке IO SomethingElse. Это может сносить немного крышу. Что бы это понять попробуйте представить, что ваша программа может дать верные результаты или выпасть с ошибками — это все «известные» результаты; либо уборщица шваброй выдернет питание и все накроется — это «не известные» результаты, одно из не подвластных вам проявлений IO SomethingElse. Функциональный мир при этом остается чист и детерминирован.
Что-то мне подсказывает, что еще будут об этом писать…
Стандарты это хорошо, но реализация часто хромает. Если сейчас сделать все грамотно и перетаскивать локальные файлы будет не возможно, то завтра кто-то в браузер встроит плагин, где в окне будут открыты файлы из какого-нибудь cloud хранилища. И как фичу сделают возможность перетаскивать эти файлы (все события, dataTransfer интерфейсы и т.п.). Вдруг внезапно «откроется брешь в безопасности».
Нельзя предусмотреть все варианты, просто потому, что софт меняется. В последнее время браузеры стараются не спрашивать пользователя о скрытых запросах и процессах. На мой взгляд проблема реальна.
P.S. я думал карма ь это отношение участников к адекватности автора, а не оценка его взглядов. «Заминусованный» пользователь потеряет возможность писать, «неугодная» точка зрения исчезнет. Жалко смотреть во что превратили карму.
Похоже на удобный способ выкачивать скрытно у пользователя его приватные файлы (пароли и т.п.) просто предлагая сыграть в puzzle-подобную игрушку. Под курсор ставим скрытый iframe с локальным file://URL и даем перетаскивать все подряд к нам. А если не только файлы, но и букмарки/прочее таким образом можно будет перетаскивать, то откроется большое поле для сбора приватной инфы.
Я не скептик, но как то с опаской смотрю на такие нововведения…
А как в 2011 году можно заразиться подобным без ведома пользователя? При условии, что он не скачивает неизвестный софт из сети, не ставит левые плагины в браузер (только «проверенные временем» вещи AdBlock, Firebug etc) и вообще с недоверием относится ко всему в сети.
Конечно возможен сценарий, где репозиторий популярного плагина взломали, дописали вредного кода и тихо позволили разработчикам это все опубликовать. Но это надеюсь когда-нибудь пофиксят в браузере, задавая определенным адресам возможность отключать все плагины.
Просто как обычный пользователь чувствуешь себя в поле окруженном граблями, следишь за каждым своим шагом и начинаешь думать «ну почему все так через ж*пу...?»
<input type="email" name="email" required />
Тут либо лишний '/', либо на required парсер должен споткнуться. Неясно зачем смешивать синтаксисы HTML и более строгого XML. Надеюсь автор просто ошибся.
> ну, что с убогих взять?
Подобное явно не будет привлекать новых пользователей к рамблеру. Скорее заставит уйти и не возвращаться, если работники компании делят аудиторию на «убогих» и себя/богов/кого-угодно.
У него будут полные авторские права на фотографию, т.е. право ее распространения. А фотографировать можно что угодно, кроме частной жизни и военных объектов. Даже промышленный шпионаж нельзя прикрутить, если человек сфотографировал чертежи и не отдал/продал их тому, кто в последствии (обязательное условие) получил от этого выгоду.
xrange(width) это генератор, а range(width) даст список. Создание генератора довольно простая вещь, тем более он сам себе и итератор. Пробег по списку создаст скрытый итератор в цикле. К тому же при ощутимо большом width будем сильно потреблять память.
Прежде чем перекапывать кучу кода, да ограничивать себя утилитах/подходах, может стоит взглянуть на что-то более совершенное? К примеру python+django+celery (задеплоенный под gunicorn). В связке с postgresql+redis будет летать.
Статью я дочитал, просто заинтересовали коментарии «Давно я не слышал о столь изящных вирусах» и подобное. Здесь затронут не только человеческий фактор (перенос зараженной флешки), сколько:
- автоматический запуск приложений с флешки (autorun), который ну никак не должен работать на подобного рода компьютерах (да и вооще редко где нужен).
— работа человека с привилегиями админа, позволяющими (за)(из)менить либы Step 7 (кстати, это не ОС, просто редактор логики/IDE, впрочем и название всей линейки контроллеров, работал с ними год)
Иными словами, не будет этих двух пунктов и человеческий фактор уже не сработает. Хоть порнушку запускай, сам, пока не повысишь свои привилегии, нет проблемы. Так что на мой взгляд проблема — windows и ее специфика работы, а на втором месте уже «человеческий фактор». Другой вопрос, что винду можно настроить корректно, отрубить права, автозапуск и все такое. Если включать админа - идиота в «человеческий фактор», то да, вы правы.
Судя по видео, уязвимость в винде, не в контроллерах. Винда по прежнему заражаема простой вставкой USB флешки (неужели автораны все еще актуальны… это печально), вредоносное ПО на лету меняет логику загружаемой программы, что приводит к «сумасшедшему» поведению контроллера. Если перед этим, как в статье, вирь поживет да пособирает статистику в память контроллера, то можно рапортовать записанным в течении некоторого времени, пока контроллер «сходит с ума». Никто не заметит, пока сам своими глазами не глянет на поведение железа.
Вывод: основная дыра — винда.
Второй вывод: судя по видео, вирь не заражает контроллеры, он заражает компы, что прошивают контроллеры. Если контроллер не трогать и не обновлять на нем софт с зараженной машины, то проблемы не будет. Софт по идее обновлять часто не должны.
Похоже победили юристы, а не технари. Гугл изначально сказал, что Android на Java с собственными модификациями, что позволило привлечь кучу народа (о! там Java, я ее уже умею писать под Андроид!). Это маркетинговый ход. У Dalvik больше сходства с Parrot, чем с JVM. Но кого интересуют технические детали, когда пахнет хорошими деньгами?
getLine::IO Stringэто всегда одно и то же значение типаIO String, не зависимо от времени или каких либо других сторонних факторов.putStr::String -> IO()всегда возвращает одно и тоже значение типаIO ()для одной и той же строки. Выражение:(getLine >>= putStr)::IO ()в принципе без выполнения, даже на этапе написания кода, всегда будет возвращать значение типа IO (). Детерминизм, type-safety, верификация, все присутствует и никаких поблажек. А потом пользователь перенесет получившееся значение, в свой «не чистый» мир, глянув в него. И тут открылись файлы, прочитались строки, заработали SOAP соединения со всеми случайными сбоями и т.д. «Чистая» программа к тому моменту уже «отработала», выдав одно из бесконечно возможных значений типа IO (). А значение — это один из бесконечно возможных сценариев работы императивной программы со всем вводом и выводом. С некоторыми оговорками можно сказать, что переход из «чистого» мира происходит когда Haskell программа транслируется в C/машинный код (императивный, шаг за шагом код), результат которого наоборот зависит от окружающей обстановки. А монады (типы, о которых мы можем ничего не знать, кроме определенных операций >>=, return и т.д.), позволяют завернуть понятие «все возможные значения/сценарии Х» в некоторое не известное значение монадного типа.
Не все монады «не известны». Maybe тоже монад (тут важно наличие конструктора типов, операций >>=, return, fail etc) со вполне известными вариантами. Просто монады, помимо других задач, элегантно решают проблемы не детерминированного мира (позволяют не знать о себе ничего).
Пусть есть некоторый алгебраический тип, к примеру:
data Maybe a = Nothing | Just aМы знаем из чего состоит тип, значит можем на прямую рассмотреть case value of с альтернативами для Just a и Nothing. Исходя из этих знаний, мы можем сделать функцию
f::Maybe a -> a, выдав значение по умолчанию для Nothing. Это чистые значения.А теперь представим что есть некий алгебраический тип, о котором мы ничего не знаем, только лишь конструктор. Значит
f::IO Stringдействительно может быть какой угодно альтернативой вIO, о которой мы ничего не знаем. Это может быть прочтенная строка с консоли, ошибка, что угодно. Заметим, что мы даже не можем предполагать, что значение с типомIO Stringэто действительно какая то альтернатива IO, нет это всегда одно значение, но оно «многолико». Именно поэтомуgetLine::IO Stringэто значение (функция без аргументов), которое может «прочесть любую строку с консоли» — прочтенная строка будет строкой/ошибкой/etc для наблюдателя (наблюдатель не находиться в «чистом» мире), в самой программе оперируется чистое значение «все возможные варианты IO» (ключевые: суперпозиция, посыл к квантовой физике)Раз мы не знаем что есть в
IOили в любом другом «неизвестном типе»/монаде, значит нельзя что либо сделать со значениемIO a. Для этого и есть оператор применения >>=, который достает а из монадного значения и применяет ее к функцииf::a -> IO aесли это возможно. Иначе (если к примеруIO Stringбыл ошибкой, а не прочитанной строкой) возвращает новое значение IO a, о котором мы ничего не знаем. Именно потому, что >>= может вернутьIO a«в обход» нашей f, f должна возвращатьIO a. Т.е. однажды «испачкавшись» в монадах вы увязли до самого конца программы. В функциональной программе нет времени, т.е. нельзя стать наблюдателем и посмотреть что там в монадном значении (unsafe функции, те которые при «исключительных» значениях «не знают что делать» и оставлены на совесть программисту, мы не рассматриваем. это хак малодушных :), это не Haskell), значит нельзя избавиться от монада. На самом деле программа на Haskell всегда, не зависимо от времени, окружающего мира и т.д. отдаетIO (), «многоликое» неизвестное значение, и завершается, мгновенно. После работы программы мы в своем мире с side-effects наблюдаем за полученным значением с типомIO ()и видим один из «выпавших» вариантов: вывод на консоль, окошки и т.д. Даже если программа работает несколько суток, общается с пользователем и выкачивает чего из интернета, все равно в «чистом мире» Haskell программа уже отработала и вернула намIO ()со всем что мы видим, можем ввести и можем получить результат обратно. Там нет времени, там нет side-effects :)Заметим, что зная тонкости внутренней реализации ввода/вывода (или любой сторонней либы, чего угодно), можно написать к примеру
hasFailed::IO а -> Bool. Но это совсем не хорошо, т.к. из всего «бесконечного» множества вариантовIO aмы вдруг получили Bool, который всегда True | False, не зависимо от действий внешнего мира и времени. Таких функций быть не должно, это unsafe функции. Но может бытьhIsClosed::Handle -> IO Bool, применяемая кIO Handle. Тогда логика скрыта в Handle, если там не что-то еще из бесконечного множество «чего то еще». ПолучилIO Boolмы можем сделать свою логикуf::Bool -> IO SomethingElseили дальше катиться в потоке IO SomethingElse. Это может сносить немного крышу. Что бы это понять попробуйте представить, что ваша программа может дать верные результаты или выпасть с ошибками — это все «известные» результаты; либо уборщица шваброй выдернет питание и все накроется — это «не известные» результаты, одно из не подвластных вам проявленийIO SomethingElse. Функциональный мир при этом остается чист и детерминирован.Стандарты это хорошо, но реализация часто хромает. Если сейчас сделать все грамотно и перетаскивать локальные файлы будет не возможно, то завтра кто-то в браузер встроит плагин, где в окне будут открыты файлы из какого-нибудь cloud хранилища. И как фичу сделают возможность перетаскивать эти файлы (все события, dataTransfer интерфейсы и т.п.). Вдруг внезапно «откроется брешь в безопасности».
Нельзя предусмотреть все варианты, просто потому, что софт меняется. В последнее время браузеры стараются не спрашивать пользователя о скрытых запросах и процессах. На мой взгляд проблема реальна.
P.S. я думал карма ь это отношение участников к адекватности автора, а не оценка его взглядов. «Заминусованный» пользователь потеряет возможность писать, «неугодная» точка зрения исчезнет. Жалко смотреть во что превратили карму.
Я не скептик, но как то с опаской смотрю на такие нововведения…
Конечно возможен сценарий, где репозиторий популярного плагина взломали, дописали вредного кода и тихо позволили разработчикам это все опубликовать. Но это надеюсь когда-нибудь пофиксят в браузере, задавая определенным адресам возможность отключать все плагины.
Просто как обычный пользователь чувствуешь себя в поле окруженном граблями, следишь за каждым своим шагом и начинаешь думать «ну почему все так через ж*пу...?»
<input type="email" name="email" required />Тут либо лишний '/', либо на required парсер должен споткнуться. Неясно зачем смешивать синтаксисы HTML и более строгого XML. Надеюсь автор просто ошибся.
Подобное явно не будет привлекать новых пользователей к рамблеру. Скорее заставит уйти и не возвращаться, если работники компании делят аудиторию на «убогих» и себя/богов/кого-угодно.
Да, вывод не верный. Более правильно будет: для циклов по целым числам быстрей xrange.
А range нужен что бы просто создать список. Любой список. Способность пробежаться по нему, к примеру по буквам range('a', 'z') это скорее бонус =)
Итог: по моему xrange почти всегда лучше.
- автоматический запуск приложений с флешки (autorun), который ну никак не должен работать на подобного рода компьютерах (да и вооще редко где нужен).
— работа человека с привилегиями админа, позволяющими (за)(из)менить либы Step 7 (кстати, это не ОС, просто редактор логики/IDE, впрочем и название всей линейки контроллеров, работал с ними год)
Иными словами, не будет этих двух пунктов и человеческий фактор уже не сработает. Хоть порнушку запускай, сам, пока не повысишь свои привилегии, нет проблемы. Так что на мой взгляд проблема — windows и ее специфика работы, а на втором месте уже «человеческий фактор». Другой вопрос, что винду можно настроить корректно, отрубить права, автозапуск и все такое. Если включать админа - идиота в «человеческий фактор», то да, вы правы.
Вывод: основная дыра — винда.
Второй вывод: судя по видео, вирь не заражает контроллеры, он заражает компы, что прошивают контроллеры. Если контроллер не трогать и не обновлять на нем софт с зараженной машины, то проблемы не будет. Софт по идее обновлять часто не должны.