Но ведь разве не всегда так начинаются дежурства? Конкретные желания по автоматизации и упрощению жизни дежурного должны материализоваться в тикеты и таким образом процесс итеративно улучшается.
Если процесс не улучшать, то сам по себе он не улучшится.
Вот хоть убейте не пойму зачем там этот блокчейн, т.е. да понятно что это попытка связать все голоса одной цепочкой, чтобы нельзя было поменять что то посередине. Но братцы, как можно доверять черному ящику? Я доверяю блокчейн сетям, когда я могу подключить свой компьютер к этой сети и у меня будут те же данные, что и у всех и я также как и все буду проверять все транзакции и мы будем приходить к консенсус все вместе. Но когда у вас несколько узлов в одной централизованной p2p сети, то в чем смысл то?
PS я не блокчейн специалист, так что не отрицаю технические качества системы, но вот архитектурные явно вызывают вопросы, а они выше
Как я понял, речь идет о mitm атаке на собственное устройство, вы можете перехватить трафик с собственного (и не только) устройства с помощью прокси вроде Charles или Burp. И перехватывая шифрованный трафик (https) вы не увидите ни эндпоинтов куда он идет, ни самого тела запросов. Для того, чтобы перехватить шифрованный трафик можно подменить корневой сертификат на устройстве, после чего весь шифрованный трафик сможете просматривать. Но есть ssl pinning, который от этого и защищает.
То есть по сути это просто обертка, а не другой способ установки, вы можете и руками вызывать dpkg -i и получите тот же самый результат
По сути, то же самое и с командами просмотра состояния сети, все они читают из /proc и /sys и просто по-разному выводят информацию, никакой магии тут нет)
Надежность с точки зрения отсутствия больших температурных флуктуаций это да, а вот что делать когда у вас 1 из двух (два из трех и так далее) сетевых кабелей просто перестали работать? Что делать когда НОК случайно зароутил весь трафик внутрь самого подводного дц? Такие ситуации происходят, не сказать, что очень часто, но все же происходят. В классическом дц это решается звонком дежурному инженеру, а в подводных дц любая из подобных ошибок будет стоит очень много денег (помимо простоя). Ну и опять таки, говоря о подах речь идет только о stateless приложениях, их не больно терять, а вот шард большой бд потерять будет очень больно, даже несмотря на реплики/бекапы/оркестрацию.
Но ведь разве не всегда так начинаются дежурства? Конкретные желания по автоматизации и упрощению жизни дежурного должны материализоваться в тикеты и таким образом процесс итеративно улучшается.
Если процесс не улучшать, то сам по себе он не улучшится.
Вот хоть убейте не пойму зачем там этот блокчейн, т.е. да понятно что это попытка связать все голоса одной цепочкой, чтобы нельзя было поменять что то посередине. Но братцы, как можно доверять черному ящику? Я доверяю блокчейн сетям, когда я могу подключить свой компьютер к этой сети и у меня будут те же данные, что и у всех и я также как и все буду проверять все транзакции и мы будем приходить к консенсус все вместе. Но когда у вас несколько узлов в одной централизованной p2p сети, то в чем смысл то?
PS я не блокчейн специалист, так что не отрицаю технические качества системы, но вот архитектурные явно вызывают вопросы, а они выше
Как я понял, речь идет о mitm атаке на собственное устройство, вы можете перехватить трафик с собственного (и не только) устройства с помощью прокси вроде Charles или Burp. И перехватывая шифрованный трафик (https) вы не увидите ни эндпоинтов куда он идет, ни самого тела запросов. Для того, чтобы перехватить шифрованный трафик можно подменить корневой сертификат на устройстве, после чего весь шифрованный трафик сможете просматривать. Но есть ssl pinning, который от этого и защищает.
Кажется тут уж совсем не "операции оборота" должны были быть, скорее уж операции высвобождения или что то в таком духе.
Тут согласен, но не в данном случае.
Смотрите, вот взглянем что делаем gdebi:
https://github.com/linuxmint/gdebi/blob/bf5ff7eb94a0382961cd3be24d5786558aa0b05d/gdebi#L117 - Тут вызывается sys.exit(debi.install()), где debi - GDebiCli(options)
А в методе install класса GDebiCli лишь вызывается dpkg -i --auto-deconfigure https://github.com/linuxmint/gdebi/blob/bf5ff7eb94a0382961cd3be24d5786558aa0b05d/GDebi/GDebiCli.py#L147
То есть по сути это просто обертка, а не другой способ установки, вы можете и руками вызывать dpkg -i и получите тот же самый результат
По сути, то же самое и с командами просмотра состояния сети, все они читают из /proc и /sys и просто по-разному выводят информацию, никакой магии тут нет)
Странное решение, мне кажется все же нет никакого смысла в обертке над dpkg -i
А после 5 минут на общение алгоритмическая секция будет?
Соглашусь, kivy гораздо мощнее остальных «визуальных» библиотек, да и возможность создать мультиплатформенное приложение впечатляет.