Я правильно понял из статьи, что используются механизмы pg_dump (по сути не предназначенный для РК) или, как альтернатива, копирование ФС? Несколько вопросов 1 - Почему не использовать хотя-бы pg_basebackup, изначально предназначенный для целей РК? 2 - При выполнении РК с файл-системы (очень надеюсь) используются pg_start_backup|pg_stop_backup?
3 - планируется ли использовать механизм реплики, наиболее оптимальный для РК тяжелых баз?
Привет Не упоминается покрытие тестами gRPC апи, а он у вас, насколько я знаю, также активно используется. Планируете расширять тесты на него, и если да - каким инструментарием?
И сканировать надо не с FuncTable, а с FuncTable+601*4
Ни один компилятор, знающий что допустмые значения «601-609», не станет строить таблицу вызовов с 600ю-стами пустыми указателями, он просто вычтет 600 из eax. и случай приводится к обычной таблице.
Кстати любой более-менее приличный декомпилятор умеет распознавать подобные таблицы и правильно строить схему вызовов.
При работе с важными данными (например тот-же онлайн банк), нужно иметь полезную привычку заглядывать в информацию о сертификате для https-сессии, перед тем как вводить пароли.
… глянул из любопытства:
в libwrap версия библиотеки skylib-winblue-x86-release_2014.06.19.137
в скайпе 6.20.0.104 — skylib-win-release_2014.07.17.1037
в 6.18.0.106 — skylib-win-release_2014.05.22.1547
так что можно считать, враппер более-менее свежий :)
но требует доработки напильником — для запуска хотя-бы на 7ке нескольких импортов ему не хватает.
Ну UI-ев неплохих пока хватает, типа тойж миранды или триллиана. На мой взгляд, для начала стоит не изобретать велосипед, а сделать к ним нормальные плагины, без монстра-скайпкита :)
Это вы глубоко заблуждаетесь :) Хоть бы прочитали внимательно то на что ссылаетесь…
у Ефима есть восстановленный код (т.е. результат реверс-инжениринга) очень небольшой части транспортного слоя скайпа. Никакого отношения к исходному коду оно не имеет, и судить о кривости кода по маленькому фрагменту отреверсенного — нонсенс. К тому-же в статье никаких выводов о «быдлокоде» нет, Ефим такого тоже не заявлял (я с ним регулярно общаюсь) — откуда тогда Ваш вывод?
Я правильно понял из статьи, что используются механизмы pg_dump (по сути не предназначенный для РК) или, как альтернатива, копирование ФС?
Несколько вопросов
1 - Почему не использовать хотя-бы pg_basebackup, изначально предназначенный для целей РК?
2 - При выполнении РК с файл-системы (очень надеюсь) используются pg_start_backup|pg_stop_backup?
3 - планируется ли использовать механизм реплики, наиболее оптимальный для РК тяжелых баз?
Привет
Не упоминается покрытие тестами gRPC апи, а он у вас, насколько я знаю, также активно используется. Планируете расширять тесты на него, и если да - каким инструментарием?
Ни один компилятор, знающий что допустмые значения «601-609», не станет строить таблицу вызовов с 600ю-стами пустыми указателями, он просто вычтет 600 из eax. и случай приводится к обычной таблице.
Кстати любой более-менее приличный декомпилятор умеет распознавать подобные таблицы и правильно строить схему вызовов.
в libwrap версия библиотеки skylib-winblue-x86-release_2014.06.19.137
в скайпе 6.20.0.104 — skylib-win-release_2014.07.17.1037
в 6.18.0.106 — skylib-win-release_2014.05.22.1547
так что можно считать, враппер более-менее свежий :)
но требует доработки напильником — для запуска хотя-бы на 7ке нескольких импортов ему не хватает.
у Ефима есть восстановленный код (т.е. результат реверс-инжениринга) очень небольшой части транспортного слоя скайпа. Никакого отношения к исходному коду оно не имеет, и судить о кривости кода по маленькому фрагменту отреверсенного — нонсенс. К тому-же в статье никаких выводов о «быдлокоде» нет, Ефим такого тоже не заявлял (я с ним регулярно общаюсь) — откуда тогда Ваш вывод?