Недавно на Geektimes был обзор про модули ITEAD TH10. Хочу поделиться опытом разработки собственной прошивки для этих устройств.

Как уже писали на Хабре, Билайн успешно поедает остатки Корбины-телеком.
Уже закрыли старый личный кабинет, халявное телевидение и некоторые другие гайки подзакрутили.

На этой волне Билайн перевёл всех корбиновцев с 1 декабря 2009 года на новый договор-офёрту пользования услуг Интернета.

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

Чтобы сэкономить ваше время, привожу самую вкусную часть договора — пункт про публикацию ваших личных персональных данных и передача их в компании-сборщики долгов.

Читаем п. 3.12. — в нем Компания разрешает себе распространять ваши личные и персональные данные, назвав это их «обработкой». По телефону операторы коллцентра оправдывались, что «имели ввиду распространения только в пределах себя».

Дальше — круче.

Всем привет. Эта статья написана отхабренным юзером noxxx и размещена по его просьбе — все плюсики, минусики и вопросики направляйте ему.

Это моя первая статья для Хабра, поэтому написал как смог. Цель статьи – показать другим, как замечательная сеть ИОН обращается с покупателями и вершит левосудие.

Преамбула.

Случилось мне с моей женой покупать ей мобильный телефон взамен старого, потрепанного и морально устаревшего Samsung. Выбор пал на Nokia N79. Искали нужного цвета и что б было подешевле. Нашли в единственном магазине – ИОН в Ашане, что недалеко от станции метро «Красносельская».
По странному стечению обстоятельств под нужным нам белым цветом числился серебристый, которых в городе пруд пруди и который моей супруге ну никак не нравился. Поэтому выбор пал на Nokia N78, который являлся практически полной копией N79, но был в черном цвете и смотрелся неплохо. После недолгих раздумий и «щупаний» телефона, мы решили, что берем его.
Пару дней спустя жена стала жаловаться, что клавиатура работает не так как надо, что кнопки иногда не срабатывают а иногда срабатывают не те. Я сказал что это, скорее всего, с непривычки и что всё устаканится. Жена честно пыталась привыкнуть к новому телефону, а тем временем с джойстика телефона постепенно облезала краска, телефон обшарпывался, морально устаревал, а срок службы шел…

Доброе время суток, хабраюзер!

Хоте с тобой посоветоваться по поводу моей проблемы. А суть проблемы следующая:
Есть одно электротехническое предприятие на Украине на котором я работаю. Пришел ко мне один сотрудник со служебной запиской с просьбой установить ему Компас, Фотошоп, заставку «часы» и другие прелести. На вопрос «Откуда софт?» последовал ответ — «Из дома принёс». «Лицензионный?» — спрашиваю я, «Не знаю, ответил он». А софт то оказался не лицензионным, чего и следовало ожидать. В конце то концов отправил я его с просьбой меня по этому поводу больше не беспокоить.

Он пошел в напор и обратился к моему начальнику, собственно, из-за чего этот спор и возник и до сих пор не решен.

О чем: делал кластер высокой готовности на двух нодах, с использованием heartbeat. Кластер под веб-сервер (apache, nginx, php, mysql). Здесь не инструкция о поднятии подобного кластера, а заметки по поводу использования кластерных файловых систем, то, чего не хватает в распространенных статьях и описание грабель, на которые наступил я.

В этой статье я хотел бы поделиться опытом, как организовать доступ к Web-интерфейсам различных домашних качалок через один единственный проброшеный наружу порт. Делать будем под винду (на Win32 порту nginx), но точно также можно сделать под unix.

Где это может понадобиться? Очень простой пример, состоящий из двух условий:
— У меня дома стоит СТРИМ, который блокирует входящий 80 порт
— У меня на работе открыты наружу только порты 443, 80, 5190.
— Как итог: я могу достучаться домой только к 2 сервисам, один из которых у меня SSH, и один остается свободным. Задача сводится к тому, чтобы завернуть все WEB-морды в один сайт, ибо замучался я с SSH-туннелингом. Универсального интерфейса, конечно же, не получится, так что их надо логически разделить.

