Sply Splyeff

22:30: freebsd dirhash patch
Проще оказалось порыться в исходниках и поправить для себя dirhash. Добавлена новая sysctl переменная, через которую можно указывать минимальный объем памяти, который мы гарантируем для тех каталогов, которые активно используются (последнее время доступа меньше, чем dirhash_reclaimage). Хэши неиспользуемых каталогов при этом очищаются, навечно не остаются.

В этом случае удобно поставить dirhash_reclaimage на 30..300 секунд. А minmem либо сделать половине maxmem, либо экспериментальным путем для нужно величины своего хэша. У меня около 150 Мб получилось. Не уверен, что в таком виде в PR субмитить нужно, все-таки слишком много ручек наружу, по линуксовски как-то.

А я из-за этого, было, на linux, да с кучей переделок переносить проект собирался.

( Read more... )

21:12: freebsd dirhash
Пока разбирался с бэкапами, нашел то-ли неприятную фичу, то-ли баг с dirhash у freebsd (на 8.3 тоже).

Память под dirhash освобождается в первую очередь при любом приближении к завершению свободной памяти. Даже когда есть куча inactive (в моем случае 1.5 Гб), освобождается сначала dirhash, который на самом деле очень нужен в работе - 6 млн. файлов в одном каталоге. После особождения dirhash он по-новой создается, уже вытесняя под себя inactive. Но для создания хэша на 6 млн ему требуется около пары минуты, а на это время тормозятся все процессы, работающие с этим каталогом.

С одной стороны, выглядит как баг, т.к. вред есть. Но может быть другого простого способа вытеснения устаревших записей из dirhash и нет. Разве что объединять их с обычными дисковыми буферами и освобождать по общему принципу.

Неприятно получается, когда свободная память немного плавает у границы - dirhash сбрасывается каждые 3-5 минут. Сейчас как временный вариант пришлось при уменьшении свободной памяти до 80 Мб занимать и сразу освобождать через malloc памяти на 1 Гб, чтобы освободить памяти побольше и надолго (20-30 минут). Но видимо разделять все на подкаталоги, все-таки неудобно 6 миллионов в одном каталоге.

17:19: бэкапы
Кроме удобного сбора бэкапов нужно предусматривать быстрое развертывание. Для больших объемов инкрементные бэкапы становятся злом. Вот вчера полетела файловая система с приложениями и кучей картинок, на 160 Гигов. Образ диска перенести занимает около часа. Но т.к. копии хранятся на отдельном большом сервере бэкапов, то остается пофайловое копирование. С помощью rsync это было бы около двух суток, после небольшой допиливания через cpio получается около суток.

Отсюда мораль: для некоторых видов бэкапов, пусть и очень большого объема, нужно хранить резервные копии в виде образов диска, готового к немедленному употреблению. Такое вот нечто между горячим и холодным резервом.

22:41: какое могло бы быть реальное облако
У нас уже есть JVM с автоматическим профилированием и JIT-компилированием с оптимизацией по результатам профилирования.

Похожий подход можно было бы использовать для автоматического распараллеливания на большом числе вычислительных узлов "процессор+память". Скажем, есть какое-то java-приложение, да даже хоть любое существующее веб-приложение в tomcat. Есть N вычислительных узлов, на которых работают JVM, знающие друг о друге, невидимо для приложения передающие данные друг другу, и вызывающие методы друг у друга. Задача профайлера собирать статистику по потреблению процессора методами и статистику по объему данных, которые нужно будет передать между узлами для выполнения этого метода. Далее нужно кластеризовать области данных по их использованию методами и методы по вызовам других методов. На основании чего оптимально раскладывать данные и методы на узлах таким образом, чтобы минимизировать передачу данных между узлами.

Да, при этом внешняя СУБД не только не нужна, но даже вредна, т.к. является бутылочным горлышком автоматического масштабирования. Данные нужно хранить в самой JVM, для персистентности сериализуя их на локальные диск узлов или на общее хранилище. Получится автомтический шардинг данных.

Решать как и что параллелить уже должен компьютер, а не программист.

Возможно, такое можно было бы организовать и в single system image, например, на Kerrighed. Но на первый взгляд выглядит, что работы должно быть на порядки больше, чем для JVM.

15:43: где python хуже php, update
Предыдущее обвинение в вахтеризме отменяется, нужно ждать подвоха и внимательно читать документацию. Питон - не вахтер, он самый просветленный. Там, где все perl, java, ruby и даже php в качестве limit у split считают число получившихся частей, питон считает что limit - это число разрезов. Да, оно на 1 меньше числа кусков.

