Это — продолжение, вернее ответ на задачу из статьи "Лингвистическая загадка. Переводим с мертвого языка".

Времени нет катастрофически, но как известно его никогда не бывает, а раз уж обещал, статью приходится писать. Засим еще раз извиняюсь за опоздание.

Ответ

Для нетерпеливых сразу ответ, который кстати на момент написания статьи, кроме единственного человека (не с хабра), полностью не разгадал никто. Но об этом ниже…
Упомянутая известная фраза про «Глокую куздру» (привет AndreyDmitriev), что есть цитата из книги Успенского «Слово о словах», была коварно помещена мной в середину текста. Остальное, как уже говорилось, добил другими из той же темы, причем немного даже в «старорусской» манере…

Ответ можно найти здесь — Лингвистическая загадка. Переводим с «мертвого» языка. [§2] Разбор полётов.

Навеяло постом «Продолжение дилетанта».

Хотя оригинал «Манускрипт Войнича. Маньчжурский кандидат» по своему шедеврален, с подходом с лингвистической стороны, изложенной makondo, я бы местами пожалуй не согласился. Но сам разбор полетов прочитал запоем. В отличии от «Продолжение дилетанта», имхо.

К слову, я никогда не понимал людей, пытающихся вот так — нахрапом брать подобные «лингвистические» задачи, и делать на основании (иногда даже огромной) проделанной работы, но базирующейся на сомнительных исходных выкладках, далекоидущие выводы.
А некоторые методы вообще доставляют, в криптографии их назвали бы — брутфорсом и серьезно к анализу «чего либо» так никто не подходит.

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

Скажем так, тот язык за многие лета претерпел некоторые изменения.

Собственно текст

მეაგ პგლოეზგასელ პაგდლრეოლმელეოგ გილრაგლახაგ მოლ კეუგლზდლიმეილ პეალკგლეგ სფაგიხაგ, ეპეალ ფაგსცლგიბიშჩულდგ პაგდლრეოლეუგლშჩეილ, დოლ ფაგშცელეოგეუგლტ პაგდლრეოლინეგილ. გილრაგელეო კეუგლზდლოლ სტიკეალ პაგდლრეოლმეუგლრეოლ პეალკგლეგ ელ კეუგლლდეოჩედგეგ პეალკლეამკეოლეგ. დოლ მეაგ პაგდლიტ უგ პეალკგლეგ კეუგლზდლეგ, ოლ უგ კეუგლზდლეგ პეალკგლეგ ბლგიდ რეცინოგ ნაენოგ, ეპეალ ეოგლ სცლგოშმაგ პაგდლრეოლმეუგლრ, ელ ნმაეუგლ ტოხგ პაგდლრეოლმეუგლგტაგ.

Задача — то же, но по-русски.

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

Есть такая довольно популярная линейка рутеров в Европах — AVM Fritz!Box. Это и рутер и мини АТС и для VOIP- и для аналоговой или ISDN-телефонии и медиа-сервер и вообще все-что-хочешь в одном.
Особенно топовые модели у AVM всегда отличались «умом и сообразительностью»(TM). Вплоть до того, что некоторые модели имеют систему «умный дом» (на базе FHEM сервера) и кучу других вкусностей.
Ваш покорный слуга плотно подсел на фритцы лет дтцать назад и ни разу не жалел (до недавнего времени).
Скажу сразу — уязвимость это мягко сказано — это просто огромная дыра. И по моему скромному мнению, во всей этой истории AVM себя повела не совсем, скажем так, адекватно.

При подключении переносного диска, таблета или смартфона через USB, например для зарядки, существует ненулевая вероятность, что устройство будет заражено вредоносным ПО. Многие, зная что система спросит подтверждения для связи с компьютером, даже не задумываясь, заряжают свой смартфон где угодно. Но очень не многие знают, что аппаратная часть, отвечающая за связь, тоже имеет лазейки. Иногда это «бэкдоры» специально оставленные производителем для отладки или восстановления устройств, иногда это просто уязвимость в протоколе, программной или железной составляющей системы.

Например, в определенных кругах упорно курсируют слухи (имхо пока совершенно ничем не подтвержденные), что для рутового доступа (неограниченный доступ к устройству) к некоторым моделям, например от Samsung, с Android на борту, достаточно определенным набором сигналов «постучатся» по USB.

