У-ф-ф… Напугали… А я думал уже, что кирдык всей ФС, причем неремонтируемый даже при загрузке с диска MS DaRT. И Hard Reset не в помощь…
Но все равно, если есть возможность внедрить это обращение в html любого сайта, то удовольствия мало. Особенно для терминальных серверов. Особенно работающих с локальными файл-серверными БД.
На SQL-сервере общих ресурсов нет кроме системных: ADMIN$, IPC$, C$ и т.д. Администратор домена может к ним подключиться.
На сервере геоинформационной системы есть расшаренные папки. Чтобы админ ГИС мог заливать привязанные к объектам фото, схемы, пятисотки. С XP с правами этого админа в них заходит.
На сервере терминалов (про который сканер говорит, что он безопасен) тоже есть шары — на локальные файловые БД. С правами соответствующих админов на них с XP заходит.
Т.е., заходит с XP на все расшаренные ресурсы, но один сервер помечается сканером как безопасный, а второй — как с неопределяемой уязвимостью.
Но это не единственные сервера с Win2K12 R2. Про другие сканер, тем не менее пишет не такую строчку, а вполне обычную:
[-] 192.168.xxx.yyy (Windows Server 2012 R2 Standard 9600) stays in safety
Ну это после установки всех последних обновлений. Как было до этого — не знаю. Потому что сразу при начале эпидемии кинулся устанавливать их и перегружать сервера.
Спасибо за сканер — оч-ч-чень полезное изобретение… За полдня обежал всю контору и еще по RAdmin кучу компов обновил. Где XP стояла (автоматом она не не находит обновлений — только вручную устанавливать), где обновления по каким-то причинам глючили, где доступ в Инет был заблочен, но время от времени обновления хоть вручную ставить надо. Без сканера наверняка бы много пропустил.
Только вот на двух серверах тоже выдает такую строчку:
can't determine whether 192.168.xxx.yyy is vulnerable or not
На одном файерволл включен, на другом — нет. На одном MS SQL сервер, на другом сервер геоинформационной системы. Общее — Win2K12 Server R2 Standard Edition. Но эта ОСь есть и на других машинах, как и включенные файерволлы.
1. БД персоналий создавалась полуавтоматически на основании списка актеров/режиссеров и прочих действующих лиц к фильму. Этот список представлял собой обычную текстовую строку, разделенную запятыми.
При добавлении фильма строка парсилась скриптом. Если имя уже присутствовало в БД, то создавалась связь между страничкой фильма и страничкой персоны. Если имени в БД еще не было, то страничка персоны (пустая) сначала создавалась.
Если имя в строке-списке было написано с ошибкой, то под него создавалась новая страница. Если ошибка была вовремя обнаружена и исправлена, то связь пересоздавалась, но ошибочная страница оставалась.
Если же ошибка не была исправлена, то получалось у одной персоны несколько страниц с разным написанием имени и с разным набором фильмов.
2. Дата рождения/смерти, место рождения и другие данные заполнялись теми же энтузиастами по мере возможностей и желания. Если страниц одного актера было несколько, то на одной могли быть эти данные, а на другой — биография и т.д. Причем, заполненных страниц было гораздо меньше, чем незаполненных.
3. Однофамильцы, действительно, есть. И достаточно много. Так что еще стояла задача их поиска и разделения их на разные страницы. Но это немного другая задача. Автоматически она не решается — только ручным анализом фильмографий и сравнением с другими БД, например с IMDb.
Только вот дело в том, что пока однофамильцы не разделены, у них всего одна страничка на всех. А если разделены, то каждому присвоен уникальный номер, например «Дэвид Прайс (II)». Поэтому их не могло быть «много» по определению. Либо на всех одна страница, либо их имена различаются уникальным номером.
А вот разных страниц одной персоны могло быть 2-3, а то и 4. Например, могло быть 4 страницы с такими именами:
Так Сакагути
Так Сакагучи
Сакагучи Так
Сакагути Так
А правильное из этого списка — только одно.
Вот и стояла задача обнаружить все имена, подозрительно схожие между собой. Чтобы провести ручной анализ их схожести, исправить и удалить лишние.
Во-первых, БД «худела», избавляясь от мусора. Поиск выдавал одну страницу, а не несколько, отличающихся только разным порядком слов.
Во-вторых, из нее удалялись имена с ошибочным написанием.
В-третьих, такие страницы объединялись — объединялись фильмографии.
Так что, практический смысл был вполне определенный.
Во всяком случае, среди найденных пар с релевантностью 1.0 было более 80% страниц двойников с разным порядком слов или с разными знаками препинания. Например, в одном прозвище написано в простых кавычках, а в другом — в двойных. Остальные принадлежали разделенным тезкам/однофамильцам.
Среди пар с меньшей релевантностью тезок не будет совсем, но будет достаточно много просто схожих имен разных персон. Вот поэтому и нужен ручной анализ, чтобы определить, что «Трейси Кэй» и «Трэйси Кэй Вульф» — это одна и та же актриса. Просто в разных фильмах она по разному в титрах указана. А так же в некоторых фигурировала под именем «Трэйси Вульф», но ничего общего с актрисой Трэйси Вульф, которая играла дочь чернокожего напарника в «Смертельном оружии» не имеет.
Согласен с Analitik_Telecom в плане того, что не в длине заголовка счастье…
Заголовок, список хабов и анонс статьи (то, что до ката) — это основные средства привлечь внимание целевой аудитории.
И если автор статьи относится к этим средствам вдумчиво и серьезно, то он сумеет так распределить между ними нужную информацию, что каждая из этих частей будет достаточно лаконична, но информативна. А такой подход уже сам по себе будет привлекать читателя, а не только количество букв в них.
Что касается фрагментов кода в длинных статьях, то тут ситуация противоречивая:
С одной стороны, если автор делится кодом, значит он считает, что тема настолько интересна, что код может пригодиться кому-то еще. И зачастую, это именно так и обстоит. Т.е. это не длина вызывает интерес, а оправданный расчет на заинтересованность заставляет внедрять в статью код.
С другой стороны, аккуратные авторы длинный код прячут в спойлеры. И более показательно было бы провести оценку интереса в зависимости от длины текста без спрятанных фрагментов.
Мне кажется, что этот показатель был бы более адекватным текущей ситуации.
Ну так всё о том же я: Прежде чем спорить о русском написании следует обнаружить предмет спора. Т.е. различные варианты написания. А с этим анализатор худо-бедно справился.
Кстати, обратите внимание в результатах работы есть «Ричард Рихль» и «Ричард Нихль». А еще там в этой БД есть (в пример не вошли) «Ричард Риле» и «Ричард Рили». И все это — один и тот же человек! Но правильное написание — только «Рили» :)…
P.S. Все возможные пары этого имени были анализатором обнаружены с высокой степенью релевантности.
Ага! Все-таки Devereaux, а не Deveraux, как на КП написано!
Ну что ж… Я встречал еще и «Деверё» :)
Так что, от моего изобретения большая польза :D И оно не только дырку в стене закрывает.
Во всяком случае, думаю, если бы все эти написания присутствовали в этой БД, то анализатор нашел бы все пары сходных. А дальше пусть франко-бельгийцы голову ломают — как там по русски правильно писать.
Кстати, была еще идея сделать кластерный анализ по результатам его работы. Чтобы выдавал не разрозненные пары, а некие конгломераты сходных имен. Так, чтобы на концах списка находились самые отличающиеся, а в середине — максимально похожие на все остальные.
Ну так я же и писал, что французский я ни разу не знаю.
Во всяком случае, спасибо за это сообщение. Оно является прекрасной иллюстрацией написанному мной насчет перевода «на глаз, а не на слух».
В Интернете в блогах и всяких ЖЖ я встречал именно Деверю, и я думаю, что писали это люди в отличие от меня разбирающиеся во французском языке. В Вике, в статье про фильм — Деверо. Но фильм снимали как раз американоязычные кинодеятели. Они могли и ошибиться. А Вы пишете, что правильно — Девро.
Т.е. это имя уже могло быть написано, минимум, в трех вариантах.
Смысл как раз в том, чтобы найти сходные по написанию имена, а разбираться, принадлежат ли они одному персоналию или разным, и как звучит по-русски правильно — это уже совсем другая задача.
Напишите, пожалуйста, что именно Вас интересует. Постараюсь дополнить или описать отдельным постом.
В принципе, основа описана в тексте, а фрагменты кода достаточно подробно комментированы. Отсутствуют некоторые фрагменты кода, т.к. они были заточены под конкретную реализацию исходного сайта и БД.
Т.е. повторюсь, основные идеи следующие:
1. Используется N-граммный анализ.
2. Для упрощения анализа имена нормализуются (см. в тексте).
3. Для начальной выборки используется 5-граммный индекс, вернее, его целочисленный хеш.
4. Внутри полученной выборки производится 3-граммный анализ по уникальным 3-граммам.
5. Перед началом вычисления релевантности определяется максимально допустимое число «промахов». При его превышении выисление релевантности прекращается без уточнения.
6. Дополнительно в начальной выборке можно указывать диапазон числа уникальных триграмм, т.к. существует их максимальное соотношение в сравниваемых именах, при превышении которого релевантность будет заведомо ниже заданной границы.
Остальное можно посмотреть в коде и комментариях к нему.
Если что будет непонятно — спрашивайте. Буду рад ответить.
Что за группа «йо»? Тем более, что и «й» и «о» уже входят в другие группы.
https://www.theverge.com/2017/5/26/15696704/microsoft-windows-7-windows-8-pc-crash-bug-ntfs
На 4PDA есть перевод:
http://4pda.ru/2017/05/29/342735/
Но все равно, если есть возможность внедрить это обращение в html любого сайта, то удовольствия мало. Особенно для терминальных серверов. Особенно работающих с локальными файл-серверными БД.
"… если выполнить перезагрузку, то система повиснет на ней".
Т.е. после таких экспериментов система перестает загружаться от слова «совсем»?
Чем в таком случае лечить? Диагностика ФС из набора MS DaRT помогает? Или какие сторонние средства?
На сервере геоинформационной системы есть расшаренные папки. Чтобы админ ГИС мог заливать привязанные к объектам фото, схемы, пятисотки. С XP с правами этого админа в них заходит.
На сервере терминалов (про который сканер говорит, что он безопасен) тоже есть шары — на локальные файловые БД. С правами соответствующих админов на них с XP заходит.
Т.е., заходит с XP на все расшаренные ресурсы, но один сервер помечается сканером как безопасный, а второй — как с неопределяемой уязвимостью.
[-] 192.168.xxx.yyy (Windows Server 2012 R2 Standard 9600) stays in safety
Ну это после установки всех последних обновлений. Как было до этого — не знаю. Потому что сразу при начале эпидемии кинулся устанавливать их и перегружать сервера.
P.S. Файерволл на них включен. В чем разница?
Только вот на двух серверах тоже выдает такую строчку:
can't determine whether 192.168.xxx.yyy is vulnerable or not
На одном файерволл включен, на другом — нет. На одном MS SQL сервер, на другом сервер геоинформационной системы. Общее — Win2K12 Server R2 Standard Edition. Но эта ОСь есть и на других машинах, как и включенные файерволлы.
Вобщем, чем они такие особенные — не понятно.
1. БД персоналий создавалась полуавтоматически на основании списка актеров/режиссеров и прочих действующих лиц к фильму. Этот список представлял собой обычную текстовую строку, разделенную запятыми.
При добавлении фильма строка парсилась скриптом. Если имя уже присутствовало в БД, то создавалась связь между страничкой фильма и страничкой персоны. Если имени в БД еще не было, то страничка персоны (пустая) сначала создавалась.
Если имя в строке-списке было написано с ошибкой, то под него создавалась новая страница. Если ошибка была вовремя обнаружена и исправлена, то связь пересоздавалась, но ошибочная страница оставалась.
Если же ошибка не была исправлена, то получалось у одной персоны несколько страниц с разным написанием имени и с разным набором фильмов.
2. Дата рождения/смерти, место рождения и другие данные заполнялись теми же энтузиастами по мере возможностей и желания. Если страниц одного актера было несколько, то на одной могли быть эти данные, а на другой — биография и т.д. Причем, заполненных страниц было гораздо меньше, чем незаполненных.
3. Однофамильцы, действительно, есть. И достаточно много. Так что еще стояла задача их поиска и разделения их на разные страницы. Но это немного другая задача. Автоматически она не решается — только ручным анализом фильмографий и сравнением с другими БД, например с IMDb.
Только вот дело в том, что пока однофамильцы не разделены, у них всего одна страничка на всех. А если разделены, то каждому присвоен уникальный номер, например «Дэвид Прайс (II)». Поэтому их не могло быть «много» по определению. Либо на всех одна страница, либо их имена различаются уникальным номером.
А вот разных страниц одной персоны могло быть 2-3, а то и 4. Например, могло быть 4 страницы с такими именами:
А правильное из этого списка — только одно.
Вот и стояла задача обнаружить все имена, подозрительно схожие между собой. Чтобы провести ручной анализ их схожести, исправить и удалить лишние.
Во-первых, БД «худела», избавляясь от мусора. Поиск выдавал одну страницу, а не несколько, отличающихся только разным порядком слов.
Во-вторых, из нее удалялись имена с ошибочным написанием.
В-третьих, такие страницы объединялись — объединялись фильмографии.
Так что, практический смысл был вполне определенный.
Во всяком случае, среди найденных пар с релевантностью 1.0 было более 80% страниц двойников с разным порядком слов или с разными знаками препинания. Например, в одном прозвище написано в простых кавычках, а в другом — в двойных. Остальные принадлежали разделенным тезкам/однофамильцам.
Среди пар с меньшей релевантностью тезок не будет совсем, но будет достаточно много просто схожих имен разных персон. Вот поэтому и нужен ручной анализ, чтобы определить, что «Трейси Кэй» и «Трэйси Кэй Вульф» — это одна и та же актриса. Просто в разных фильмах она по разному в титрах указана. А так же в некоторых фигурировала под именем «Трэйси Вульф», но ничего общего с актрисой Трэйси Вульф, которая играла дочь чернокожего напарника в «Смертельном оружии» не имеет.
Заголовок, список хабов и анонс статьи (то, что до ката) — это основные средства привлечь внимание целевой аудитории.
И если автор статьи относится к этим средствам вдумчиво и серьезно, то он сумеет так распределить между ними нужную информацию, что каждая из этих частей будет достаточно лаконична, но информативна. А такой подход уже сам по себе будет привлекать читателя, а не только количество букв в них.
Что касается фрагментов кода в длинных статьях, то тут ситуация противоречивая:
С одной стороны, если автор делится кодом, значит он считает, что тема настолько интересна, что код может пригодиться кому-то еще. И зачастую, это именно так и обстоит. Т.е. это не длина вызывает интерес, а оправданный расчет на заинтересованность заставляет внедрять в статью код.
С другой стороны, аккуратные авторы длинный код прячут в спойлеры. И более показательно было бы провести оценку интереса в зависимости от длины текста без спрятанных фрагментов.
Мне кажется, что этот показатель был бы более адекватным текущей ситуации.
Ну так всё о том же я: Прежде чем спорить о русском написании следует обнаружить предмет спора. Т.е. различные варианты написания. А с этим анализатор худо-бедно справился.
Кстати, обратите внимание в результатах работы есть «Ричард Рихль» и «Ричард Нихль». А еще там в этой БД есть (в пример не вошли) «Ричард Риле» и «Ричард Рили». И все это — один и тот же человек! Но правильное написание — только «Рили» :)…
P.S. Все возможные пары этого имени были анализатором обнаружены с высокой степенью релевантности.
Ну что ж… Я встречал еще и «Деверё» :)
Так что, от моего изобретения большая польза :D И оно не только дырку в стене закрывает.
Во всяком случае, думаю, если бы все эти написания присутствовали в этой БД, то анализатор нашел бы все пары сходных. А дальше пусть франко-бельгийцы голову ломают — как там по русски правильно писать.
Кстати, была еще идея сделать кластерный анализ по результатам его работы. Чтобы выдавал не разрозненные пары, а некие конгломераты сходных имен. Так, чтобы на концах списка находились самые отличающиеся, а в середине — максимально похожие на все остальные.
Но не задалось. Заказчик потерял интерес.
Надо обратиться к первоисточнику. Запущу дома DOSBox и WC первый под ним. И посмотрю, что там пишут.
Во всяком случае, спасибо за это сообщение. Оно является прекрасной иллюстрацией написанному мной насчет перевода «на глаз, а не на слух».
В Интернете в блогах и всяких ЖЖ я встречал именно Деверю, и я думаю, что писали это люди в отличие от меня разбирающиеся во французском языке. В Вике, в статье про фильм — Деверо. Но фильм снимали как раз американоязычные кинодеятели. Они могли и ошибиться. А Вы пишете, что правильно — Девро.
Т.е. это имя уже могло быть написано, минимум, в трех вариантах.
Смысл как раз в том, чтобы найти сходные по написанию имена, а разбираться, принадлежат ли они одному персоналию или разным, и как звучит по-русски правильно — это уже совсем другая задача.
В принципе, основа описана в тексте, а фрагменты кода достаточно подробно комментированы. Отсутствуют некоторые фрагменты кода, т.к. они были заточены под конкретную реализацию исходного сайта и БД.
Т.е. повторюсь, основные идеи следующие:
1. Используется N-граммный анализ.
2. Для упрощения анализа имена нормализуются (см. в тексте).
3. Для начальной выборки используется 5-граммный индекс, вернее, его целочисленный хеш.
4. Внутри полученной выборки производится 3-граммный анализ по уникальным 3-граммам.
5. Перед началом вычисления релевантности определяется максимально допустимое число «промахов». При его превышении выисление релевантности прекращается без уточнения.
6. Дополнительно в начальной выборке можно указывать диапазон числа уникальных триграмм, т.к. существует их максимальное соотношение в сравниваемых именах, при превышении которого релевантность будет заведомо ниже заданной границы.
Остальное можно посмотреть в коде и комментариях к нему.
Если что будет непонятно — спрашивайте. Буду рад ответить.