Дело не столько в счете денег, сколько в совершенно ином отношении к законам как граждан, так и власти.
Если бы я жил в какой-либо нормальной Европейской стране, то меня бы ни сколько не покоробила мысль о покупке нужного коммерческого ПО хоть под Линукс (тот же Bibble Pro).
Мда… тупняк какой-то. Хорошо хоть Opera есть, как Mini, так и полноценная.
Кстати говоря, современные мобильные устройства по своим возможностям (память, процессор и т.п.) сравнимы с компьютерами десятилетней давности, а может даже и с чуть более новыми. Браузеры в те времена прекрасно себе работали без всяких тормозов и прочих неприятных вещей, так почему же современные поделки, наблюдаемые на смартфонах настолько убоги?
В чужой аккаунт элементарно попасть, если сидишь с этим человеком за одним прокси. По крайне мере с Kerio это не так давно еще работало. Просто тупо заходишь на мыл.ру и оказываешься в чужом ящике, если кто-то в него залогинился до твоего захода.
Partition Magic забросили 5 лет назад. Какой смысл им сейчас пользоваться? Он и тогда то нормально не работал.
Если уж сравнивать, то с решениями от Acronis.
Перенесли бы сервера в Зимбабве и ничего бы не пришлось блокировать.
А если серьезно, то я не думаю, что в заблокированных странах было много разработчиков. Северная Корея врядли сама бы позволила хоть каким-то проектам утечь из страны, более того, америка у них скорее всего просто заблокирована. Во всяких «неблагополучных» странах людям тоже не до проектов на SF. Остаются только страны вроде Кубы, но там компьютеры стоят больше, чем обычный человек может заработать за всю жизнь.
Забавно, конечно, но фокус в том, что они письма и не отсылали. У меня собственный почтовый сервер, на котором я могу посмотреть все, что происходило. От аваста писем просто не было.
А когда я запрашивал новый ключ на новый ящик, отличающийся от старого одной буквой, письмо практически моментально приходило.
Вообще говоря, информации о шифровании там и не должно быть, она по идее должна лежать в ключе, но раз это просто файлик с последовательностью, то никак не убрать (либо алгоритм фиксирован, либо информация о нем хранится в открытом виде).
То, что разница в скорости незаметна, означает лишь то, что процессор успевает обрабатывать считываемый поток. Ради интереса можно сравнить максимальную скорость чтения и нагрузку на процессор на обычном диске и на зашифрованном. Думаю, что разница должна быть заметная. А если зашифрованный диск будет на шустром рейде, то разница в скоростях и нагрузке будет существенная.
P.S. Информацию я не шифрую, т.к. не вижу в этом никакого особого смысла.
Конечно не тупой xor :) Там в статье по ссылке написано:
Ciper name: aes
Cipher mode: cbc-essiv:sha256
Hash spec: sha1
Т.е. при попытке расшифровки алгоритм либо полностью известен, либо выбирается из очень ограниченного списка типовых. Пусть сам алгоритм и не такой простой, как xor, но, обладая информацией о части зашифрованного содержимого, можно если не полностью восстановить ключ, то по крайней мере существенно сократить диапазон для перебора. Размер ключа тут не очень важен, его длина больше влияет на скорость работы с зашифрованным диском.
Единственное, что может действительно усложнить расшифровку — это сохранение информации о алгоритме шифрования вместе с ключом, а сам алгоритм, естественно, тоже должен быть какой-то случайной последовательностью случайной длины более простых (типовых) алгоритмов, причем ключи для стыковки между ними тоже должны быть случайными. Но быстро это работать точно не будет :)
Хочу прокомментировать не в критику поста, а на счет шифрования дисков вообще.
Смысл шифрования и его стойкости в том, что НЕИЗВЕСТНО что именно зашифровано, в этом случае поможет только брутфорс. В случае шифрования диска задача нахождения ключа (пусть и длиной 256 символов) очень сильно упрощается, т.к. содержимое огромного количества файлов в фаловой системе известно (сама операционка), плюс точно известны сайфер и хэш-функция.
Получается отпугивалка для детей, а не реальная защита данных.
Так зачем утруждаться, если можно написать под j2me и запустить ту же программку еще на куче мобилок. Какие-то «системные» фишечки придется делать «нативными», но их не так много нужно.
Вон на современных нокиях под симбианом половина якобы нативных приложений на самом деле флэш.
Вроде как раз количество сишников снижается (шарп я не считаю)…
Если на андроиде j2me работает, то народ не будет особо напрягаться с нативными приложениями.
Это замечательно, что оно встало в reactos. Я к тому, чтобы в wine эти части официально разделили. Тогда можно будет спокойно работать над общей частью (как над отдельным проектом), не таская код туда-сюда. Польза будет всем.
Может задумка такая и была, но в презентации этого вроде нет (или я проглядел), т.к. она ориентирована в основном на разработчиков reactos, т.е. немного однобока.
Я не очень в курсе, как реализован вайн, но может проще не задействовать часть wine в reactos, а абстрагировать wine от платформы. Будет просто реализация винды, которую можно запустить на любой платформе при наличии некоторой платформозависимой прослойки. Ну и никто не мешает сделать эту самую прослойку запускаемой на голом железе, т.е. это фактически reactos.
Если бы я жил в какой-либо нормальной Европейской стране, то меня бы ни сколько не покоробила мысль о покупке нужного коммерческого ПО хоть под Линукс (тот же Bibble Pro).
Кстати говоря, современные мобильные устройства по своим возможностям (память, процессор и т.п.) сравнимы с компьютерами десятилетней давности, а может даже и с чуть более новыми. Браузеры в те времена прекрасно себе работали без всяких тормозов и прочих неприятных вещей, так почему же современные поделки, наблюдаемые на смартфонах настолько убоги?
Если уж сравнивать, то с решениями от Acronis.
А если серьезно, то я не думаю, что в заблокированных странах было много разработчиков. Северная Корея врядли сама бы позволила хоть каким-то проектам утечь из страны, более того, америка у них скорее всего просто заблокирована. Во всяких «неблагополучных» странах людям тоже не до проектов на SF. Остаются только страны вроде Кубы, но там компьютеры стоят больше, чем обычный человек может заработать за всю жизнь.
А когда я запрашивал новый ключ на новый ящик, отличающийся от старого одной буквой, письмо практически моментально приходило.
То, что разница в скорости незаметна, означает лишь то, что процессор успевает обрабатывать считываемый поток. Ради интереса можно сравнить максимальную скорость чтения и нагрузку на процессор на обычном диске и на зашифрованном. Думаю, что разница должна быть заметная. А если зашифрованный диск будет на шустром рейде, то разница в скоростях и нагрузке будет существенная.
P.S. Информацию я не шифрую, т.к. не вижу в этом никакого особого смысла.
Ciper name: aes
Cipher mode: cbc-essiv:sha256
Hash spec: sha1
Т.е. при попытке расшифровки алгоритм либо полностью известен, либо выбирается из очень ограниченного списка типовых. Пусть сам алгоритм и не такой простой, как xor, но, обладая информацией о части зашифрованного содержимого, можно если не полностью восстановить ключ, то по крайней мере существенно сократить диапазон для перебора. Размер ключа тут не очень важен, его длина больше влияет на скорость работы с зашифрованным диском.
Единственное, что может действительно усложнить расшифровку — это сохранение информации о алгоритме шифрования вместе с ключом, а сам алгоритм, естественно, тоже должен быть какой-то случайной последовательностью случайной длины более простых (типовых) алгоритмов, причем ключи для стыковки между ними тоже должны быть случайными. Но быстро это работать точно не будет :)
Смысл шифрования и его стойкости в том, что НЕИЗВЕСТНО что именно зашифровано, в этом случае поможет только брутфорс. В случае шифрования диска задача нахождения ключа (пусть и длиной 256 символов) очень сильно упрощается, т.к. содержимое огромного количества файлов в фаловой системе известно (сама операционка), плюс точно известны сайфер и хэш-функция.
Получается отпугивалка для детей, а не реальная защита данных.
Что касается стабильности, то Убунта тут ничем не хуже винды.
Вон на современных нокиях под симбианом половина якобы нативных приложений на самом деле флэш.
Если на андроиде j2me работает, то народ не будет особо напрягаться с нативными приложениями.
Может задумка такая и была, но в презентации этого вроде нет (или я проглядел), т.к. она ориентирована в основном на разработчиков reactos, т.е. немного однобока.