Сейчас наличие нескольких подключений к интернет на одном, в том числе и домашнем сервере — не редкость. Городские локалки, ADSL, 3G модемы… Добавим к этому сети домашние локальные и внешние виртуальные (VPN), и получим ядрёную смесь интерфейсов, между которыми необходимо роутить трафик, балансировать трафик между разными каналами в интернет (когда они есть), и переключаться с нерабочих каналов на рабочие (когда они отваливаются).

Судя по постам в инете, большинство людей, столкнувшихся с этой ситуацией, очень плохо представляет себе, как это настраивается. Надо отметить, что в линухе действительно управление роутингом весьма сложное и запутанное — следствие эволюционного развития и поддержки (частичной) совместимости. Я хочу описать принципы настройки роутинга multihomed серверов на конкретном, достаточно сложном, примере: на сервере три физических сетевых интерфейса (один в домашнюю локалку и два к ADSL-модемам), два ADSL-подключения (ADSL-модемы в режиме bridge, так что pppd поднимает этот же сервер) к разным провайдерам (одно со статическим IP, второе с динамическим), плюс VPN на сервер компании — итого шесть интерфейсов.

Тема достаточно сложная, поэтому для понимания материала потребуется хотя бы минимальное понимание работы роутинга (что такое default route и gateway), файрвола (маркировка пакетов, отслеживание соединений, связь между разными таблицами и цепочками файрвола и роутингом), pppd (скрипты ip-up/ip-down) и протоколов IP и TCP.

Всем доброго времени!
В один прекрасный момент меня достало:

1. Нажимать PrintScreen
2. Искать место куда же его сохранить
3. Открывать сервис imageshack\radikal\хабр-эффект
4. Искать на диске, куда же я сохранил все таки именно этот скриншот
5. Копировать полученную ссылку, и делать с ней .....

Теперь я делаю:

1. Нажимаю Ctrl+/
2. Копирую полученную ссылку и делаю с ней .....

Неправдо ли лучше? И вас это тоже достало? Тогда лезем под кат!

В самый страшный день в году мы подготовили иллюстрированный прогноз на тему: каким будет следующий грипп? Жирафий, страусиный… можно довериться судьбе.



nextflu.ru

Некоторое время назад мы представляли уважаемой публике наши open source продукты для веб-разработчиков — редактор elRTE и файловый менеджер elFinder. После анонса мы получили немало отзывов и надо сказать были изрядно удивлены, что интерес к файловому менеджеру оказался заметно выше чем к редактору.

Мы почесали головы, свалили в одну кучу все безумные идеи о том, каким должен стать новый elFinder, просеяли их через сито основной концепции «минимально необходимый функционал», многократно пропустили через мясорубку кодинга, приправили новыми вкусными возможностями и долго томили в печи тестирования.

И сегодня с удовольствием от хорошо сделанной работы предлагаем попробовать наше фирменное блюдо elFinder!

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

В этой статье я расскажу вам о сервере службы каталогов 389 Directory Server (он же Fedora Directory Server, он же Redhat Directory Server). Так уж повелось, что для доступа к серверу каталогов используется протокол LDAP. Если вы не работали с LDAP, я очень рекомендую ознакомиться со статьями в Wikipedia (тут про cлужбу каталогов, а тут про протокол LDAP).

Итак, сначала кратко о том, зачем же вообще использовать сервер службы каталогов (далее — LDAP-сервер). LDAP-сервера, в основном, применяются для централизованного хранения учетных записей, и всего, что с ними связано. LDAP-сервер представляет собой иерархическую БД, а значит в нем можно хранить любые данные.

