когда вышел Ubunty 9.04 Jaunty Jackalope, я немедленно скачал torrent официального DVD и положил в папочку. А памятуя прошлые обновления, когда новые версии пакетов тянулись с официальных серверов в час по чайной ложке, решил в этот раз использовать пакеты с диска. Но мне вовсе не хотелось вначале записывать образ на болванку, а потом слушать урчание привода, который всяко медленнее винчестера. Казалось бы, что может быть проще — примонтировать iso в файловую систему и указать инсталлятору на неё. Но не тут-то было!
во время предыдущего обновления я безуспешно пытался проделать эту операцию. Однако в этот раз я решил пойти до конца. Вначале создал каталог /media/ubuntu. Работать с iso-образами я предпочитаю через гуй простенькой программки gmount-iso, но того же можно добиться и через /etc/fstab:
вручную вставить диск в инсталлятор невозможно, о чём предупреждает man apt-cdrom, поэтому положимся на него:
sudo apt-cdrom -d /media/ubuntu add
он зачем-то отмонтирует диск и попросит «вставить» его снова, но это не создаёт особых трудностей : )
после этих операций в /etc/apt/sources.list появилась запись:
deb cdrom:[Ubuntu 9.04 _Jaunty Jackalope_ - Release i386 (20090421.3)]/ jaunty main restricted
тут я обрадовался и запустил инсталлятор. Тот пошуршал байтами и попросил меня вставить диск в привод /cdrom/. «Ага!», — сказали мужики и задумались. Именно в этом месте я забил в прошлый раз. Но сейчас на глаза мне попалась строчка из мана apt-cdrom: «Configuration Item: Acquire::cdrom::mount.» Что-то похоже я уже видел в настройках apt. Например, в /etc/apt/apt.conf.d/10periodic:
Дальше было просто. Я создал файл /etc/apt/apt.conf.d/35cdrom с одной строчкой:
Acquire::cdrom::mount "/media/ubuntu/";
после этого пакеты ставились и продолжают ставиться большей частью с диска: «Need to get 929kB/5920kB of archives.» Впрочем, локально того же эффекта можно было добиться, указав эту опцию в командной строке к dist-upgrade:
впрочем, почему бы не проверить? Что говорят глобальные сервисы статистики на эту тему? W3Schools считает только своих посетителей, которые в большинстве своём веб-разработчики, поэтому даже не буду смотреть его сторону. Ещё есть, например, Net Applications и StatCounter. Первый из них — в своём роде Alexa — известный, древний и однобокий (подсчитывает преимущественно американские сайты). А вот второй показывает лучшее соответствие заявкам компаний. Получается 30%/270млн у фф, 3%/27млн у оперы и 2%.20млн у хрома, который ещё в конце года рапортовал как раз 10 миллионов
в общем, можно не верить StatCounter'у и Опере, а можно не верить только Net Applications. Жаль только, что блоггеры обычно хватают только первые попавшиеся цифры, и чаще всего ими оказываются данные именно NA
…чтобы я мог написать адрес и попасть на нужную страницу, как я это с лёгкостью делаю на Википедии
гик вроде меня помнит точную структуру адреса на важных ему сайтах, и при необходимости вводит её вручную и без опечаток. Но что если продолжить поворачиваться лицом к человеческим ошибкам? Кто-то может опечататься, или пропустить сегмент, или сплоховать ещё одним из сотен способов. Сейчас почти везде такой пользователь получит сообщение типа «Страница не найдена». Но мы-то можем сделать лучше
вспомните: для википедии можно набрать в адресе «ru.wikipedia.org/django» и оказаться на нужной странице «http://ru.wikipedia.org/wiki/Django». Теперь представьте, что для других сайтов можно набрать, например «ilyabirman.ru/уникод», и оказаться на странице «http://ilyabirman.ru/meanwhile/2009/04/15/2/» с заметкой «Биты, Болк и Уникод», или быть перенаправленным с «blog.arty.name/цифровое видео» на «https://blog.arty.name/2009/ssyilka-o-tsifrovom-video/». Здорово, не правда ли?
что для этого нужно? Всего ничего! Если не удалось отрезолвить адрес, не спешить показывать 404 ошибку. Перед этим нужно взять из такого адреса путь и засунуть его в полнотекстовый поиск по основному контенту сайта: новостям, статьям, людям, фильмам — чему угодно. Если есть результаты, взять первый из них и перейти к нему. Вуаля!
конечно, желательно при этом подсмотреть у википедии и ещё одну правильную мысль: при таком редиректе желательно показать пользователю сообщение типа «вы направлены сюда с поискового запроса такого-то, кликните сюда, чтобы посмотреть другие результаты»
есть и быстрый+грязный вариант решения: редирект на гугловский «мне повезёт» по своему сайту и с этой же строкой поиска ; )
такую мысль можно развить в более сложный, но более универсальный и «правильный» вариант. У нас уже есть стандарт OpenSearch, относительно распространённый в вебе. Когда человек начинает писать в адресной строке, браузер берёт домен этого адреса, вытаскивает по XRDS для него путь opensearch, подставляет в этот путь всё после домена, берёт с полученного адреса варианты подсказок и предлагает их пользователю. С человеческой точки зрения это выглядит так: указал домен, после него написал поисковый запрос, выбрал нужный результат и перешёл к нему — почти ничем не отличается от опыта с уже существующими браузерами типа хрома или фф, только результативнее!
конечно, у предложенного есть серьёзный недостаток: это не будет работать на сайтах ленивых разработчиков, то есть, на большинстве сайтов. Но зато, с другой стороны, в схеме напрочь отсутствует большой брат, за которого поругивают эксплорер с его системой подсказок и, если мне не изменяет память, хром с его гуглопоиском. Всё кошерно распределённое и основанное на существующих стандартах : )
все веб-разработчики знают про GET/POST, многие — ещё и про PUT/DELETE. Я также наслышан о том, что WebDav добавляет несколько специфичных для себя методов. Но тут внезапно! обнаруживаю в статье «REST worst practices» отсылку к новому глаголу PATCH, черновик спеки которого уже почти готов. Предполагается, что этот метод будет использоваться очень широко, потому что решает очень общую задачу: обновление только части объекта. Проблема в том, что PUT заменяет объект полностью, а иногда удобнее исправить только одну небольшую часть. Очень разумное предложение, буду ждать выхода стандарта