была обнаружена копия дампа памяти в приложении разработчика софта. Там же нашли ключи доступа
вы таки будете смеяться, но мы тут снова про 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 секунд жестко встроены в Архитектуру. и возможность поднять их до 10 неизбежно означает, что что-то ухудшится в те же 2-4 раза.
кто-нибудь гуглил GitHub SLA?
получается смешно немного там (ц) Йода
лучше смотреть вызов t->commit(test07_wrt_cb, mp, test07_chk_cb, mp); в code\test_mem_db\main.cpp из https://ders.by/cpp/deque/code.zip
вы ж понимаете, что ко всему закроют доступ.
все согласно Концепции: это продвинутая хеш-таблица для тех, кому уже не хватает обычной. т.е. удобный и быстрый кэш, а не медленная БД.
ЗЫ и обратите внимание на колбэки check_cb и write_cb метода commit() -- это абсолютно уникальные возможности!
потому что у Go есть GC, а сборщик мусора в многопоточном приложении - это УБИЙЦА производительности!!!
многопоточность очень сложна, но оправдана при росте производительности.
а потом мы прикручиваем костыль, убивающий всю производительность...
за что боролись граждане??
держу пари, что вы это не знали:
by using GC, applications spend 7–82% more wall-clock time and 6–92% more CPU cycles relative to their intrinsic costs.
both Shenandoah and ZGC have worse (by factors of 10–100×) query latencies than the other three collectors!
здесь подробности https://www.linkedin.com/pulse/how-java-garbage-collection-works-sergey-derevyago-af84f
не бывает такой Роскоши, увы.
(в серьезных проектах)
bottleneck - это не оскорбление :) он есть всегда.
это как скорость эскадры определяется скоростью самого медленного корабля.
практика показывает, что в реальных проектах есть только один СЕРЬЕЗНЫЙ bottleneck. максимум два.
это другое :)
смотрите https://en.wikipedia.org/wiki/FoundationDB#Design_limitations
FoundationDB does not support transactions running over five seconds.
Transaction size cannot exceed 10 MB of total written keys and values.
Keys cannot exceed 10 kB in size. Values cannot exceed 100 kB in size.
пять секунд - это стыдно. и остальное тоже.
а, ну еще можно эффективно создавать Структуры данных второго порядка внутри ЛЮБОГО key-value store
https://ders.by/cpp/deque/deque.html
BTW если надо ОЧЕНЬ быстро и внутри процесса, то рекомендую Хеш-таблицу с транзакциями
https://ders.by/cpp/memdb/memdb.html
нет, суть дела не в этом!
и дело не в 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/ но быстро удалена. в чем причина?
немного не так :)
дурак - это структура мозга. она нам дана с рождения.
а неуч - да, он может прямо сейчас не знать "графического дизайна". но неуч способен потом разобраться. а дурак не способен.
как ни смешно, но это САМЫЙ ЭФФЕКТИВНЫЙ метод! Инженер сел за Задачу и полностью на ней сосредоточен. а любые сторонние прерывания лишь удлиняют сроки.
да, есть вариант, когда надо вмешаться чтобы прекратить выполнение (если задача утратила бизнес смысл). но вмешаться чтобы потом продолжить - это потеря Времени!