Классические разделы, на которые чаще всего разбивается жёсткий диск для установки системы и хранения данных, имею ряд существенных недостатков. Их размер очень сложно изменять, они находятся в строгой последовательности и просто взять кусочек от первого раздела и добавить к последнему не получится, если между ними есть ещё разделы. Поэтому очень часто при начальном разбиении винчестера пользователи ломают себе голову — сколько места выделить под тот или иной раздел. И почти всегда в процессе использования системы приходят к выводу, что они сделали не правильный выбор.

К счастью, решить большинство этих проблем в Linux может технология LVM. Она создаёт дополнительную абстракцию — логические тома, которые видны в системе, как обычные разделы, однако реально ими не являются. Эта технология очень полезна для серверов, однако и на домашних компьютерах она приходится очень к месту. Я больше не думаю, какого размера диск выделить под систему, чтобы какой-нибудь texlive не забил бы всё место, но и чтобы лишние 5 — 10 гигабайт не пропадали просто так. LVM имеет ряд существенных преимуществ, значительно упрощающих жизнь:

• Логические тома LVM больше не привязаны к физическому местоположению. В рамках LVM вообще не существует такого понятия, как порядок логических томов.
• Размер логических томов можно увеличивать прямо на лету, а у отмонтированных томов можно кроме того легко уменьшать размер, не выходя из системы.
• При необходимости можно размазать логические тома по нескольким физическим жёстким дискам, таким образом увеличив доступное место. При этом система всё так же будет видеть только один логический том, хотя размер его будет превышать доступные размеры жёстких дисков. Можно провести и обратную операцию, удалив жёсткий диск из LVM, таким образом освободив его для другого использования.
• LVM поддерживает механизм снапшотов — мгновенных копий файловой системы тома. Это может очень пригодиться для создания бекапов.
• Есть ещё масса плюсов, о которых можно почитать в специализированных статьях про LVM.

Дело было глубокой осенью. Мне поручили разработку раздела, основной задачей которого является указание местоположения объектов фильтрации и поиска на карте. Что стало заметно сразу же — даже при отображении 10 объектов на карте, можно уменьшить зум до такого, при котором они просто сливаются. Если их будет 100 — появятся жутковатые наложения и тени. Не комильфо!

Поиск решения

Решение очевидное, маркеры нужно группировать. В процессе поиска наткнулся на хабростатью, в которой рассмотрены различные способы группировки большого количества маркеров на карте. Нас вполне устраивали «костыли 1-2», то есть группировка маркеров на клиентской стороне, однако… если бы они подошли, не писал бы я сейчас статью ;)

Сегодня меня заинтересовал опрос надо ли перевешивать SSH на нестандартный порт. Сам опрос не так интересен как способ автора zivot_je_cudo защищать SSH от подбора пароля: после неверной попытки подключения блокировать новые попытки в течение 20 секунд. Задержка, видимо, выбрана эмпирически, исходя их двух противположных пожеланий: чтобы не заблокировать в случае опечатки себя надолго, и в тоже время усложнить жизнь подбиральщика. Я хочу поделиться своим способом противодействия брут-форсу, который применяю уже несколько лет. Он имеет два преимущества:
— дает мне больше попыток для набора правильного пароля
— но при этом блокирует брутфорсеров «навечно».

Как можно достичь этих двух противоположных целей?

Теорию и процесс атаки хорошо описал юзер n3m0 в статьях «Атаки на беспроводные сети». Но практика там описана достаточно слабо.

В данной статье будет описан практический процесс атаки на беспроводную сеть с шифрованием WEP, используя пакет aircrack-ng и операционную систему OpenSuse.

Накопив определенный опыт в помощи «неосторожным» и обобщив его решил написать краткую обозревательную статейку по проблеме различных смс-вымогателей ака информеров. Опытный ИТ-шник вряд ли найдет в ней что-то новое, но большая часть простых пользователей, вероятно, найдут в ней что-то полезное либо просто интересное для себя.
Назовем её «Кто виноват или/и что делать для Чайников».

Ручки шаловливые ...

Как показывает практика, для большинства простых пользователей факт заражения системы не вызывает каких-либо особых опасений — вроде все кое-как да работает, немного тормозит система да выскакивают время от времени ошибки, но в целом это не мешает удовлетворять свои скромные повседневные потребности – общаться в соц.сетях, послушать музыку да фильм посмотреть. А значит заботится о какой-то защите не кажется столь важным. А в то время зараженная ЭВМ днями напролет работает на благо ДиДосеров, спамеров да остальных не менее непорядочных товарищей…

Прежде чем приступить к практике, зададимся некоторыми весьма интересными вопросами: почему консоль, зачем использовать видеокодек Ogg Theora, каким образом и с какими параметрами лучше конвертировать видео.

Начнём с матчасти:

Видеокодек — это программа/алгоритм сжатия (то есть уменьшения размера) видеоданных (видеофайла, видеопотока). Кодек — файл-формула, которая определяет, каким образом можно «упаковать» видеоконтент и, соответственно, проиграть видео. Также возможно кодирование кроме видео и аудиоинформации, добавления субтитров, векторных эффектов и т. п.

На сегодняшний день, самые популярные видеокодеки — это знакомые всем DivX, XviD, H.264, WMV, Apple QuickTime и множество других. Ogg Theora всегда была в тени своих коллег и на то, видимо, были какие-то свои причины. Может быть потому, что это относительно новый кодек (он появился только в 2004-м году), может потому-что он изначально ориентировался на применение в интернете, а не для кодирования видеофильмов… Это уже не важно.

Во многих проектах требуется посчитать время, которое затратил тот или иной метод. Для этого можно вручную сохранять значение System.currentTimeMillis() и после метода вычислять затраченное время. Когда методов много это становится не очень удобным.
Поэтому я решил написать простенькую аннотацию, которая бы считала время выполнения метода. Попытавшись найти информацию в интернете, понял, что её по данной теме очень мало. Придётся как-то выкручиваться, собирая информацию по крупицам.

Как известно, пару месяцев назад свет увидела jQuery 1.4, в которой мы можем наблюдать множество новых функций и возможностей. А значит, стало еще больше информации для изучения и запоминания. И не важно, насколько хорошо вы владеете искусством jQuery — запомнить всё в любом случае не удастся. И вот здесь нам на помощь приходят всевозможные сборники документаций и шпаргалки, которые очень полезно держать под рукой и периодически в них заглядывать).

Привет тебе хабражитель!
В данной статье, точнее примере я хочу показать как можно получить информацию о залоченных потоках Вашего многопоточного java приложения. Под катом будет представлен пример простейшей ситтуации DeadLock'а, а также способы получения информации о нем.

rTorrent — еще один из самых популярных torrent клинтов в мире Unix-подобных операционных систем (о Transmission я уже написал несколько ранее). При создании этого клиента, по заявлению автора, во главе угла стояли «высокая производительность и хороший код», а использование mmap для отображения файлов в память позволяет добиться на широкополосных каналах трехкратного преимущества перед официальным клиентом. Еще одной характерной чертой rTorrent является наличие множества различных web-интерфейсов «на все вкусы» для удаленного управления. Именно об установке и настройке всего этого я и хочу рассказать на этот раз.

После прочтения поста Стива Сойдерса о бесплатном инструменте — dynaTrace Ajax, я был дико заинтригован. Он предлагает полную анализ трассировки в IE6-8, включая JavaScript, прорисовку и сетевой трафик. Я протестировал несколько сайтов, но более интересный результат получил с тяжелым JavaScript'ом в Gmail в IE8.