21:35: где python хуже php
Снова столкнулся вахтерским синдромом у питона, в string.split.( Read more... )

17:24: Сейчас заказывал всякого пластика для серверно-производственных нужд. Разные хорошие листовые пластики продают поставщики материалов для рекламной продукции. Мужик, оформляющий заказ, просто так легко у нас его принять не мог. Он долго выяснял, зачем на пластик, что мы с ним будем делать, знаем ли мы как его резать и обрабатывать. Собственно, оформил он заказ только после того, как убедился, что материал на полезное дело пойдет и не загубим его по незнанию.

11:10: xen, что полезного могут дать клоны виртуальных машин
Давно уже вертелась в голове идея реализовать консистентное резервное копирование через клонирование виртуальной машины, ее последующий чистый шатдаун и копирование получившейся копии. В Xen готового механизма для этого не было, и долгое время идея оставалась лишь идеей. Недавно созрел чуть-чуть допилить и эту часть - все в итоге работает как и предполагалось. Совсем без даунтайма и без необходимости отплясывать с FLUSH TABLES, sync и прочим. Потом даже поддался приступу графоманства, описывая как и почему.

21:55: французы тролли
Петя Диденко пожаловался на французов, подтверждая общеизвестное, что французы не любят говорить по английски. У меня есть подозрения, что это у них либо общенациональный троллинг туристов, либо такая изощренная лень напрягать говорильный мозговой центр.

Принимая во внимание сведения о нелюбви французов к английскому, я честно запомнил числительные, десяток других слов и пытался разговаривать в Париже со всеми французами на такой смеси французского и итальянского. И что в результате? Практически во всех случаях собеседник пять-десять секунд пытается тебя понять (понять можно, если немного напрячься), потом делает вид, что очень мучается от твоего французского и считает невозможным что-либо разобрать, после чего легко переходит на английский и быстро выясняет, что ты от него хочешь.

21:55: SaaS без web
Лет пять назад было понятно, почему SaaS скорее всего должен работать через веб-интерфейс - каналы слабые, тормозило бы все. Через веб тоже, конечно, тормозит, но не так сильно.

Сейчас с каналами стало почти хорошо и будет еще лучше. И можно не извращаться, упаковывая все в неудобную и затратную прослойку html и javascript, а отдавать родной GUI приложения через VNC, RDP и т.п. Пользователь даже может особо не понимать, через что он его получает, т.к. VNC в виде java-апплетов прекрасно работают без установки. Виртуализация позволяет на сервере легко клонировать новые экземпляры рабочих окружений для какого угодно числа пользователей. Многие уже сейчас пользуются 1C по RDP с арендованного сервера, на скорость и удобство не жалуются. Autodesk мог бы Autocad так, на повременно оплате сдавать.

Ведь примерно с таким представлением лет десять назад весь SaaS и ожидался. И как-то на другое съехало.

20:35: системные утилиты на питоне
У нас в системе все больше и больше служебных скриптов пишется на питоне. В основном, они нужны для постоянного контроля и регулирования параметров (диски, сеть, виртуальные машины) и, в идеале, должны постоянно работать. Вычислений мало, но память тратится помногу: одного демона с минимумом функций запустил - 5 Мб улетело. Уже сейчас на системные нужды уходит 250 Мб. На ядро и бинарники - около 90 Мб, все остальное съедает среда выполнения питона и скрипты. А системы, по своей сути, как-бы embedded, и просто так отдавать память жалком.

Вот диллема. Писать все на C - замедлить в 10 раз разработку. Разработку системы, у которой многие требования уточняются и меняются по результатам внедрения. Что-то, конечно, пишется на C, но как только вылезает взаимодействие по сети, анализ статистики и т.д., то С становится использовать труднее.

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

Сейчас частично само собой получилось что-то ровно наоборот - вместо постоянного висения в памяти утилиты запускаются либо по требованию, либо через inetd и sshd, либо по cron. Некоторые были реализованы как программы-сенсоры в виде shell-скриптов (кстати, очень скромных в потреблении), которые при необходимости в какой-то реакции запускают тяжелую артиллерию питоновского скрипта.

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

Теперь вот, глядя на это все появляется соблазн не переписывать все на чистых питоновских демонов, а принять и полюбить сложившееся положение дел. И вовсе даже наоборот, закрепить его в виде некоего design guide, который бы прямо предписывал, что в целях борьбы с транжирством ресурсов избегать демонизации и больше писать на shell.

А что еще остается?

