Я что-то не встречал в SLA облачных провайдеров RPO и RTO — в конце концов, это сильно зависит от конкретного приложения, просто восстановление железа (виртуального или реального) или бэкапа не обязательно ведет к восстановлению сервиса, это в 99% случаев ЗО клиента.
В случае DS, есть SLA на RTO по железу, остальное уже ЗО клиента.
К сожалению, в случае виртуалки всё намного печальней — host имеет полный доступ к памяти guest в любое время, совершенно необнаруживаемый, не говоря уже о возможности трейсинга.
Соответственно, имея доступ к памяти, можно легко получить все ключи шифрования, или, как пример, все сертификаты с приватными ключами — благо структуры данных в памяти известны.
В случае DS для этого придётся как минимум его отключить и загрузится со своей recovery system, но это невозможно сделать незаметно, да и просто любопытный это вряд ли сделает.
Не должно — но об этом-то и речь — ответственность провайдера в случае облака и DS практически одинакова, SLA такое же, только первое стоит дороже (даже с учетом 2-3х-кратного резервирования) чем второе (при эквивалентных параметрах).
Пока это выглядит так, что вы рекомендуете мне платить примерно столько же, но за сервер который даст мне только 10% от того что у меня уже есть, а если мне потребуется больше на какое-то время, придётся совершать лишние телодвижения (как минимум перезагрузку инстанса в случае изменения конфигурации) и платить больше (пусть и временно).
Проблема в том что потребности в ресурсах не всегда предсказуемы — я не знаю когда и насколько мне понадобятся все 64GB с 4 CPU (хотя всё же чуть больше чем 4, если учесть HT), зато я точно знаю что мне в обозримом будущем не потребуется больше, т.е. если вдруг это таки будет месяц 100% загрузки — всё, я попал на годовую стоимость DS всего за месяц. OK, если это нужно клиенту — не совсем попал — клиент заплатит, конечно, но не всегда это нужно только клиенту, да и драть втридорога с клиентов тоже не хочется.
Если вдруг мой клиент решит что ему нужен инстанс у меня на какое-то время (или нужен буден инстанс для выполнения работы на длительное время — так бывает), я смогу это сделать не заплатив лишнего цента провайдеру и не урезая своих ресурсов.
Некоторые из крутящихся приложений расчитаны на то что в любой момент (при запросе извне) они получат всю мощь, а не будут урезаны текущим инстансом и его ресурсами, т.е. вдруг нужно 50G RAM (без свопа!) на несколько секунд-минут, и так с периодичностью в час-два — как вы догадываетесь, в случае облака мне всё равно придётся держать эти 50G готовыми 24/7/365 — а это львиная доля стоимости — и вот уже вроде как и 10% «в среднем», но де-факто все 90% «мощности», то же самое с диском — вряд-ли какой-то облачный провайдер позволяет динамически менять эти параметры в живой системе, при этом считая только реальное потребление за время использования (ок, AWS/Azure/Google могут, но это требует поддержки со стороны приложений, а это не всегда возможно).
Или другой пример — мне вдруг нужно 4-5 инстансов в KVM на несколько дней для выполнения какой-то работы или эксперимента — в случае облака придётся брать их отдельно (ибо вложение KVM несколько неадекватно) — в вашем случае, к примеру, 4 инстанса по 8G RAM / 100G disk на неделю обойдутся минимум в две месячных стоимости всего DS.
Заметьте, это всё — только на моём личном примере, речь всего-то о несчастных €40-50/мес, но ведь похожие условия могут быть в небольшой фирме, которой периодически (но только чаще и всё также непредсказуемо) могут быть нужны по несколько десятков инстансов на несколько дней-недель — и тут сумма увеличивается раз эдак в 10-20, в пересчете на год уже проще будет купить свои сервера для экспериментов, чем пользоваться облаком.
И есть ещё один важный момент. Поскольку в случае cloud речь про VM и гипервизор, нет абсолютно никакой гарантии что провайдер не лезет внутрь и не наблюдает за клиентом по распоряжению соответствующих структур (или в связи с любопытством админов, или в связи с подкупленным админом) — в случае DS это на 99% решается шифрованием диска, в случае VM — увы, не решается вообще никак, даже если провайдер говорит что всё супер-пупер-надежно-и-муха-не-пролетит — потому что если бы это было действительно так, гарантии на это были бы прописаны в договоре, а пока это ограничено стоимостью времени простоя — это не гарантии. Да, DS могут конфисковать, в теории — но я не говорю про случаи когда нарушается закон, а в других случаях никто DS трогать не будет — ибо это невозможно сделать незаметно.
Я считал по этому: 64 GB RAM, 2x 2000GB HDD, 1Gbit network, 30TB traffic, Core i7-7700, в вашем конфигураторе указывал соответствующие параметры: 4 x CPU, 64 GB RAM, 1000 GB HDD Medium (в моём случае это всё равно RAID1, и IOPS/Latency явно получше).
Получилось €26/день(!) или €780/мес — мой же DS стоит около €40/месяц.
К тому же, у вас «Free guaranteed unlimited channel 5 Mbps expandable to 1000 Mbps» — а у меня это гарантированный 1 Gbit/s (пусть и с траффиком — но он более чем достаточен, к тому же лишние терабайты стоят мелочи, или unlimit с 10 Mbit/s).
Вы, видимо, не обратили внимания на «если просуммировать все случаи таких резких всплесков, облако всё равно оказалось бы дороже».
Один месяц полной загрузки одного сервера в случае облака обошелся бы мне в стоимость двух полноценных серверов за год — вот почему мне выгодней держать DS, и подозреваю, у многих небольших компаний или контрактников примерно аналогичная ситуация.
А также, в случае DS я точно знаю где и как используются его ресурсы, в случае облака я не могу быть уверен на 100% что получу свои vCPU и vRAM, нет гарантии что на хосте никто не тормозит мой инстанс, и т.д. — а если гарантии даются, то это уже сравнимо со стоимостью аналогичного DS (что логично), но поскольку это облако, то чаще всего оно ощутимо дороже аналогичного DS. В сравнении с вашими услугами, к примеру — всего два дня у вас в конфигурации моего DS стоят больше одного месяца (в 17(!) раз выше), не говоря уже про SLA на диски и сеть (очень мало). Если взять три DS чтобы обеспечить «bulletproof» HA/LB, они всё равно обойдутся в несколько раз дешевле чем конфигурация одного из них в вашем облаке.
Самое печальное, впрочем, не это — дело в том, что в случае DS, что в случае PaaA/IaaS, провайдер отвечает не более чем стоимостью времени простоя (в редких случаях это выше, но всё равно не выше 250%-500%) — то есть бремя затрат/потерь в случае проблем всё равно на клиенте, в то время как SLA для DS и облака (в пределах одного провайдера) редко отличаются.
Если уж сравнивать с такси… то вот более полная аналогия.
Можно взять такси (облако), с условным автомобилем фирмы X в качестве оного, и можно взять в аренду (dedicated server) автомобиль фирмы X — что будет выгодней (водители свои и очень квалифицированные)? Если ездить много и постоянно — явно не такси, хотя качество и характеристики самого автомобиля одинаковое в обоих случаях. Впрочем, в случае постоянных и непрерывных поездок на протяжении длительного времени этот самый X можно будет купить — это будет дешевле и такси, и аренды, без потери качества.
Как уже выше отметили, построить своё облако (при наличии ресурсов и специалистов) будет выгодней чем использовать чужое — в конце концов, большинство фирм которые выросли именно так и поступают.
Приведу более простой личный пример. У меня есть парочка серверов, довольно мощных, для хобби, экспериментов и иногда контрактых работ, их простой не нанесет мне убытка хотя и будет неприятен. Обходятся они мне в сумме около $100/мес, работают надежно (де-факто SLA > 99,99 при обещанных 99,9). Сервера на разных провайдерах и в разных странах (мало ли что), оба провайдера крупные игроки на рынке и предлагают также облачные решения. Но если бы я выбрал аналогичные по мощности и ресурсам облачные решения (не только у этих провайдеров — а из всех более-менее крупных), то это бы стоило уже раз в 10 дороже.
Да, я переплачиваю, ибо не использую мощности и ресурсы серверов на 100%, даже на 10%, но в любой момент могу это сделать (и делаю периодически), в то время как облачный вариант этого бы не позволил — если просуммировать все случаи таких резких всплесков, облако всё равно оказалось бы дороже (я считал).
К чему это всё… Нет, я не утверждаю что облако невыгодно в принципе — это конечно не так, своя ниша у него есть, но вы его пытаетесь подавать как серебрянную пулю с низкой стоимостью — а это не совсем честно, как мне кажется.
Без точного знания конкретной задачи и учета всех переменных невозможно сказать заранее что будет выгодней — IaaS, PaaS, своё облако или свой датацентр, всё нужно считать для каждого конкретного случая.
Если, условно, час простоя для компании обходится в $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: Это, разумеется, только общий обзор — дьяволов в деталях достаточно :)
В случае DS, есть SLA на RTO по железу, остальное уже ЗО клиента.
Соответственно, имея доступ к памяти, можно легко получить все ключи шифрования, или, как пример, все сертификаты с приватными ключами — благо структуры данных в памяти известны.
В случае DS для этого придётся как минимум его отключить и загрузится со своей recovery system, но это невозможно сделать незаметно, да и просто любопытный это вряд ли сделает.
Что и приводит к вопросу — зачем платить больше?
Проблема в том что потребности в ресурсах не всегда предсказуемы — я не знаю когда и насколько мне понадобятся все 64GB с 4 CPU (хотя всё же чуть больше чем 4, если учесть HT), зато я точно знаю что мне в обозримом будущем не потребуется больше, т.е. если вдруг это таки будет месяц 100% загрузки — всё, я попал на годовую стоимость DS всего за месяц. OK, если это нужно клиенту — не совсем попал — клиент заплатит, конечно, но не всегда это нужно только клиенту, да и драть втридорога с клиентов тоже не хочется.
Если вдруг мой клиент решит что ему нужен инстанс у меня на какое-то время (или нужен буден инстанс для выполнения работы на длительное время — так бывает), я смогу это сделать не заплатив лишнего цента провайдеру и не урезая своих ресурсов.
Некоторые из крутящихся приложений расчитаны на то что в любой момент (при запросе извне) они получат всю мощь, а не будут урезаны текущим инстансом и его ресурсами, т.е. вдруг нужно 50G RAM (без свопа!) на несколько секунд-минут, и так с периодичностью в час-два — как вы догадываетесь, в случае облака мне всё равно придётся держать эти 50G готовыми 24/7/365 — а это львиная доля стоимости — и вот уже вроде как и 10% «в среднем», но де-факто все 90% «мощности», то же самое с диском — вряд-ли какой-то облачный провайдер позволяет динамически менять эти параметры в живой системе, при этом считая только реальное потребление за время использования (ок, AWS/Azure/Google могут, но это требует поддержки со стороны приложений, а это не всегда возможно).
Или другой пример — мне вдруг нужно 4-5 инстансов в KVM на несколько дней для выполнения какой-то работы или эксперимента — в случае облака придётся брать их отдельно (ибо вложение KVM несколько неадекватно) — в вашем случае, к примеру, 4 инстанса по 8G RAM / 100G disk на неделю обойдутся минимум в две месячных стоимости всего DS.
Заметьте, это всё — только на моём личном примере, речь всего-то о несчастных €40-50/мес, но ведь похожие условия могут быть в небольшой фирме, которой периодически (но только чаще и всё также непредсказуемо) могут быть нужны по несколько десятков инстансов на несколько дней-недель — и тут сумма увеличивается раз эдак в 10-20, в пересчете на год уже проще будет купить свои сервера для экспериментов, чем пользоваться облаком.
И есть ещё один важный момент. Поскольку в случае cloud речь про VM и гипервизор, нет абсолютно никакой гарантии что провайдер не лезет внутрь и не наблюдает за клиентом по распоряжению соответствующих структур (или в связи с любопытством админов, или в связи с подкупленным админом) — в случае DS это на 99% решается шифрованием диска, в случае VM — увы, не решается вообще никак, даже если провайдер говорит что всё супер-пупер-надежно-и-муха-не-пролетит — потому что если бы это было действительно так, гарантии на это были бы прописаны в договоре, а пока это ограничено стоимостью времени простоя — это не гарантии. Да, DS могут конфисковать, в теории — но я не говорю про случаи когда нарушается закон, а в других случаях никто DS трогать не будет — ибо это невозможно сделать незаметно.
Получилось €26/день(!) или €780/мес — мой же DS стоит около €40/месяц.
К тому же, у вас «Free guaranteed unlimited channel 5 Mbps expandable to 1000 Mbps» — а у меня это гарантированный 1 Gbit/s (пусть и с траффиком — но он более чем достаточен, к тому же лишние терабайты стоят мелочи, или unlimit с 10 Mbit/s).
Вы, видимо, не обратили внимания на «если просуммировать все случаи таких резких всплесков, облако всё равно оказалось бы дороже».
Один месяц полной загрузки одного сервера в случае облака обошелся бы мне в стоимость двух полноценных серверов за год — вот почему мне выгодней держать DS, и подозреваю, у многих небольших компаний или контрактников примерно аналогичная ситуация.
А также, в случае DS я точно знаю где и как используются его ресурсы, в случае облака я не могу быть уверен на 100% что получу свои vCPU и vRAM, нет гарантии что на хосте никто не тормозит мой инстанс, и т.д. — а если гарантии даются, то это уже сравнимо со стоимостью аналогичного DS (что логично), но поскольку это облако, то чаще всего оно ощутимо дороже аналогичного DS. В сравнении с вашими услугами, к примеру — всего два дня у вас в конфигурации моего DS стоят больше одного месяца (в 17(!) раз выше), не говоря уже про SLA на диски и сеть (очень мало). Если взять три DS чтобы обеспечить «bulletproof» HA/LB, они всё равно обойдутся в несколько раз дешевле чем конфигурация одного из них в вашем облаке.
Самое печальное, впрочем, не это — дело в том, что в случае DS, что в случае PaaA/IaaS, провайдер отвечает не более чем стоимостью времени простоя (в редких случаях это выше, но всё равно не выше 250%-500%) — то есть бремя затрат/потерь в случае проблем всё равно на клиенте, в то время как SLA для DS и облака (в пределах одного провайдера) редко отличаются.
Можно взять такси (облако), с условным автомобилем фирмы X в качестве оного, и можно взять в аренду (dedicated server) автомобиль фирмы X — что будет выгодней (водители свои и очень квалифицированные)? Если ездить много и постоянно — явно не такси, хотя качество и характеристики самого автомобиля одинаковое в обоих случаях. Впрочем, в случае постоянных и непрерывных поездок на протяжении длительного времени этот самый X можно будет купить — это будет дешевле и такси, и аренды, без потери качества.
Как уже выше отметили, построить своё облако (при наличии ресурсов и специалистов) будет выгодней чем использовать чужое — в конце концов, большинство фирм которые выросли именно так и поступают.
Приведу более простой личный пример. У меня есть парочка серверов, довольно мощных, для хобби, экспериментов и иногда контрактых работ, их простой не нанесет мне убытка хотя и будет неприятен. Обходятся они мне в сумме около $100/мес, работают надежно (де-факто SLA > 99,99 при обещанных 99,9). Сервера на разных провайдерах и в разных странах (мало ли что), оба провайдера крупные игроки на рынке и предлагают также облачные решения. Но если бы я выбрал аналогичные по мощности и ресурсам облачные решения (не только у этих провайдеров — а из всех более-менее крупных), то это бы стоило уже раз в 10 дороже.
Да, я переплачиваю, ибо не использую мощности и ресурсы серверов на 100%, даже на 10%, но в любой момент могу это сделать (и делаю периодически), в то время как облачный вариант этого бы не позволил — если просуммировать все случаи таких резких всплесков, облако всё равно оказалось бы дороже (я считал).
К чему это всё… Нет, я не утверждаю что облако невыгодно в принципе — это конечно не так, своя ниша у него есть, но вы его пытаетесь подавать как серебрянную пулю с низкой стоимостью — а это не совсем честно, как мне кажется.
Без точного знания конкретной задачи и учета всех переменных невозможно сказать заранее что будет выгодней — IaaS, PaaS, своё облако или свой датацентр, всё нужно считать для каждого конкретного случая.
Если, условно, час простоя для компании обходится в $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