Здравствуйте, kochetkov.vladimir, Вы писали:
k> AB>А у вас после посещения сотрудниками сортира образцы попадают сразу в хранилище или сначала проводится анализ на бак-посев? k> Не смешно. Если считаешь, что эта часть моей работы доставляет радость, то ты сильно ошибаешься сейчас.
Я не про тебя лично — ты человек подневольный. Я про организацию, где практикуется подобная паранойя.
k> А ковыряться зачастую приходится именно что в натуральном дерьме и ради чего? ... Вот скажи, если нерадивый сотрудник твоего сотового оператора сольет куда-нибудь твои ПДн или детализацию, ты, придя в их офис, будешь продолжать защищать права их сотрудников или таки-вспомнишь о своих?
Существует (условно) тысяча и один способ "слить" уже полученные данные — на этом поле вы всегда проигрываете. По этому я считаю слежку за приватными данными пользователя (а почта на mail.ru или сообщения ICQ — это приватные данные) необоснованным копанием в чужом белье и выражаю свое "фи" подобным методам.
Вне всякого сомнения, когда нарушат мою приватность, я приду в офис и буду качать права точно так же, как сейчас защищаю приватность ваших сотрудников.
k> И ты зря думаешь, что у вас в конторе данный процесс поставлен принципиально иначе
В нашей "конторе" этот процесс лишен практического смысла.
Здравствуйте, kochetkov.vladimir, Вы писали:
k> AB>P.P.S. На работе часто приходится анализировать логи под несколько гигабайт. Твой способ "через эксель" позабавил k> Тем не менее, он работает и замены не просит
а) Штатные утилиты работы с текстом (я про грепы) могут справиться куда быстрее. Как минимум, ими можно отфильтровать на начальном этапе потенциально интересующие данные, а не грузить портянку в десятки лямов строк сначала по сети, а потом в эксель.
б) Есть куда менее затратный способ импорта CSV в инструмент с большими возможностями по выборкам — BULK LOAD в БД. Так, например, MySQL просасывает 100MB файлик секунд за 5 и время почти линейно зависит от объема. Уверен, что MSSQL сделает это за сопоставимое время и уж точно не будет ругаться на количество строк. В конечном итоге, старый добрый Access так же может цеплять CSV и работать с ними как с таблицами (по крайней мере в 97 офисе умел).
k> AB>P.P.P.S. [troll mode on] Получается, ты наглядно продемонстрировал убогость винды и офиса [troll mode off] k> Тем не менее, вот он этот файл и вот оно 100% воспроизводимое падение. Ок, посыл понятен, дело видимо не в объемах, а в содержании. Попробую найти то место, на импорте которого он крэшится.
AB>Существует (условно) тысяча и один способ "слить" уже полученные данные — на этом поле вы всегда проигрываете. По этому я считаю слежку за приватными данными пользователя (а почта на mail.ru или сообщения ICQ — это приватные данные) необоснованным копанием в чужом белье и выражаю свое "фи" подобным методам.
Есть компромисс — автоматический анализ с уведомлением, если что-то подозрительное найдено — обижаться на такой способ — все равно, что обижаться на потоковый антивирус (кстати, эти звери чуть ли ни первые стали "дешифрацию" HPPTS практиковать).
Здравствуйте, Anton Batenev, Вы писали:
AB>(а почта на mail.ru или сообщения ICQ — это приватные данные)
А почту на mail.ru или сообщения ICQ у нас никто и не трогает, в логах отражен только факт отправки запроса, но не его содержимое
k>> И ты зря думаешь, что у вас в конторе данный процесс поставлен принципиально иначе AB>В нашей "конторе" этот процесс лишен практического смысла.
Здравствуйте, Sheridan, Вы писали:
S>Приветствую, neFormal, вы писали:
F>> S>А както мамут высказался, мне и понравилось. Очень хорошее слово. Явно нехорошее, но в то же время произнести трудновато. Следовательно произносится сие слово только когда ну совсем нехорошо.
F>> тебя линуксу тоже во дворе научили мальчики?.
S>Линуксу я научился сам. Вот этими вот руками... S>
волосатыми.....
Здравствуйте, kochetkov.vladimir, Вы писали:
k> AB>(а почта на mail.ru или сообщения ICQ — это приватные данные) k> А почту на mail.ru или сообщения ICQ у нас никто и не трогает, в логах отражен только факт отправки запроса, но не его содержимое
Тогда я не понимаю зачем на них смотреть — ну есть URI, время, размер, рефер в логе. Что это доказывает или опровергает?
k> AB>В нашей "конторе" этот процесс лишен практического смысла. k> А это ты не мне, а вот этому человеку будешь рассказывать: http://company.yandex.ru/job/vacancies/rukovod_ib.xml
Здравствуйте, DOOM, Вы писали:
DOO> Есть компромисс — автоматический анализ с уведомлением, если что-то подозрительное найдено — обижаться на такой способ — все равно, что обижаться на потоковый антивирус (кстати, эти звери чуть ли ни первые стали "дешифрацию" HPPTS практиковать).
Тут желательно конкретизировать слово "подозрительное". Потому как "дешифрация HTTPS" — это не автоматический анализ, а слежка, т.к. слово secure становится неуместным.
Правильный https не поломаете без закладки на машине пользователя, пазве только его работу можете нарушить. По крайней мере, если "у нас" — это не в АНБ или хотя бы сильно не рядовой отдел ФСБ, но тогда думаю об этом сюда никто не писал бы
Здравствуйте, DOOM, Вы писали:
M>>Правда, отмечу, что в Linux, всё-таки, можно настроить лимиты так, что прикладная программа не отожрет ресурсов, больше, чем администратор дал ей. DOO>Слышал я про одного аспиранта, который достаточно глубоко занимался тематикой планировщиков в ОС. Дак вот он, естественно, через какое-то время понял, что все они кривые и научился писать программы (естественно непривилегированные), которые выщелкивали почти все процессорное время на себя, что под виндой, что под линуксом. К слову, предложить идеальный планировщик, насколько я знаю, он тоже не смог...
То было давно. Уязвимость старого планировщика в Линуксе (и всех в Виндоусе) прекрасно известна — http://www.cs.huji.ac.il/~dants/papers/Cheat07Security.pdf
С версии 2.6.20 — Линукс для этой атаки неуязвим, так как там используется новый точный планировщик, который гарантированно правильно распределяет время между процессами.
Здравствуйте, Michael7, Вы писали:
K>>А у нас вот https ломают.
M>
M>Правильный https не поломаете без закладки на машине пользователя, пазве только его работу можете нарушить. По крайней мере, если "у нас" — это не в АНБ или хотя бы сильно не рядовой отдел ФСБ, но тогда думаю об этом сюда никто не писал бы
Заранее извиняюсь, если глупость скажу. А как же уязвимость, найденная Дэном Камински? Или это не из той оперы?
Здравствуйте, Michael7, Вы писали:
M>Правильный https не поломаете без закладки на машине пользователя, пазве только его работу можете нарушить. По крайней мере, если "у нас" — это не в АНБ или хотя бы сильно не рядовой отдел ФСБ, но тогда думаю об этом сюда никто не писал бы
Да поломаешь, поломаешь. Не забывай, что в корпоративной среде компьютеры пользователей "особые", например, они все доверяют корпоративному центу сертификации... Дальше понятно — прокси выдается сертификат подчиненного ЦС, прокси генерит нужный сертификат для каждого https соединения и терминирует соединение на себе — вот и все. Самый обыкновенный человек-по-середине.
Здравствуйте, Lazytech, Вы писали:
L>Заранее извиняюсь, если глупость скажу. А как же уязвимость, найденная Дэном Камински? Или это не из той оперы?
Ну как бы — зачем ломать DNS сервер, который ты и так контролируешь (речь же о корпоративной среде).
Ну а по поводу этой "уязвимости" — если я нашел таки правильное описание, то общей идее с TID'ами сто лет в обед, идея дополнительного RR — видимо более новая и она просто сделала более применимой давно известную атаку. Вот и все. Ну а журналюги, естественно, раздули все ух как...
KV>Итак, что имело место при работе с Excel?
KV>1) Он задал мне все вопросы, необходимые для импорта этого формата, до самого импорта, прочитав перед этим только первую строчку отчета с именами столбцов.
Это хорошо. KV>2) Во время импорта он не мешал мне работать, захватывая все доступные ему ресурсы компа.
А это следствие того что ОО нагрузил оба ядра, а МСО только одно. KV>3) Когда он не смог прогрузить весь файл, он не только сообщил об этом и исчерпывающе объяснил почему, но и оставил то, что смог прогрузить для дальнейшей работы.
Ну это конечно плюс.
ЗЫ. ОО не нравится ни разу, но по второму пункту он лучше МСО.
Здравствуйте, DOOM, Вы писали:
DOO>Чисто в целях позанудствовать: скормить наивному пользователю "специально сформированный" лог под гигабайт весом будет сложно
Учитывая, что родные форматы жмутся зипом — совсем нет.
Здравствуйте, ambel-vlad, Вы писали:
AV>2. MMC используется AppDomain. Сама работает в одном домене. А snap-in'ы грузит в другие сборки. Это сделано для того, чтобы вылет одного snap-in не выносила остальные.
(*)
AV> В одной сборке можно хранить несколько snap-in. Теперь попробуй угадать как будут загружаться эти несколько snap-in. Если в один msc-файл добавляется несколько snap-in разных типов, то будут ли они грузиться в один домен или в разные? Если в один msc-файл добавляется несколько snap-in одного типа, то будут ли они грузиться в один домен или в разные? Попробуй угадать, прежде чем читать дальше. Правильные ответы: 1 — разные домены, 2 — один. Интересно было бы увидеть обяснение в чем заключается различие в этих ситуациях.
Неверное предположение (*) и привело к непониманию. Домен никак не предохраняет ни от какого типа вылетов. Управляемые вылеты прекрасно отлавливаются и без него, а неуправляемым домены по барабану.
Домены нужны:
1) Для выгрузки сборок. Но для msc это не особо актуально
2) Для назначения отдельной политики CAS. Вот это, похоже, и было основной причиной использования доменов. И с этой точки зрения описанное тобой поведение выглядит вполне логично.
AV>3. Продолжим тему нескольких экземпляров snap-in одного типа. Никаких идентификаторов snap-in найти не удалось. То есть если мы где-то (например, в реестре) сохраним настройки каждого экземпляра. Как при загрузке snap-in разобраться где чьи настройки?
А есть ли вообще понятие такое — персистентный экземпляр снапина? В рамках ММС, разумеется, а не в твоем коде?
AV> А что будет если в системе окажется два продукта, которые имеют msc-файлы с одинаковым именем?
Поверь.
AV> Далее еще веселее. Что будет если мы снесем продукт, а потом поставим заново? Правильно, все старые данные подымутся. Что не есть правильно.
Это как сказать. Подавляющее большинство приложений ведет себя именно так.
Здравствуйте, Ночной Смотрящий, Вы писали:
AV>>2. MMC используется AppDomain. Сама работает в одном домене. А snap-in'ы грузит в другие сборки. Это сделано для того, чтобы вылет одного snap-in не выносила остальные.
НС>(*)
AV>> В одной сборке можно хранить несколько snap-in. Теперь попробуй угадать как будут загружаться эти несколько snap-in. Если в один msc-файл добавляется несколько snap-in разных типов, то будут ли они грузиться в один домен или в разные? Если в один msc-файл добавляется несколько snap-in одного типа, то будут ли они грузиться в один домен или в разные? Попробуй угадать, прежде чем читать дальше. Правильные ответы: 1 — разные домены, 2 — один. Интересно было бы увидеть обяснение в чем заключается различие в этих ситуациях.
НС>Неверное предположение (*) и привело к непониманию. Домен никак не предохраняет ни от какого типа вылетов. Управляемые вылеты прекрасно отлавливаются и без него, а неуправляемым домены по барабану. НС>Домены нужны:
Вообще-то это не предположение. От использования неуправляемого кода в snap-in планируют в будущем отказаться.
НС>1) Для выгрузки сборок. Но для msc это не особо актуально
Ну да. Snap-in выгружается только если его надо пришибить.
Кстати, тут есть еще одна веселуха. Нет возможности гарантировано перехватить необработанные исключения.
НС>2) Для назначения отдельной политики CAS. Вот это, похоже, и было основной причиной использования доменов. И с этой точки зрения описанное тобой поведение выглядит вполне логично.
Тогда вообще надо все snap-in грузить в отдельные домены. Что не наблюдается.
AV>>3. Продолжим тему нескольких экземпляров snap-in одного типа. Никаких идентификаторов snap-in найти не удалось. То есть если мы где-то (например, в реестре) сохраним настройки каждого экземпляра. Как при загрузке snap-in разобраться где чьи настройки?
НС>А есть ли вообще понятие такое — персистентный экземпляр снапина? В рамках ММС, разумеется, а не в твоем коде?
Если ты посмотрел бы далее, то увидел бы что да, в принципе, есть.
Кстати, есть еще такой интересный момент. До момента вызова функции загрузки сохраненных данных, snap-in никак не может узнать есть ли эти сохраненные данные. А эта функция не вызывается, если данных нет. В итоге получается вообще весело. При старте snap-in всегда вызывается OnInitialize и не всегда OnLoadCustomData. В результате из-за того что мы не знаем есть сохраненные данные или их нет, то в OnInitialize необходимо проводить дефолную инициализацию. Ну а если вызовется OnLoadCustomData, то зря мы что-то делали в OnInitialize. Все равно надо инициализацию проводить заново.
AV>> Далее еще веселее. Что будет если мы снесем продукт, а потом поставим заново? Правильно, все старые данные подымутся. Что не есть правильно.
НС>Это как сказать. Подавляющее большинство приложений ведет себя именно так.
Вот только это далеко не всегда правильно. А достаточно часто — это вообще неприемлимо. Так как же получить необходимое поведение?
Здравствуйте, ambel-vlad, Вы писали:
AV>Вообще-то это не предположение.
Неважно. Главное, что это неправда.
AV>Кстати, тут есть еще одна веселуха. Нет возможности гарантировано перехватить необработанные исключения.
AppDomain.UnhandledException?
AV>Тогда вообще надо все snap-in грузить в отдельные домены.
Если они однотипные, вряд ли им нужны разные политики.
НС>>Это как сказать. Подавляющее большинство приложений ведет себя именно так.
AV>Вот только это далеко не всегда правильно. А достаточно часто — это вообще неприемлимо. Так как же получить необходимое поведение?
Здравствуйте, Ночной Смотрящий, Вы писали:
AV>>Вообще-то это не предположение.
НС>Неважно. Главное, что это неправда.
Ну если не верить разработчикам, то я не знаю кому уж и верить. Потому что именно устойчивость у них была первой. А CAS — где-то 3-4 аргументом.
AV>>Кстати, тут есть еще одна веселуха. Нет возможности гарантировано перехватить необработанные исключения.
НС>AppDomain.UnhandledException?
Полагаешь, что про это забыли? Можешь подписать на AppDomain.UnhandledException. Вот только от этого практически 0. Потому что до твоего обработчика дело даже не дойдет. Твой snap-in прихлопнут гораздо раньше. Можешь еще подписаться на Application.ThreadException. С точно таким же результатом.
Кстати, как mmc обрабатывает необработанные исключения тоже весело. Оно обрабатывает их в своем домене. А не в домене, где работает snap-in. В результате, если ты не словил свое кастомное исключение, то консоль покажет совсем не ту ошибку. А покажет сообщение о SerializationException. Типа не может десериализовать наше исключение. Еще бы. Конечно не может. Да и стектрейсы, которые mmc показывает тоже не имеют ничего общего с стектрейсом исключения. Даже когда используется стандартное исключение.
AV>>Тогда вообще надо все snap-in грузить в отдельные домены.
НС>Если они однотипные, вряд ли им нужны разные политики.
Видишь ли, такое вполне может быть. Когда один snap-in вынужден делать две разные задачи. Причем у нас небольшое время был именно такой переходный вариант. От которого правда быстро отказались.
НС>>>Это как сказать. Подавляющее большинство приложений ведет себя именно так.
AV>>Вот только это далеко не всегда правильно. А достаточно часто — это вообще неприемлимо. Так как же получить необходимое поведение?
НС>Думаю, написать на connect.microsoft.com
А как же уязвимость, найденная Дэном Камински? Или это не из той оперы? 