19:11: отключение воздуха
Приходит сегодня письмо с темой "Отключение воздуха". У меня уж было картинки лунных поселений перед глазами пошли, но вещь, в итоге, банальная - нас, оказывается, снабжают воздухом и будет временное прекращение для каких-то работ.

23:32: Трудности перевода
Читаю я сейчас "Пражское кладбище" У. Эко. Хороший увлекательный роман. И основной сюжет, и детальки всякие. Начал читать его параллельно - на итальянском и в русском переводе Е. Костюкович, бессменной переводчицы Эко. Сейчас тоже некоторые места перечитываю по-русски - есть такие куски, где либо много слов слабопонятных, либо гора сложноподчиненных предложений. Иногда просто перечитываю чтобы проконтроллировать, что все понял правильно. И обнаружил несколько странных вещей. Учитывая, что абы кто Эко переводить не будет и Костюкович преподает итальянцам художественный перевод, это еще страннее.

1. Насколько отличается язык, разнообразие слов, их окраска. Т.е. русский перевод выглядит на порядок более богатым, сложным, глубоким, чем оригинал. С одной стороны, это можно обяснить тем, что "русский язык необыкновенно богат". Как-то даже уязвляли одного итальянского дедка - он похвалялся, что у какого-то их писателя словарь на 50 тысяч слов, а мы в ответ ему Пушкина или Толстого с 240 тысячами (хотя может быть и соврали, не уверен). Точно не подсчитывал, но есть ощущение, что разнообразие слов перевода заметно превышает оригинал. С другой стороны, важно не количество слов, а их сочетания, насыщенность ассоциациями и образами, изменения этих ассоциаций, накладываемые контекстом. Может быть мне менее сочным выглядит текст только из-за того, что я на итальянском художественную литературу читал мало, и не обросли слова яркими и богатыми образами. Но,

2. Приглядевшись, можно везде заметить настойчивое улучшение переводчиком оригинального текста. Ладно уж богатство образов, выбор из десятка синонимов того единственного, который наиболее точно отобразит тонкий оттенок смысла. Но часто достаточно нейтральный смысл оригинала в переводе становятся преувеличенно окрашенным, чаще всего, в негативную сторону. Например, в переводе мясник сначала "отвечал тот осклабясь", потом "ухмыльнулся ... вы-де ежели взглянуть, вообще мальчик", от чего складывается впечатление, что мясник этот - какой-то неприятный тип. Хотя в оригинале просто сказано, что "ответил тот смеясь" и "сказал, что я вечно молодой". Нормальный такой мясник, зря только напраслину возвели.

3. Тщательность в улучшении авторского текста переводом означает, что времени хватает с избытком, и можно бы переводить вдумчиво, аккуратно. Но, наоборт, местами улучшения компенсируются небрежностями. Например, в переводе в одном месте "Держась за перила руками, а руки у них как лилии, три в белых одеждах девицы, неслыханной красоты" ... "монахини", "хорошо-бы их освободить и повесилить". От чего их освободить? А вот от чего, в оригинале: "Вцепившись в железную решетку руками как лилии, три девицы в белом, красавицы, смотрели безмолвно".. "монахинии". Соответственно, освободить их предлагалось из "темницы".

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

И самое странное-то что - ведь и правда получается, что русский перевод "Пражского кладбища" лучше оригинала. Интересно, знает ли об этом Эко? Может быть он и сам так хотел. А улучшательство у нас всегда в крови. Это и еще Лесков с блохой подкованной заметил. И Гоблин с переводами подтвердил.

03:04: Ищу себе блютус гарнитуру на ухо. Если верить отзывам, все плохо - дохнет, шумит, болтается и падает. Хоть кому-нибудь повезло с гарнитурой?

03:12: Вопрос о необходимости документирование или автоматизации.
1.

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

На описание задачи требуется X времени. На составление инструкции требуется XX времени. На составление инструкции, дополнение ее вариациями, если условия отклоняются так или иначе, на проверку ее на отсутствие ошибок, требуется XXX времени. Если решение можно программировать/автоматизировать, то на написание программы решения, с проверкой на различные исходные данные и минимизацию ошибок, требуется XXXX времени.

На решение "с нуля" требуется Y времени. На решение по недокументированному образцу требуется YY времени. На решение по инструкции требуется YYY времени.

Вопрос: Как можно решить, какой уровень детализации документации или автоматизации требуется?
Ответ: Сравнив стоимость разработки документации со стоимостью воспроизведения и додумывания при повторном решении.

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

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

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

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

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

2.