Но известны и реальные подтверждения взлома смартфонов — на конференции Black Hat 2013 проходящей в Вегасе специалист по безопасности Billy Lau успешно продемонстрировал взлом iPhone, когда телефон подключенный для зарядки по USB к его мини-компьютеру сам сделал звонок. В принципе он мог бы установить на телефон любую программу (не из Apple Store), которая могла бы себя глубоко интегрировать в операционную систему устройства и например позволяла бы отслеживать действия пользователя на смартфоне (набор на клавиатуре, в том числе пароля), его местоположение (GPS координаты), снимать и отсылать скриншоты экрана и т.д.

Сразу оговорюсь, что речь пойдет не о программах типа link2sd. Принцип похож, но связывать мы будем не программные каталоги, а каталоги данных этих программ, например /sdcard2/Navigon -> /sdcard/Navigon или /mnt/extSdCard/Books -> /sdcard/Books и т.д.
Кроме того, нам нужен рут (куда ж без него). Кстати, после того как я узнал про эту программу, это для меня очередной аргумент за root.

Многие владельцы андроид смартфонов или таблеток с небольшей встроеной памятью наверняка сталкивались со следущей проблемой: вставлена большая sd карта (например 16, 32 или даже 64 Гигабайт), но после установки нескольких тяжеловесных программ наше устройство или очередная программа с наглостью заявляет, что на карте не хватает места. Иногда сама программа небольшая, но после установки лезет в интернет и тянет на смартфон гигабайты данных.
В очередной раз получив сообщение «Нет места» и заглянув на карточку видим, что она практически пуста, зато внутренняя память устройства забита под завязку.
Это происходит потому, что внутренняя память часто используется как каталог по умолчанию для многих программ. Дело в том, что она монтируется как /sdcard, что исторически всегда было внешней sd картой (раньше так оно и было на всех смартфонах). Внешняя же sd карта монтируется в этом случае как /sdcard2, /mnt/sdcard2, /mnt/extSdCard или даже /sdcard/.externalSD. Я так понимаю, что это делается изготовителями, чтобы устройство работало из коробки, т.е. совсем без sd карты.

Многие «недобросовестные» программы всегда хотят читать/писать данные из/в каталог /sdcard/НазваниеПодставить. Редко это можно изменить в настройках программы.
В результате имеем, что имеем, и несколько возможностей чтобы поправить сложившееся положение:

• перемонтировать каталоги: внешнюю sd карту на /sdcard, а внутреннюю на /sdcard2 (нужен рут, если нет в настройках). По моему недостаточно гибкий способ, т.к. теперь уже внутренняя память лежит у нас мертвым грузом. Еще один недостаток этого способа — скорость работы системы.
  Если вы все же решитесь пойти этим путем, внизу я добавил как это можно сделать.
• создать символьную ссылку на внешние каталоги, как нам нужно, например
  ln -sf /mnt/externalSD/Books /sdcard/Books.
  Не работает, если файловая система не поддерживает симлинк (например fat).
• при загрузке андроида примонтировать внешние каталоги на внутреннюю память, используя что-то типа
  mount -o bind /mnt/externalSD/Books /sdcard/Books
  и добавить это в автозагрузку, например используя Autostart (root), чтобы это происходило автоматически при включении или после перезагрузки устройства.

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

Хочу обратить внимание хабрасообщества на возможную «уязвимость» в TCL, PostgreSQL и теоретически в некоторых других системах, использующих модули ругулярных выражений или NFA утилиты, изначально написаные самим Генри Спенсором (Henry Spencer). Измененных исходников можно найти добрую сотню (у того же Sun Microsystems, UUNET и т.д.). И хотя, я не думаю, что баг существует изначально с далеких 90-х, хотя бы потому, что кода где возникает эта ошибка я у Генри, в старых его источниках, не нашел, проверить ваши системы все-таки стоит.

И так ошибка: это busyloop на стадии компиляции регулярного выражения вида (((((x)*)*)*)*)*. Причем именно не исполнения, а компиляции, т.е. если есть проверка валидности регулярки и она базируется на том же коде NFA — имеем тот же безконечный цикл + 100% cpu usage.

Ошибку нашли коллеги по opensource проекту TCL, во всех его актуальных версиях (включая develop). Зная, что Postgres использует похожее API, нетрудно было выяснить, что скармливание этого регулярного выражения Postgres приводит к полному зависанию потока (процесса), отрабатывающего запрос.

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

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

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

