была обнаружена копия дампа памяти в приложении разработчика софта. Там же нашли ключи доступа
вы таки будете смеяться, но мы тут снова про Security!
все дети знают, что существуют здесь зело Таинственные Хакеры, способные наизусть читать дамп памяти не менее пяти минут! им так сказала бабушка. а бабушка смотрела сериалы...
увы, но Самый Страшный Зверь - сферические дебилы в вакууме! бесхитростно копирущие на Прод экзамплы...
--
держу пари, что не было непостижимого Дампа Памяти. а был обычный баг репорт с environment variables ;)
вы таки знаете за AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, VAULT_TOKEN... ну вот и Хакеры Таинственные знают ;))
DersCrypt - это блочный симметричный криптографический алгоритм, построенный на не использовавшихся ранее принципах. Суть работы алгоритма состоит в переводе числа из одной системы счисления в другую, перестановке "цифр" и обратном переводе в исходную систему счисления.
Скажем, за $1000 - это было бы интересно студентам?
Ну, что-то типа выкладываем два файла: открытый текст и зашифрованный. А студент должен угадать ключ.
Нормально ли денег за два-три вечера, или нужно добавить?
Вот тут и приходят на помощь lock-free структуры данных, которые позволяют нам обрабатывать данные в многозадачной среде без необходимости блокировать потоки. В их основе лежат атомарные операции, такие как CAS.
боже, как все запущено...
а знает ли уважаемый автор, что "обычные синхронизации типа lock, Monitor или Mutex" используют под капотом те же самые "атомарные операции, такие как CAS"?
известно ли уважаемому автору ПОЧЕМУ "обычные синхронизации" после некоторой долбежки в цикле просят помощи планировщика ОС??
ну и совсем уже подлый вопрос: ПОНЯТНО ЛИ автору, почему CAS не имеет смысла на однопроцессорной арихитектуре?!
ЗЫ читайте David R. Butenhof, если и правда хотите понять. а если нет времени, то просто ЗАДУМАЙТЕСЬ над фразой "Multithreading is defined by an application design that ALLOWS FOR concurrent or simultaneous execution".
ЗЗЫ лично я лет 15 назад задумался, и мои примеры производительности C++ на 8 потоках работали в 321 раз быстрее!
еще раз для тех, кто не понял: в ТРИСТА ДВАДЦАТЬ ОДИН РАЗ.
как ни смешно, но это САМЫЙ ЭФФЕКТИВНЫЙ метод! Инженер сел за Задачу и полностью на ней сосредоточен. а любые сторонние прерывания лишь удлиняют сроки.
да, есть вариант, когда надо вмешаться чтобы прекратить выполнение (если задача утратила бизнес смысл). но вмешаться чтобы потом продолжить - это потеря Времени!
Называется предложение Харлана Миллза. Был такой математик
из статьи:
При некотором размышлении ясно, что эта идея приведет к желаемому, если ее удастся осуществить. Лишь несколько голов занято проектированием и разработкой, и в то же время много работников находится на подхвате. Будет ли такая организация работать? Кто играет роль анестезиологов и операционных сестер в группе программистов, а как осуществляется разделение труда?
а знает ли Уважаемая Общественность для чего нужен анестезиолог?
анестезиолог нужен не для того, чтобы пациент уснул. анестезиолог нужен, чтобы пациент проснулся!
"Предложение Харлана Миллза дает свежее и творческое решение. Миллз предложил, чтобы на каждом участке работы была команда разработчиков, организованная наподобие бригады хирургов, а не мясников.
Допустим, поток упал до 5 свистулек в час, Вы смотрите на доску, и видите, что например, на последнем этапе скопились свистульки(задачи), оказывается, что например, не вовремя поставляют гвоздики.
Потоки и лимиты ОБЯЗАТЕЛЬНО надо видеть! Иначе даже такая простая задача, как масштабирование серверов, будет НЕПРАВИЛЬНО сделана. А "масштабирование" людей - проблема гораздо сложнее!
Scrum и Kanban, стали основными инструментами для команд
Жаль, что люди забыли еще один метод: Бригада хирурга!
Где-то лежит у меня старая бумажная книга времен СССР. Перевод еще более старой книги, естественно.
Там, на заре компьютерной эры, очень неглупые люди пытались найти эффективные формы организации труда. И предложили взглянуть на хирургов:
Операцию выполняет хирург! А бригада ему помогает.
Высококвалифицированный хирург приходит к уже подготовленному пациенту. А низкоквалифицированные помощники готовят пациента, подают инструменты, держат края раны, зашивают что могут...
В результате чего самый квалифицированный специалист работает с МАКСИМАЛЬНОЙ ЭФФЕКТИВНОСТЬЮ, не отвлекаясь на ерунду.
нет, суть дела не в этом!
и дело не в Go, а во "всем бизнесе в целом". почему? потому, что
https://ders.by/arch/scale/scale.html
ну, вы же не думаете, что реальная цель "менеджера" - это жалеть программистов с инвесторами ;)
на триллионах кормится кто надо. все хорошо.
вы таки будете смеяться, но мы тут снова про Security!
все дети знают, что существуют здесь зело Таинственные Хакеры, способные наизусть читать дамп памяти не менее пяти минут! им так сказала бабушка. а бабушка смотрела сериалы...
увы, но Самый Страшный Зверь - сферические дебилы в вакууме! бесхитростно копирущие на Прод экзамплы...
--
держу пари, что не было непостижимого Дампа Памяти. а был обычный баг репорт с environment variables ;)
вы таки знаете за AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, VAULT_TOKEN... ну вот и Хакеры Таинственные знают ;))
На вакансию PM пришло три резюме:
Лучший Срам Мастер в Мире!
Лучший Кабан во Вселенной!
Лучший PM в этом городе...
А давайте лучше сломаем что-нибудь красивое современное: https://ders.by/crypt/derscrypt/derscrypt.html
Скажем, за $1000 - это было бы интересно студентам?
Ну, что-то типа выкладываем два файла: открытый текст и зашифрованный. А студент должен угадать ключ.
Нормально ли денег за два-три вечера, или нужно добавить?
разберитесь чем concurrency отличается от parallelism.
боже, как все запущено...
а знает ли уважаемый автор, что "обычные синхронизации типа lock, Monitor или Mutex" используют под капотом те же самые "атомарные операции, такие как CAS"?
известно ли уважаемому автору ПОЧЕМУ "обычные синхронизации" после некоторой долбежки в цикле просят помощи планировщика ОС??
ну и совсем уже подлый вопрос: ПОНЯТНО ЛИ автору, почему CAS не имеет смысла на однопроцессорной арихитектуре?!
ЗЫ читайте David R. Butenhof, если и правда хотите понять. а если нет времени, то просто ЗАДУМАЙТЕСЬ над фразой "Multithreading is defined by an application design that ALLOWS FOR concurrent or simultaneous execution".
ЗЗЫ лично я лет 15 назад задумался, и мои примеры производительности C++ на 8 потоках работали в 321 раз быстрее!
еще раз для тех, кто не понял: в ТРИСТА ДВАДЦАТЬ ОДИН РАЗ.
вот здесь статья: https://ders.by/cpp/mtprog/mtprog.html#3.1.1
И снова Security through obscurity...
МТС ничего не ответил по сути https://habr.com/en/companies/ru_mts/articles/861822/ . Давайте посмотрим, что скажет Сбер. Итак, вы пишете:
Прекрасно! Теперь вопрос: Используете ли вы секрет для доступа к самому ПровайдеруСекретов?
Если нет, то злоумышленник прочитает ПровайдерСекретов и получит секреты для ваших сервисов...
Если да, то вам нужен ПровайдерСекретов2, чтобы хранить секрет для ПровайдераСекретов...
Вы видите суть проблемы?
ЗЫ эта статья уже была сегодня размещена по адресу https://habr.com/en/companies/sberbank/articles/869932/ но быстро удалена. в чем причина?
немного не так :)
дурак - это структура мозга. она нам дана с рождения.
а неуч - да, он может прямо сейчас не знать "графического дизайна". но неуч способен потом разобраться. а дурак не способен.
как ни смешно, но это САМЫЙ ЭФФЕКТИВНЫЙ метод! Инженер сел за Задачу и полностью на ней сосредоточен. а любые сторонние прерывания лишь удлиняют сроки.
да, есть вариант, когда надо вмешаться чтобы прекратить выполнение (если задача утратила бизнес смысл). но вмешаться чтобы потом продолжить - это потеря Времени!
из статьи:
а знает ли Уважаемая Общественность для чего нужен анестезиолог?
анестезиолог нужен не для того, чтобы пациент уснул. анестезиолог нужен, чтобы пациент проснулся!
ЗЫ а усыпыпить могут даже в макдональдсе.
спасибо!
уже очень давно читал, забылись детали.
"Предложение Харлана Миллза дает свежее и творческое решение. Миллз предложил, чтобы на каждом участке работы была команда разработчиков, организованная наподобие бригады хирургов, а не мясников.
ну что тут ответишь...
хирург не пойдет мыть сортиры. а в операционную не пустят из толчка!
Ох, ребята...
Уже 150 лет на каждом серьезном Экономическом Форуме бушуют ЖАРКИЕ дискуссии на тему "Что же на самом деле сказал Маркс в своем Капитале"!
Скрам такое же фуфло.
О! Отличная кстати подводка для моей статьи Горизонтальное масштабирование https://ders.by/arch/scale/scale.html
Потоки и лимиты ОБЯЗАТЕЛЬНО надо видеть! Иначе даже такая простая задача, как масштабирование серверов, будет НЕПРАВИЛЬНО сделана. А "масштабирование" людей - проблема гораздо сложнее!
Жаль, что люди забыли еще один метод: Бригада хирурга!
Где-то лежит у меня старая бумажная книга времен СССР. Перевод еще более старой книги, естественно.
Там, на заре компьютерной эры, очень неглупые люди пытались найти эффективные формы организации труда. И предложили взглянуть на хирургов:
Операцию выполняет хирург! А бригада ему помогает.
Высококвалифицированный хирург приходит к уже подготовленному пациенту. А низкоквалифицированные помощники готовят пациента, подают инструменты, держат края раны, зашивают что могут...
В результате чего самый квалифицированный специалист работает с МАКСИМАЛЬНОЙ ЭФФЕКТИВНОСТЬЮ, не отвлекаясь на ерунду.
Создайте систему, которой сможет пользоваться дурак, и только дурак захочет ею пользоваться.
Основной закон Органической химии — Если взять килограмм г@вна и килограмм повидла, то получится два килограмма г@вна.
#legacycode
(dup)