Или вот реальный случай, который я сейчас пытаюсь под это подогнать. Есть отказоустойчивый кластер, который еще и географически распределен. Слово "отказоустойчивый" здесь немного преувеличение, т.к. требуется только синхронизировать мастера на бэкап и при выходе мастера из строя или недоступности его больше часа, переключаться на резерв. Возникновения такой ситуации вероятно, но редко - вполне может быть и раз в несколько лет. Для такой частоты отказов будет приемлемым время простоя и в несколько часов. Сейчас у нас в эксплуатации 5 таких систем.

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

Можно потратить день и написать инструкцию с объяснением как и что работает, как и что поднимать, если упадет. В принципе, вещь хорошая. Но чайник по ней сработать не сможет. Для специалиста инструкция уменьшит время поднятия бэкапа с двух часов до полутора. Можно не писать инструкцию, а предложить читать рабочую документацию. Но на поиск, изучение и фильтрование в ней полезного, уйдет даже больше 30 минут выигрыша.

А еще схема репликации и запуска мастера/бэкапа может полностью поменяется через год.

Если бы таких систем было не 5, а 50, то был бы другой ответ - выгоднее автоматизировать. Цена разработки скрипта остается такой же, в то время как цена повторного исполнения увеличивается в 10 раз.

Впрочем, здесь в пользу составления хотя бы простой инструкции есть другой аргумент. Инструкция в каком-то смысле является моделью системы. Какие-то ошибки в реализации системы могут оказаться заметными только в этой модели, т.е. при составлении инструкции.

3.

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

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

В нашей реальности этим вовсю генные инженеры занимаются.

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

Знание того, как преобразуется из итальянского в испанский произношение или написание близких по смыслу слов, дает тебе возможность наполовину понимать простую неторопливую внятную речь. Несколько десятков распространенных испанских слов, хранящихся в памяти, улучшает это еще на десяток процентов. Но в итоге, результативность диалога упирается в то, насколько собеседник умеет, хочет и старается тебя понять. В магазине/ресторане/гостинице, где кроме прочего ограничен лексикон и выбор тем, тебя поймут всегда. Хозяйка квартиры, когда рассказывала про особенности отопления, окон и замков, вопросы понимала, но считала, что чем больше разных слов она скажет, тем лучше я ее пойму, из-за чего говорила много, быстро и непонятно. Старик, который выскочил из дома, перед которым я тупил в поисках нужной мне улицы, поймал меня, предложил помощь, обстоятельно рассказал мне какие церкви и памятники есть рядом, но не смог понять мой вопрос, в какой стороне нужная мне улица.

22:08: украденные 900 mbps
Сейчас прогулялся по забавным граблям. Есть две площадки, соединенные оптикой - гигабитные длинковские медиаконвертеры. Когда-то давно, при подключении, погоняли соединение на максимальной скорости - гигабит более-менее получался. Сейчас вдруг обнаружилось, что пропускает только 100 мегабит.

Медные интерфейсы видят оба медиаконвертера на 1000 mbps. В паспорте длинков написано, что они по оптике только гигабит поддерживают, т.е. на 100 mbps между собой не соединятся в принципе. Задержки пингов по 0.05 мсек тоже показывают, что реальная скорость - гигабит. Но больше 12 Мбайт/сек не передается.

Проблема оказалась в особенностях работы QoS/шейпера. На самих интерфейсах ничего не шейпилось, но шейпились другие интерфейсы. А шейперу нужно знать опорную скорость интерфейса, чтобы правильнее от нее нарезать мелкие потоки. Вместе с другими портами, для этих гигабитных портов была указана опорная скорость 100 mbps. Но шейпер умный и дальновидный - если ему сказали, что опорная 100, то он сам позаботится о том, чтобы реальность совпала со своим описанием и зашейпит по своей инициативе гигабит до 100 мбит.

03:17: advanced format
Потестировал диски с Advanced Format (4K-секторы). Чтобы почувствовать, как падает производительность на записи блоков, размером меньше чем физический сектор, и блоков по 4-К, не попадающих в один физический сектор. С удовлетворением все это увидел.

А LVM принес приятный сюрприз: даже если раздел (DOS-partion) не выровнен по границе 8 секторов, то LVM это учитывает и созданные в этом разделе тома выравнивает самостоятельно.

00:04: verdejo
В Испании из заготовленного ранее списка вин мало чего нашел. Зато открыл для себя белое из винограда Verdejo (Вердехо), которое там продается на каждом шагу за 7-10 евро. Очень ароматное, простое, не совсем универсальное, но к еде хорошо. В одном ресторане его даже подали под видом vino de la casa, но это уж ресторан сам по себе был с изысками.

