Если, условно, час простоя для компании обходится в $10K денег, и облачный хостер готов это компенсировать в случае чего (а случаи бывают даже у Амазона) — ок, это того стоит.
Если же нет (в вашем случае — максимум 100% месячной стоимости) — то облако того не стоит и почти неотличимо от «самого дешевого хостинга» — в соответствии с вашими SLA вы не отвечаете ни за что (как и практически все остальные облачные провайдеры, впрочем).
Если же вы и пойдете на более адекватные условия SLA, это взвинтит цены настолько что
проще будет нанять своих админов на голое железо где подешевле.
Ну а теперь простой вопрос — зачем платить больше, если можно взять сервера на том же Hetzner и развернуть там своё облако за гораздо меньшие деньги (даже если придётся взять своих админов)? Hetzner, кстати, декларирует «всего» 99,9% доступности, хотя де-факто она на порядок выше.
Вы описали не "идею сортировки пузырьком", а "алгоритм сортировки пузырьком", который, кстати, легко патентуется по крайней мере в некоторых странах.
Идея в чистом виде с вашей аналогией — это «берем массив и переставляем элементы так чтобы на выходе получился отсортированный массив».
Кстати, почему «антигравитация» или даже «warp двигатель» это «фантазия»? Не более фантазия чем телевизор или фотоаппарат в 17 веке. С другой стороны, описать устройство для создания антигравитации с конкретным принципом работы, и запатентовать его — вполне даже можно, причём неважно, будет оно работать или нет (есть масса патентов на «вечный двигатель», если что).
Простите, не можете ли объяснить, каким образом содержание или количество данных влияют на надежность?
Мне казалось, что если алгоритм верен (и железо надёжно) — то неважно, сколько данных хранится — 1000 записей или миллиард, а судя по вашему комментарию получаются что это лотерея, и не факт что при 10 миллиардах записей ничего не «рассыпется».
Пока автоматика не настолько совершенна, а ложное чувство что она увидит всё приводит к более серьезным проблемам (автопилот теслы тому пример).
В частности, логику проекта и его архитектуру проверить автоматически невозможно, то есть — отсутствие сообщений анализатора не говорит о том что ошибок нет, так что рано списывать гуру и заботится о его времени.
Я считаю аналогию корректной по одной простой причине — несмотря на то что многие отбили себе пальцы, и не менее многие знают что можно отбить себе пальцы, всё же отбивание пальцев искоренить не удаётся (причём достаточно тех, кто делает это не один раз), но в то же время те кто свято соблюдает правила ТБ, ничего себе не отбивают — и прошу заметить, это не требует модификации молотков. А убить можно и случайно — если размахнуться молотком в момент когда кто-то стоит на траектории замаха.
К тому же, я уверен что молотками пользуется гораздо больше людей чем тех кто пользуется switch :)
Если этот гуру в единственном экземпляре — да. Если их несколько — то review кода уставшего/неспавшего гуру тем кто уже успел отдохнуть решает проблему, как правило. Главным условием является то что все гуру заняты одним проектом.
Руководствуясь приведённой логикой, не следует развивать Spelling & Grammar чекер в Microsoft Office, лучше учить детей в школе языку. Лучше? Лучше. И что дальше?
Я этого не говорил. Если применить вашу логику к данной аналогии — то нужно запретить Microsoft Office писать в документах слова с ошибками (ну или сохранять их) — а это уже зверство. Предупредить, направить — да, но последнее слово должно оставаться за автором.
Spelling / Grammar checker как раз нужны — ибо они помогают совершенствоваться.
Поэтому использование PVS-Studio это практический шаг по улучшению качества и надёжности кода.
Простите, но именно это я и сказал — если вы внимательно вчитаетесь :) Я просто против «внедрения» правил в сами языки (особенно если их нельзя обойти).
Зато этот инструмент нужен и полезен профессиональным разработчикам и компания может позволить им его купить.
Не все работают на компании, и не все зарабатывают кодом — но как раз именно они и «производят» больше всего ошибок.
Именно это и является большой проблемой, на мой взгляд — непрофессионалы пишут что-то полезное (и оно даже работает), но делают это «как умеют», т.е. с типичными проблемами, потом другие (уже включая профессионалов с небольшим опытом) копипастят их творения и множат проблемы. Иногда после разбора ответов на Stack Overflow волосы дыбом встают, но факт остается фактом — ответ который выполняет задачу принимается как «лучший», даже несмотря на наличие в нём потенциальных проблем, а дальше по спирали.
Но, поскольку эти самые непрофессионалы редко зарабатывают своим кодом, они вряд-ли подпишутся на такой тулз который стоит в общем-то, немало (даже весь комплект всего для разработчиков от JetBrains стоит дешевле, и он, кстати, включает в себя элементы статического анализа, а в Visual Studio это входит вообще даром — но не все могут им пользоваться).
Любой язык программирования и его возможности — это всего лишь инструмент. Его неправильное использование (сознательно или в силу отсутствия опыта или знаний) — проблема того кто использует, а не проблема языка.
Эдак можно дойти до утверждения в духе «молотки сделаны неправильно — ими можно ударить по пальцу или убить кого-нибудь».
Именно по этой причине в мире «железных» вещей существуют правила, инструкции и техника безопасности, а при необходимости — те, кто следит за их исполнением, и которые наказывают нарушителей.
Мне кажется более логичным не ограничивать языки, а совершенствовать тех, кто их испольузет — прямо (обучение + опыт) или косвенно (статический + динамический анализы).
PS: Если бы у средств типа PVS-Studio была более либеральная ценовая политика, вероятно, это сильно бы улучшило качество кода и уменьшило количество ошибок для массы программистов. Большинство разработчиков, особенно в open source, не могут себе позволить платить $60/мес, в то время как действительно опытные разработчики в таких средствах не нуждаются вовсе.
Если приватный ключ скомпрометирован, то никакие «независимые timestamp-сервисы» просто не помогут.
Вообще-то помогут — пока не скомпрометированы. Если добавить чуть-чуть деталей. Но это уже совсем другая история, заслуживающая отдельной статьи. За ссылку спасибо, но для меня это уже давно пройденный этап :)
Если приватный ключ источника скомпрометирован, то любые видео можно переподписать — то есть подделать. Блокчейн подделать сложнее, но есть более простой способ — включать в подписанное видео токены из независимого timestamp-service.
То есть, если нужна определенная гарантия что видео не будет скомпрометировано в будущем, нужно:
— независимый timestamp-service, который будет выдавать подписанный случайный токен на каждый новый стрим (начало трансляции);
— подписывать каждый кадр (дельту), включая как составляющий элемент хэша вышезапрошенный токен (ну и хэш предыдущего, конечно);
— по окончании стрима (или его прерывании) просить очередной токен и вставлять его в последний кадр.
Таким образом, мы получим стрим, который будет практически невозможно подделать даже если приватный ключ источника будет скомпрометирован. Разумеется, исходя из предположения что timestamp-service не может быть скомпрометирован, но это намного сложнее сделать (хотя в теории, конечно, возможно). Тут, правда, есть потенциал DoS — если timestamp-service будет недоступен — это как раз легко устроить, но дальнейшие меры снижают риски.
Можно пойти дальше и включать в каждый новый стрим подписанный хэш предыдущего (с одного источника), таким образом ещё больше усложняя задачу любителям переписывать историю.
Ну и наконец, вбиваем очередной гвоздь, обязывая всех стримеров публиковать подписанный хэш каждого завершенного стрима в нескольких печатных (да, бумажных) изданиях в текстовом виде + qr-code — всё, у дотошных журналистов и прочих детективов есть всё необходимое чтобы доказать подлинность (или наоборот) любого опубликованного стрима, и даже судам будет сложно сопротивляться — если, разумеется, они вообще признают цифровую подпись стрима.
PS: Это, разумеется, только общий обзор — дьяволов в деталях достаточно :)
Не будет с этим проблем — даже простые системы обеспечат тысячи подписей в секунду (а нужно обычно не больше 60), а скорость хеширования на уровне сотен мегабит (или гигабит на мощных системах или акселлераторах). Кодирование видео намного более затратная операция, так что подписывание будет почти незаметно.
The basic idea of our solution is to divide the stream into blocks and embed some authentication
information in the stream itself. The authentication information of the ith block will be used to authenticate
the (i + 1)st block. This way the signer needs to sign just the first block and then the properties of
this single signature will “propagate” to the rest of the stream through the authentication information
В Германии иначе. Ты не имеешь права сам починить что-нибудь, даже незначительное. Не имеешь права учить своих детей сверх программы — если он знает больше, то прямой путь в «нестандартную» школу.
Это неправда. Разумеется, вещи типа предустановленного или арендного оборудования (газовые колонки и пр.) самостоятельно ремонтировать нельзя, всё остальное — никаких запретов нет, и самодельчество в Германии очень популярно. Если, конечно, для себя — а не в качестве услуги — в случае услуг могут быть нужны разрешения и пр. Многие фирмы (по крайней мере, небольшие) очень ценят сотрудников которые способны делать больше чем то что ожидается от должности — к примеру, сисадмин умеющий паять (там, где это может пригодиться) — вполне даже востребовано и поощряется материально.
И детей можно учить чему угодно — пока это не затраивает саму школу и не сказывается на обучении, это никого не волнует, кто сколько знает (причём в обе стороны). Не исключаю, конечно, что есть школы в которых на это обращают внимание, но это явно не правило и уж тем более не регулируется законодательно.
Что мешает обрезать/отключить ethernet и заглушить GSM, особенно если речь про «удаленный объект»?
Если датчики работают «в пределах 868.0-868.6 мГц» — что мешает широкополосно глушить 865-870 MHz? Злоумышленники, в отличие от вас, не связаны регуляциями ни по мощности, ни по полосе. А если сделать это несколько раз, чтобы охранной фирме (и владельцу) надоели эти «уведомления»?
Глушилка может быть, кстати, удаленно управляемой и весьма хорошо замаскированной рядом с объектом — тут ничего кроме проводов не помогает, а потеря контакта с датчиком по проводу явный признак того что что-то не так, в отличие от беспроводного контакта.
Я не вижу противоречия — MonoDevelop просто не мог составить конкуренцию VS (даже в «чистом» виде) — если уж говорить честно, ну никак. Вопрос тогда — зачем поддерживать продукт который не имеет будущего, если есть возможность его существенно улучшить путём интеграции в существующий? Чисто практичное решение, и, говоря честно, он ещё до MS дышал на ладан.
А насчёт VS Community — он не «для студентов», лицензия прямо говорит: «If you are an individual working on your own applications to sell or for any other purpose, you may use the software to develop and test those applications.» — что ещё нужно для старта? Первые версии Community были очень урезаны, а последние — очень полноценные, более того (о ужас!) — они позволяют делать разработку под Linux (нет, не под WSL — обычный Linux, даже GDB поддерживается — и всё совершенно безвозмездно, т.е. даром). Использование VS Community для Open Source проектов вообще не ограничено.
Да, если речь про работу в организации или для выполнения работ по заказам — нужно покупать Pro или выше — но в этом случае оно оправдано и (честно говоря) недорого, не говоря уже о том что для сотрудников их покупают компании.
Если бы все прислушивались к его словам, то Linux & co. до сих пор были бы уделом маргиналов, а среди серверов царили бы коммерческие Windows, AIX, Slowlaris и иже с ними, вместо Postgres/Mysql были бы Oracle и Informix, ну и т.д.
Настоящий расцвет Open Source продукты получили именно после коммерциализации — чтобы он не говорил.
Забавный факт… когда «пришёл Микрософт», Xamarin IDE стал бесплатным — а до того у них была подписка (на бесплатный вариант были серьезные ограничения). И пусть его впоследствии интегрировали в VS — да и сам VS, в конце концов, стал бесплатным, и в приличном виде (а не то что было много лет назад) — даже для коммерческих проектов.
Что же касается MonoDevelop — то это было «жалкое подобие левой руки» — если сравнивать с VS, единственный реальный конкурент VS появился сравнительно недавно — это Rider (и прочие продукты от JetBrains).
Так что, пока что, наблюдая за всем этим, я вижу только Embrace & Extend — а вот Extinguish почему-то не наблюдается.
На самом деле, им и не нужно Extinguish — если первыми двумя они увеличивают проникновение, и, соответственно, прибыли.
Ну, чтобы «кто угодно» нужно ещё знать пароль для расшифровки ключа — просто ради интереса я импортировал его в gpg — и — как и ожидал — был спрошен на тему пароля.
Разумеется, это не делает инцидент менее значительным, но если всё же пароль достаточно сложный — то вряд-ли «кто угодно» будет в состоянии им воспользоваться.
Если, условно, час простоя для компании обходится в $10K денег, и облачный хостер готов это компенсировать в случае чего (а случаи бывают даже у Амазона) — ок, это того стоит.
Если же нет (в вашем случае — максимум 100% месячной стоимости) — то облако того не стоит и почти неотличимо от «самого дешевого хостинга» — в соответствии с вашими SLA вы не отвечаете ни за что (как и практически все остальные облачные провайдеры, впрочем).
Если же вы и пойдете на более адекватные условия SLA, это взвинтит цены настолько что
проще будет нанять своих админов на голое железо где подешевле.
Ну а теперь простой вопрос — зачем платить больше, если можно взять сервера на том же Hetzner и развернуть там своё облако за гораздо меньшие деньги (даже если придётся взять своих админов)? Hetzner, кстати, декларирует «всего» 99,9% доступности, хотя де-факто она на порядок выше.
Идея в чистом виде с вашей аналогией — это «берем массив и переставляем элементы так чтобы на выходе получился отсортированный массив».
Кстати, почему «антигравитация» или даже «warp двигатель» это «фантазия»? Не более фантазия чем телевизор или фотоаппарат в 17 веке. С другой стороны, описать устройство для создания антигравитации с конкретным принципом работы, и запатентовать его — вполне даже можно, причём неважно, будет оно работать или нет (есть масса патентов на «вечный двигатель», если что).
Мне казалось, что если алгоритм верен (и железо надёжно) — то неважно, сколько данных хранится — 1000 записей или миллиард, а судя по вашему комментарию получаются что это лотерея, и не факт что при 10 миллиардах записей ничего не «рассыпется».
В частности, логику проекта и его архитектуру проверить автоматически невозможно, то есть — отсутствие сообщений анализатора не говорит о том что ошибок нет, так что рано списывать гуру и заботится о его времени.
К тому же, я уверен что молотками пользуется гораздо больше людей чем тех кто пользуется switch :)
Я этого не говорил. Если применить вашу логику к данной аналогии — то нужно запретить Microsoft Office писать в документах слова с ошибками (ну или сохранять их) — а это уже зверство. Предупредить, направить — да, но последнее слово должно оставаться за автором.
Spelling / Grammar checker как раз нужны — ибо они помогают совершенствоваться.
Простите, но именно это я и сказал — если вы внимательно вчитаетесь :) Я просто против «внедрения» правил в сами языки (особенно если их нельзя обойти).
Не все работают на компании, и не все зарабатывают кодом — но как раз именно они и «производят» больше всего ошибок.
Именно это и является большой проблемой, на мой взгляд — непрофессионалы пишут что-то полезное (и оно даже работает), но делают это «как умеют», т.е. с типичными проблемами, потом другие (уже включая профессионалов с небольшим опытом) копипастят их творения и множат проблемы. Иногда после разбора ответов на Stack Overflow волосы дыбом встают, но факт остается фактом — ответ который выполняет задачу принимается как «лучший», даже несмотря на наличие в нём потенциальных проблем, а дальше по спирали.
Но, поскольку эти самые непрофессионалы редко зарабатывают своим кодом, они вряд-ли подпишутся на такой тулз который стоит в общем-то, немало (даже весь комплект всего для разработчиков от JetBrains стоит дешевле, и он, кстати, включает в себя элементы статического анализа, а в Visual Studio это входит вообще даром — но не все могут им пользоваться).
Эдак можно дойти до утверждения в духе «молотки сделаны неправильно — ими можно ударить по пальцу или убить кого-нибудь».
Именно по этой причине в мире «железных» вещей существуют правила, инструкции и техника безопасности, а при необходимости — те, кто следит за их исполнением, и которые наказывают нарушителей.
Мне кажется более логичным не ограничивать языки, а совершенствовать тех, кто их испольузет — прямо (обучение + опыт) или косвенно (статический + динамический анализы).
PS: Если бы у средств типа PVS-Studio была более либеральная ценовая политика, вероятно, это сильно бы улучшило качество кода и уменьшило количество ошибок для массы программистов. Большинство разработчиков, особенно в open source, не могут себе позволить платить $60/мес, в то время как действительно опытные разработчики в таких средствах не нуждаются вовсе.
Вообще-то помогут — пока не скомпрометированы. Если добавить чуть-чуть деталей. Но это уже совсем другая история, заслуживающая отдельной статьи. За ссылку спасибо, но для меня это уже давно пройденный этап :)
То есть, если нужна определенная гарантия что видео не будет скомпрометировано в будущем, нужно:
— независимый timestamp-service, который будет выдавать подписанный случайный токен на каждый новый стрим (начало трансляции);
— подписывать каждый кадр (дельту), включая как составляющий элемент хэша вышезапрошенный токен (ну и хэш предыдущего, конечно);
— по окончании стрима (или его прерывании) просить очередной токен и вставлять его в последний кадр.
Таким образом, мы получим стрим, который будет практически невозможно подделать даже если приватный ключ источника будет скомпрометирован. Разумеется, исходя из предположения что timestamp-service не может быть скомпрометирован, но это намного сложнее сделать (хотя в теории, конечно, возможно). Тут, правда, есть потенциал DoS — если timestamp-service будет недоступен — это как раз легко устроить, но дальнейшие меры снижают риски.
Можно пойти дальше и включать в каждый новый стрим подписанный хэш предыдущего (с одного источника), таким образом ещё больше усложняя задачу любителям переписывать историю.
Ну и наконец, вбиваем очередной гвоздь, обязывая всех стримеров публиковать подписанный хэш каждого завершенного стрима в нескольких печатных (да, бумажных) изданиях в текстовом виде + qr-code — всё, у дотошных журналистов и прочих детективов есть всё необходимое чтобы доказать подлинность (или наоборот) любого опубликованного стрима, и даже судам будет сложно сопротивляться — если, разумеется, они вообще признают цифровую подпись стрима.
PS: Это, разумеется, только общий обзор — дьяволов в деталях достаточно :)
Иллюстрация тут: ru.wikipedia.org/wiki/RSA#%D0%A6%D0%B8%D1%84%D1%80%D0%BE%D0%B2%D0%B0%D1%8F_%D0%BF%D0%BE%D0%B4%D0%BF%D0%B8%D1%81%D1%8C
В частности:
Это неправда. Разумеется, вещи типа предустановленного или арендного оборудования (газовые колонки и пр.) самостоятельно ремонтировать нельзя, всё остальное — никаких запретов нет, и самодельчество в Германии очень популярно. Если, конечно, для себя — а не в качестве услуги — в случае услуг могут быть нужны разрешения и пр. Многие фирмы (по крайней мере, небольшие) очень ценят сотрудников которые способны делать больше чем то что ожидается от должности — к примеру, сисадмин умеющий паять (там, где это может пригодиться) — вполне даже востребовано и поощряется материально.
И детей можно учить чему угодно — пока это не затраивает саму школу и не сказывается на обучении, это никого не волнует, кто сколько знает (причём в обе стороны). Не исключаю, конечно, что есть школы в которых на это обращают внимание, но это явно не правило и уж тем более не регулируется законодательно.
Если датчики работают «в пределах 868.0-868.6 мГц» — что мешает широкополосно глушить 865-870 MHz? Злоумышленники, в отличие от вас, не связаны регуляциями ни по мощности, ни по полосе. А если сделать это несколько раз, чтобы охранной фирме (и владельцу) надоели эти «уведомления»?
Глушилка может быть, кстати, удаленно управляемой и весьма хорошо замаскированной рядом с объектом — тут ничего кроме проводов не помогает, а потеря контакта с датчиком по проводу явный признак того что что-то не так, в отличие от беспроводного контакта.
А насчёт VS Community — он не «для студентов», лицензия прямо говорит: «If you are an individual working on your own applications to sell or for any other purpose, you may use the software to develop and test those applications.» — что ещё нужно для старта? Первые версии Community были очень урезаны, а последние — очень полноценные, более того (о ужас!) — они позволяют делать разработку под Linux (нет, не под WSL — обычный Linux, даже GDB поддерживается — и всё совершенно безвозмездно, т.е. даром). Использование VS Community для Open Source проектов вообще не ограничено.
Да, если речь про работу в организации или для выполнения работ по заказам — нужно покупать Pro или выше — но в этом случае оно оправдано и (честно говоря) недорого, не говоря уже о том что для сотрудников их покупают компании.
Настоящий расцвет Open Source продукты получили именно после коммерциализации — чтобы он не говорил.
Что же касается MonoDevelop — то это было «жалкое подобие левой руки» — если сравнивать с VS, единственный реальный конкурент VS появился сравнительно недавно — это Rider (и прочие продукты от JetBrains).
Так что, пока что, наблюдая за всем этим, я вижу только Embrace & Extend — а вот Extinguish почему-то не наблюдается.
На самом деле, им и не нужно Extinguish — если первыми двумя они увеличивают проникновение, и, соответственно, прибыли.
Разумеется, это не делает инцидент менее значительным, но если всё же пароль достаточно сложный — то вряд-ли «кто угодно» будет в состоянии им воспользоваться.