На такую уловку попадаются даже люди, серьезно относящиеся к безопасности своих данных, например проверяющие URL в браузерах перед оплатой PayPal и т.д. Это объясняется высоким уровнем доверия к информации, висящей например внутри крупного банка.

От переводчика:

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

Дописывать в заголовке «Вопрос риторический — Ответа нет...» все таки не буду — думаю оно все же правильней, если свое мнение каждый составит или выскажет сам.
Для себя я частично ответил (жирно выделив ответ в Прим. переводчика в самом конце). Более полный ответ думаю сформулирует сообщество.



ENG. Android Updates: Why Is Cyanogen So Much Faster Than Google/OEMs?
GER. Android Updates: Warum ist Cyanogen so viel schneller als Google/OEMs?

---

Мой коллега Эрик был несколько лет активным членом на xda-developers и мог «вживую» видеть до чего отпадные, интересные и впечатляющие вещи разработчики там смогли поставить на ноги.

У него возникло два вопроса:
1. Почему Google и OEM-производители не нанимают xda разработчиков, чтобы быстрее выпускать андроид обновления;
2. Как удается Cyanogen'у быть настолько быстрее, чем Google и OEM, когда дело доходит до выпуска обновлений и оптимизации/улучшения Андроида?

Что такое CyanogenMOD?

Для тех кто не знает, кто такой Cyanogen — он изначально является крестным отцом Android, если речь заходит о пользовательских ПЗУ (custom ROMs) для Android. Соответственно CyanogenMOD — фундамент для custom ROMs. Steve Kondik (aka Cyanogen) и его команда создали основу для большинства других существующих Android ROMs. Не было бы Cyanogen, и сцена моддинга и рутинга выглядела бы определенно иначе.
Так например, команда позволила установить Ice Cream Sandwich на некоторые Android смартфоны, которые были названы компанией Google или OEM-производителями как несовместимые с последней версией мобильной операционной системы. И с многими предыдущими версиями дело обстояло точно так-же.

Кроме того Cyanogen удалось установить ICS на различные актуальные устройства за 4 месяца до первых изготовителей и операторов мобильной связи.
Огромное достижение то, чего уже добилась команда разработчиков и что она делает до сих пор.

Это осознал в какой-то момент и Samsung, т.к. Cyanogen был нанят в августе 2011 года, чтобы работать непосредственно на южнокорейскую компанию. CustomROMs — нечто гораздо большее, чем «просто» быстрые и нередко лучшие, чем выпущенные Google и OEM-производителями, прошивки, потому что они часто еженедельно обновляются и предлагают при этом много больше функций, которые никогда не были частью официальной продукции.

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

Мне по работе часто приходится сталкиваться с высоконагруженными многопоточными или многопроцессными сервисами (application-, web-, index-server).
Достаточно интересная, но иногда неблагодарная работа — оптимизировать все это хозяйство.
Растущие потребности клиентов часто упираются в невозможность просто заменить железную составляющую системы на более современную, т.к. производительность компьютеров, скорость чтения-записи жестких дисков и сети растут много медленнее запросов клиентов.
Редко помогает увеличение количества нодов кластера (система как правило распределенная).
Чаще приходится запустив профайлер, искать узкие места, лезть в source code и править ляпы, которые оставили коллеги, а иногда и сам, чего греха таить, много лет назад.
Некоторые из проблем, связаных с синхронизацией, я попытаюсь изложить здесь. Это не будет вводный курс по многопоточному программированию — предпологается, что читатель знаком с понятием thread и context switch, и знает для чего нужны mutex, semaphore и т.д.

Сразу скажу, что я не ломал этой программы, поэтому слово «хак» взято в кавычки далеко не случайно. Все получилось ..., а в прочем давайте по порядку.

Потеряв свой Android я был черезвычайно расстроен. Мало того что я корил себя за разгильдяйство — я не знал даже где и как это случилось (может его украли или выпал где) – мне нужно было купить (выбрать) новый, создать более-менее «рабочее окружение» на новом телефоне – рутовать его, поставить новую firmware, firewall, востанавливать все приложения и конфиги. А их у меня было немало.
Сам телефон было не жалко — он был уже старенький, был медлючь и тежеловесен (ЦПУ и память), хотя и не позволял чувствовать себя совсем ущербным с 7-м CyanogenMod и новым kernel. Его следовало уже давно выбросить и купить новый, но всякий раз, матерясь и грозясь заменить его при очередных тормозах, меня останавливала как раз потеря времени на установку и перенос всего, что было в старом смартфоне.