Казалось бы, вполне логичен вопрос: а почему именно LDAP? Что мешает хранить учетные записи в MySQL или PostgreSQL? Ответ очевиден — ничего =)

Но над любой RDBMS служба каталогов обладает целым рядом преимуществ:

• Это стандарт. Многие приложения поддерживают аутентификацию/авторизацию через LDAP;
• Данные хранятся как иерархическое дерево, что позволяет делать эффективные операции поиска, выделив нужную часть дерева;
• Число операций чтения в тысячи раз превышают число операций записи, в связи с этим появляется огромное число плюсов: нет необходимости применения транзакций и rollback'ов, репликация работает без проблем, которые присущи RDBMS;
• Приложение должно видеть одну и ту же информацию на всех серверах службы каталогов, если сервер не хранит информацию, нужную клиентскому приложению, он может сам запросить ее у другого сервера или перенаправить само приложение к другому серверу;
• Из-за описанных выше свойств службы каталогов, этот сервис отлично масштабируется горизонтально.

Выбор сервера службы каталогов пал на 389 Directory Server. История этого LDAP сервера тесно связана с компанией Netscape (если интересно, почитать историю можно тут).

Не всегда есть возможность, да и не всегда надо, строить полноценный туннель с интерфейсной парой адресов. Иногда нам нужно лишь «прокинуть» вполне определённые порты.

Тут важно понимать, что туннель можно организовать как изнутри сети, к ресурсам которой вы хотите получить доступ, на внешний ssh-сервер. Также можно организовать туннель с хоста в Интернете на пограничный ssh-сервер сети, чтобы получить доступ к внутренним ресурсам.

Несколько читателей блога webo.in просили меня выложить конфигурацию связки nginx + Apache, на которой работает сервер. Хотя это и не относится напрямую к теме клиентской оптимизации. Однако, большинству специалистов, занимающихся клиентской оптимизацией, будет интересно узнать о настройке нескольких хостов для выдачи статики и пара других трюков, связанных с балансировкой запросов.

Также я подробно комментирую все настройки конкретно Apache, которые так или иначе относятся к самой оптимизации времени загрузки страниц.

читать дальше на webo.in →

Плазмоид (plasmoid) — это виджет рабочего стола в KDE4 Desktop. Любой видимый элемент управления на рабочем столе является плазмоидом, будь то часы, системный трей, монитор загруженности процессора или окошко с прогнозом погоды.

Этот урок описывает создание плазмоида, умеющего делать запросы к некоему серверу и показывать полученный результат. Так как сервер требует авторизации пользователя, будет разобран процесс хранения данных учетной записи пользователя в KWallet. Язык разработки: Python.

Недавно друг попросил установить ему Windows 7. Так уж вышло, что мой DVD-привод давно не работает, зато есть флешка на 8 ГБ. Тема создания загрузочной флешки с Windows 7 из-под Windows уже давно сильно разжевана в Сети. Но я пользуюсь Ubuntu, так что пришлось искать другое решение. На самом деле, как мне кажется, оно еще и проще.

Сегодня я хочу рассказать вам, как я настраивал любимый всеми редактор Vim (который в одном режиме пищит, а в другом — все портит) для написания кода на Python. Статья расчитана на начинающих виммеров.
У меня получилась такая картинка:

Основная мощь языка XPath заключается в осях, позволяющих добраться до любого элемента в исходном документе. Рассмотрим применение таких редкоиспользуемых осей, как ancestor, descendant и self.

ancestor

Задача: получить атрибут id элемента-«прадеда» foo.

Обычно в таких случаях начинают рисовать лестницы:

../../../@id

Такая запись плоха тем, что малопонятна без знания исходного xml. Автор рекомендует в подобных случаях использовать более информативное выражение:

ancestor::foo[1]/@id

Эта запись не только даёт представление об искомом элементе, но и продолжает работать даже в том случае, когда текущий элемент изменил своё положение в дереве.