Не так давно, я придумал и использовал три не сложных пароля, мне приходилось вводить их на каждом сайте поочередно, пока один из них не подойдет. Сейчас же, на каждом сайте где я зарегистрирован стоит свой, устойчивый к бруту пароль, для хранения которого я использую только свои память и мозги.
Однажды, я случайно нашел sql injection на одном посещаемом сайте. Для удовлетворения своего интереса я слил все логины, пароли и мэйлы. Как ни странно 80% паролей подходили к прикрученным к аккаунтам email.*
Как известно, память наша не способна запомнить сложные, бессмысленные комбинации, потому что она работает на ассоциациях. Думаю понятно что и пароли должны вызывать ассоциации, или быть логичными. Но дата рождения или свое ФИО не способны играть роль пароля, да и иметь одинаковые пароли на каждом сайте тоже большая ошибка, объяснил я ее выше.
Значит пароль должен быть:
Когда говорят о запоминающих устройствах, большинство людей вспоминают о накопителях на магнитных дисках (HDD) и о памяти с произвольным доступом (ОЗУ). Уверен, большинство читающих этот пост, знает о множестве фундаментальных различий между устройствами этих классов. Но на самом деле у этих устройств есть и кое-что общее: и в оперативной памяти, и на жёстких дисках поиск информации выполняется по её адресу. Программистам такой подход кажется если не единственно возможным, то уж точно самым логичным, но к счастью реальный мир не ограничивается исключительно программными абстракциями. В этой статье мы рассмотрим запоминающие устройства с доступом по содержанию.Читать полностью »
UKSM (Ultra Kernel Samepage Merging) — технология совмещения одинаковых страниц памяти в одну.
UKSM вдохновлен KSM(технология от RedHat), но практически полностью переписан.
У KSM есть несколько недостатков:
Размеры объектов в Java уже обсуждались на Хабре, например, здесь или здесь. Мне бы хотелось подробнее остановиться на размерах многомерных массивов — простая вещь, которая для меня стала неожиданной.
Оптимизируя вычислительный алгоритм по памяти, я наткнулся на то, что при определённых (вполне разумных) входных параметрах создаётся массив float[500][14761][2]. Сколько он может занимать в памяти (на HotSpot 1.6.0_26 32bit, если кому интересно)? Я примерно прикинул, что 500*14 761*2*sizeof(float) = 500*14 761*2*4 = 59 044 000 байт плюс какой-то оверхед. Решив проверить, как на самом деле, я воспользовался Eclipse Memory Analyzer (невероятно волшебная вещь, рекомендую!) и обнаружил, что «Retained Heap» для этого массива составляет 206 662 016 байт! Неплохой оверхед — 350%. Посмотрим, почему так получилось.
Читать полностью »
Последние несколько лет мою квартирную сеть (12 компьютеров и с десяток Wi-Fi устройств) верой и правдой обслуживала cisco 2651XM. Телефония (12FXS и 4FXO на NM-HDA) и два провайдера по 30 Мбит унлимитного интернета от каждого. До активного пользования торрентами всеми членами семьи она справлялась на отлично, но при запущенном юторренте, более чем на одном компьютере 2651XM полностью загибалась. Потратив месяц на оптимизацию и не найдя достойных компромиссов, железка была отправлена на заслуженную пенсию (на komok.com, где за сущие копейки тут же обрела себе нового хозяина...), а на боевое дежурство встала cisco 2821. Сериал про борьбу с собственной жабой на тему доп. инвестиций в домашнюю сеть в размере 700$ я упущу… Как и полагается железка была взята юзаной, с минимальной памятью 256М и уже с весьма сильно шумящими вентиляторами, на которые железка активно ругалась, назойливо выдавая сообщение о периодической остановке одного из вентиляторов и низких оборотах на двух других. Вскрытие чистка и смазка вентиляторов решили проблему увы только частично. Один из вентиляторов полностью «воскресить» в итоге так и не удалось, слишком поздно увы! Он слишком долго проработал в пыли и без смазки, по этому хоть крутиться и начал и даже шуметь практически перестал, но должных оборотов уже не дает. Придется менять! :( Пробежавшись по ебаю, увидел их минимальную цену равную 22$, что меня само собой не вдохновило! 700р за вентилятор, да еще и пара недель ожиданий! Читать полностью »
Здравствуйте, многоуважаемые коллеги.
Возможно, вы не знаете, но каждый день, каждый час, каждую секунду мы ведем войну за память устройств. Для кого-то эта война незаметна, кто-то не придает ей значение, кто-то воюет по-старинке. Однако же, я пишу это письмо вам, пишу для всех моих сослуживцев в войсках UIKit, Objective-C и Cocoa Framework.
Много байт мы потеряли, много еще будет потеряно, но все же фронт мы не сдаем. Мы получаем новое и интересное оружие, одно из которых – это ARC, Каунтер ссылок автоматический. Воистину, с новым оружием нам открылись новые горизонты, и мы было уже начали побеждать, но мы чрезмерно расслабились.
О чем я говорю, спросите вы? О том, что память не сдается! Да, часто, но нет, не всегда мы ее получаем, завоевываем. Читать полностью »
