IA
логи, аудиты, итд тп
Size: a a a
2020 October 16
IA
какая-то закрытая очередь в яве (юзал такую лет 8 на 2х работах ) - это боль. люди хотят мониторить очередь, чистить очередь итд итп
IA
хотя она быстрее кафки и легче и интуитивней
IA
но в проде одна боль
MS
Igor A
есть vpn-ы которые не хранят логи. есть почты которые криптуют все. все есть. вы просто не с той планеты.
Да, все есть. Сноуден был настолько малой величиной, что пока он не вылез, его никто не рассматривал как объект. И вас тоже не будут рассматривать. Пока вы не станете настолько значимым, что вас будет возможно выгодно продать. И да, я наверное, если не с другой планеты, то какое-то время видел все это с другой стороны... Сорри.
A
Тоже не верю что есть vpn который не хранит логов. Или, даже если бы он был, как мы бы об этом узнали?
AD
так как ОС называлась? или что за профессор был?
речь скорее всего про Intel, Minix и профессора Таненбаума
IA
Mikhail Shambuev
Да, все есть. Сноуден был настолько малой величиной, что пока он не вылез, его никто не рассматривал как объект. И вас тоже не будут рассматривать. Пока вы не станете настолько значимым, что вас будет возможно выгодно продать. И да, я наверное, если не с другой планеты, то какое-то время видел все это с другой стороны... Сорри.
Вы не разбираетесь. "Мне нечего скрывать" называется.
Безопасность она всегда по модели швейцарского сыра.
Так можно и каско не покупать.
Безопасность она всегда по модели швейцарского сыра.
Так можно и каско не покупать.
p
Alex Demidov
речь скорее всего про Intel, Minix и профессора Таненбаума
Интересно, причем тут vt от intel
AZ
Вы же понимаете что эти ребята вне рамок кейса который введен? Даже виртуализацию в процессоре интела сделали на основе opensource низкоуровневой ОС от датского, что ли профессора, нарушив лицензию кстати. Я упоминал классический кровавый энтерпрайз. В котором вертится большая часть обычных сотрудников.
Даже виртуализацию сделали на основе ОС? Однако.
AZ
Вот вроде все слова правильные, только стоят не в том месте.
AZ
Аппаратная виртуализация в x86 - это если совсем упрощенно, появление минус первого кольца для работы гипервизора, чтобы не нужно было переписывать на лету код гостевой ОС, ожидающей, что она в нулевом.
То, о чем вы говорите - это минус второе кольцо, в котором работает "ультрагипервизор" от Intel. Но это следствие технологии виртуализации, а не ее реализация.
То, о чем вы говорите - это минус второе кольцо, в котором работает "ультрагипервизор" от Intel. Но это следствие технологии виртуализации, а не ее реализация.
AZ
Даже написал довольно объемную историческую статью по виртуализации в x86 - https://habr.com/ru/post/474776/
ОИ
Коллеги, мне хотелось бы задать вопрос следующего характера.
Дано:
- сервис, который предоставляет пользовательский интерфейс со своим фронтом и беком.
- шина и источник данных.
Требуется брать данные через шину в источнике данных, но поля запроса периодически меняются.
Какое можно выбрать решение, при котором требование изменения количества полей со стороны сервиса пользовательского интерфейса не приведёт к изменениям контракта шины?
PS: Вариант прокидывать тело запроса как SQL-запрос уже использовалось, но теперь появилась дополнительная логика и так сделать уже не прокатывает. Можно делать два запроса, но это тоже не выглядит круто. =)
Может кто сможет поделиться опытом?
Спасибо!
Дано:
- сервис, который предоставляет пользовательский интерфейс со своим фронтом и беком.
- шина и источник данных.
Требуется брать данные через шину в источнике данных, но поля запроса периодически меняются.
Какое можно выбрать решение, при котором требование изменения количества полей со стороны сервиса пользовательского интерфейса не приведёт к изменениям контракта шины?
PS: Вариант прокидывать тело запроса как SQL-запрос уже использовалось, но теперь появилась дополнительная логика и так сделать уже не прокатывает. Можно делать два запроса, но это тоже не выглядит круто. =)
Может кто сможет поделиться опытом?
Спасибо!
p
Alex Demidov
А, ME. Но нет, это не про виртуализацию.
p
DM
Коллеги, мне хотелось бы задать вопрос следующего характера.
Дано:
- сервис, который предоставляет пользовательский интерфейс со своим фронтом и беком.
- шина и источник данных.
Требуется брать данные через шину в источнике данных, но поля запроса периодически меняются.
Какое можно выбрать решение, при котором требование изменения количества полей со стороны сервиса пользовательского интерфейса не приведёт к изменениям контракта шины?
PS: Вариант прокидывать тело запроса как SQL-запрос уже использовалось, но теперь появилась дополнительная логика и так сделать уже не прокатывает. Можно делать два запроса, но это тоже не выглядит круто. =)
Может кто сможет поделиться опытом?
Спасибо!
Дано:
- сервис, который предоставляет пользовательский интерфейс со своим фронтом и беком.
- шина и источник данных.
Требуется брать данные через шину в источнике данных, но поля запроса периодически меняются.
Какое можно выбрать решение, при котором требование изменения количества полей со стороны сервиса пользовательского интерфейса не приведёт к изменениям контракта шины?
PS: Вариант прокидывать тело запроса как SQL-запрос уже использовалось, но теперь появилась дополнительная логика и так сделать уже не прокатывает. Можно делать два запроса, но это тоже не выглядит круто. =)
Может кто сможет поделиться опытом?
Спасибо!
Похоже, что шина реализует адаптер к источнику данных и при этом хочет жестко контролировать форматы, иначе у вас не было бы проблемы. А если так, то проблема неизбежна.
DM
если сделать отдельный адаптер к источнику данных и в относительно свободной форме зафиксировать формат запроса (хоть в виде key-value списка), то на шине изменений не будет, только на адаптере
ОИ
Denis Migulin
Похоже, что шина реализует адаптер к источнику данных и при этом хочет жестко контролировать форматы, иначе у вас не было бы проблемы. А если так, то проблема неизбежна.
В задаче нам не обязательно контролировать формат. Просто теперь вместо 1-го типа информации, появились два, которые не выходит воткнуть в один SQL-запрос.