Поэтому бо́льшая часть уязвимостей исправляется в процессе тестирования программы.
Вероятность найти уязвимость в стабильной версии опенсорсной программы низка. Они безопасны именно потому, что каждый может заглянуть внутрь и посмотреть, как оно работает. Разумеется, если есть кому заглядывать. Так что потратить нужно столько же, если не больше.
Я не имел в виду конкретные цифры. Я не эксперт в этой области.
Но мне понятно, что вероятность нахождения подобной уязвимости, например, в гномовском *.desktop в разы меньше (раз — открытый формат, два — воспринимаемый человеком текст, а не бнарник).
Следовательно, для получения (найти, купить) таких уязвимостей нужно потратить в те же разы больше ресурсов.
ftp> ls ./../../*/*/../*/../*/*/*/../…
200 PORT command successful. Consider using PASV.
150 Here comes the directory listing.
226 Transfer done (but failed to open directory).
> величайшие умы математики и кибернетики 50-70-хх годов давно бы уже додумались до этого решения раньше, чем какой-то студент из далёкого для них 2010-го года
Увы, у великих гениев прошлого не было того, что в наши дни есть у какого-то студента — персонального компьютера.
Насколько я понимаю принцип работы подобных алгоритмов, программа сначала переводит текст с языка источника на требуемый язык, а затем, с помощью списка синонимов и правил подстановки, рифмует полученный текст.
Отсюда следует, что:
1. С помощью этого алгоритма возможен перевод с исходного языка на исходный (да, именно перевод).
2. Имея алгоритм работы, можно с незначительными (в зависимости от выбранного языка; например, адаптация для русского займёт меньше времени, чем для китайского, поскольку русский и английский языки во многом схожи) изменениями адаптировать программу для работы с любым языком.
3. Разработчики при разработке подобной системы в условиях недостатка ресурсов реализуют лишь основной алгоритм и поддержку двух, возможно трех языков (родных языков разработчиков и английского).
З.Ы. Когда прочел статью, сразу пришла в голову мысль, что прототип алгоритма был чрезвычайно прост: брутфорсер текста через Google Translate плюс проверка размерности и рифмы.
Смысл моего комментария заключался в том, что переводчик, который имеет опыт перевода стихов RU — EN, знаком с теоретической базой (лексика, грамматика) и способен разобраться в исходном алгоритме (сам или с помощью программиста), сможет добавить поддержку русского языка в программу. Я не знаком с исходными кодами и алгоритмом работы, но предполагаю, что для этой задачи потребуется намного меньше ресурсов, чем потребовалось для разработки оригинального алгоритма.
Также я, не обладая актуальной информацией, сделал намек на то, что подобными исследованиями (а именно: открытыми исследованиями в области перспективных направлений развития IT и интернета вообще, проведенными группой энтузиастов) кто-то заинтересуется, и предположил, что это будет Google. Но когда я ознакомился с докладом, для меня не было неожиданным то, что разработчики уже тесно контактируют с вышеупомянутой корпорацией.
И наконец, насчет п. 4. Если вы откроете доклад и прочтете шапку, то с удивлением обнаружите, что исследователи нашли гениальное решение — они попросту его пропустили.
1. Создать БД слов и синонимов.
2. Научить алгоритм учитывать лексические и грамматические отличия русского от английского.
3. Продать алгоритм гуглу.
4. ???
5. PROFIT!!!
Давайте даже представим себе, что в аппарате размером с тот же айфон есть дисплей Full HD (что когда-то будет). И вопрос сразу упирается не в разрешение, а в «физические» размеры элементов управления.
Так что проектор а-ля Seabird рулит. И когда они вставили туда видео с Win7, они хотели нам что-то сказать.
Допустим, в один квадратный сантиметр можно будет запихнуть вдвое больше пикселей. Но как тогда пользоваться? Ведь если использовать разрешение *х800, а ширину оставить как у айфона, то окошко будет всего-навсего 2.5х5 см. И как стилусом цвет выбирать? Согласен, это реально. Но очень неудобно.
Я считаю, что вполне реально, например, создать открытую спецификацию подключения легкого плоского монитора по тому же miniusb. И там уже играться с гимпом в полную силу.
>Как Вы себе представляете верстку сайтов, редактирование Hi-Res фоток или создание презентаций на мобильном устройстве?
С внешним источником питания лет так через 5 и железом того времени это звучит вполне реалистично. Gimp, опенофис — это насчет презентаций и фотографий. А видео конвертировать (то есть ядро собирать) оставлять на ночь.
А вот насчет создания и потребления контента вы чертовски правы. Только (имхо) это классификация не возможностей железа, а интерфейса — будет он способствовать продуктивному созданию или продуктивному потреблению.
Вероятность найти уязвимость в стабильной версии опенсорсной программы низка. Они безопасны именно потому, что каждый может заглянуть внутрь и посмотреть, как оно работает. Разумеется, если есть кому заглядывать. Так что потратить нужно столько же, если не больше.
Но мне понятно, что вероятность нахождения подобной уязвимости, например, в гномовском *.desktop в разы меньше (раз — открытый формат, два — воспринимаемый человеком текст, а не бнарник).
Следовательно, для получения (найти, купить) таких уязвимостей нужно потратить в те же разы больше ресурсов.
Вот и всё.
Вообще-то да, кому нужно, своей цели добьётся. Но вот для того же результата затраты возросли бы на порядок-два.
Неправда. Человек, который вставит неизвестно что в производственный компьютер за деньги/по глупости — это уязвимость.
Так и произошло. Через форточки заразили контроллеры.
И да, сколько бы вы ни платили, отдача от воздействия вируса на винде будет на порядок выше.
[user@axe ~]$ ls ../../*/../*/*/../../*/*/*/*
ls: ../../*/../*/*/../../*/*/*/*: No such file or directory
ls ../../../*/*/../../*/*/*/../…
вывод очень длинный и похож на ls -R /
200 PORT command successful. Consider using PASV.
150 Here comes the directory listing.
226 Transfer done (but failed to open directory).
И ничего.
Увы, у великих гениев прошлого не было того, что в наши дни есть у какого-то студента — персонального компьютера.
К тому же, основная часть алгоритма — не перевод, а подбор рифмы и размерности. Я это уже написал вот здесь:
habrahabr.ru/blogs/htranslations/105801/#comment_3319641
P.S. Пожалуйста, не стоит недооценивать студентов. Разум и интеллект приходят с опытом, а не с возрастом.
Отсюда следует, что:
1. С помощью этого алгоритма возможен перевод с исходного языка на исходный (да, именно перевод).
2. Имея алгоритм работы, можно с незначительными (в зависимости от выбранного языка; например, адаптация для русского займёт меньше времени, чем для китайского, поскольку русский и английский языки во многом схожи) изменениями адаптировать программу для работы с любым языком.
3. Разработчики при разработке подобной системы в условиях недостатка ресурсов реализуют лишь основной алгоритм и поддержку двух, возможно трех языков (родных языков разработчиков и английского).
З.Ы. Когда прочел статью, сразу пришла в голову мысль, что прототип алгоритма был чрезвычайно прост: брутфорсер текста через Google Translate плюс проверка размерности и рифмы.
Также я, не обладая актуальной информацией, сделал намек на то, что подобными исследованиями (а именно: открытыми исследованиями в области перспективных направлений развития IT и интернета вообще, проведенными группой энтузиастов) кто-то заинтересуется, и предположил, что это будет Google. Но когда я ознакомился с докладом, для меня не было неожиданным то, что разработчики уже тесно контактируют с вышеупомянутой корпорацией.
И наконец, насчет п. 4. Если вы откроете доклад и прочтете шапку, то с удивлением обнаружите, что исследователи нашли гениальное решение — они попросту его пропустили.
1. Создать БД слов и синонимов.
2. Научить алгоритм учитывать лексические и грамматические отличия русского от английского.
3. Продать алгоритм гуглу.
4. ???
5. PROFIT!!!
Так что проектор а-ля Seabird рулит. И когда они вставили туда видео с Win7, они хотели нам что-то сказать.
habrastorage.org/storage/ff006a0b/88f9c5f0/c478e434/e2949c45.png — окно выбора цвета в гимпе. 762х390.
Допустим, в один квадратный сантиметр можно будет запихнуть вдвое больше пикселей. Но как тогда пользоваться? Ведь если использовать разрешение *х800, а ширину оставить как у айфона, то окошко будет всего-навсего 2.5х5 см. И как стилусом цвет выбирать? Согласен, это реально. Но очень неудобно.
Я считаю, что вполне реально, например, создать открытую спецификацию подключения легкого плоского монитора по тому же miniusb. И там уже играться с гимпом в полную силу.
С внешним источником питания лет так через 5 и железом того времени это звучит вполне реалистично. Gimp, опенофис — это насчет презентаций и фотографий. А видео конвертировать (то есть ядро собирать) оставлять на ночь.
А вот насчет создания и потребления контента вы чертовски правы. Только (имхо) это классификация не возможностей железа, а интерфейса — будет он способствовать продуктивному созданию или продуктивному потреблению.