У нас verdejo в испанских винах встречается заметно реже, но вполне можно найти по 600-700 руб - и наценка не заряженая.

Это вино еще называют Rueda Verdejo - с именем его родного региона. Verdejo смешивают и с другими виноградами, чаще всего с Viura и тогда называют только по региону - Rueda. Кому как, но мне смешанный вариант не понравился - характерный запах практически пропадает. Поэтому если пробовать его в первый раз, лучше поискать чистое вино, только из verdejo.

02:42: нерепрезентативная выборка
За последние 2 месяца прочитал 8 книг. По рекомендации. Разные автора, разные жанры. В 5 из них вместе или по отдельности упоминаются или цитируются книги Джейн Остин и Шарлотты Бронте - "Гордость и предубеждения" и "Джейн Эйр".

15:16: подсветка синтаксиса
Привык к тому, как vim подсвечивает код. Приятно. Код без подсветки читается ощутимо сложнее.

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

19:54: венец всего, OSPF
Тут с промежутком в пару дней выкатились две аварии, связанные с OSPF. С разными причинами, на разных каналах, и сам по себе OSPF там не причем. Но все в OSPF упирается и не работает.

Первое было на прошлой неделе. У арендуемого влана пропало исходящее направление, а входящее осталось работать. Как смог сделать это провайдер - нам не интересно, есть тыщща и один способ поломать линк так наполовину. Но как на это отреагировал OSPF? Изящным глюком! Роутер считает канал живым как и раньше, поскольку видит адвертайзинги, приходящие с другой стороны. О том, что отправленное не доходит он не знает и продолжает слать все в сломанный канал. В получаемых им анонсах приходит также маршрут по умолчанию, поэтому в сломанный канал шлется почти все. И чтобы ущерб был максимальным, от него еще и соседи принимают маршрут по умолчанию, и отдают ему свое добро, чтобы он переслал его в никуда.

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

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

Сначала на канале пропал трафик. Потом выяснилось, что на концах отвалился OSPF. Пинги и прочие пакеты ходят нормально, но соседство OSPF не устанавливается. Ага, оказывается ходит все, да не все - OSPF Hello на другом конце не видно. Ручные ресеты не помогают, арсенал шамана исчерпан - когда других причин нет, остается звонок в техслужбу оператору линка, спросить не тырят ли они наши OSPF пакеты. Суппорт вместо недоумения говорит, не вдаваясь в детали, что через пол-часа все починит. Тогда недоумеваю я: тырят, значит?

Через час все со скрипом починилось. Выяснилось, что причиной была авария на MSK-IX - у них как-раз виден провал на графике в районе 18 MSD. Вот они, издержки глобализации. Как авария на точке обмена в Москве повлияла на внутигородской L2-канал в Питере понятно не очень. Возможно, на MSK-IX случился броадкастовый шторм, он долетел до питерского коммутатора, а уж коммутатор чтобы уберечься стал фильтровать еще и мультикаст OSPF.

Два-три года до этого с OSPF все было спокойно. Выборы, что-ли?

21:24: о хорошем
Вчера нам привезли стойки. Здание большое, в нем несколько десятков организаций с производством, разгрузочные ворота только одни и одновременно с нами загружались/разгружались еще несколько машин. Нашу коробку с крепежом забыли у разгрузочных ворот. Мы там пока бываем редко, с соседями не познакомились и не примелькались, но часа через полтора эту коробку принес нам мужик с чужой погрузки, который в перерыве между машинами не поленился опросить несколько этажей и в итоге нашел нас.

04:13: закопать стюардессу
Недавно где-то прочитал, что в последнее время стали чаще высказываться предложения отменить изучение латыни и древнегреческого в итальянских классических лицеях.

Классических лицеев - их дофига, примерно как у нас ПТУ или техникумов. Там, конечно, есть и именно техникумы, где такого зверста с мертвыми языками нет. Но лицеев намного больше, это самый распространенный способ получения полного среднего образования.

03:56: Очень нравится читать итальянский Wired
Реклама: шмотки, машины, часы, парфюмерия, украшения, мебель. Нет крепкого алкоголя, в отличии от американского wired. Нет ноутбуков, фотоаппаратов, мобильников. Есть реклама вечеров моды в Милане и Риме, проводимых Vogue. В разделе фетишей - поло с люрексом от Прада за 600 евро, сумка для ноута от BottegaVeneta за 2400 евро.