Пиратство программного обеспечения является одной из основных проблем для разработчиков.
А кто-то это реально считал? Есть какие-то экономические обоснованния сего утверждения — например типа "если бы не пираты, то наши продажи выросли бы в три раза" или хотя бы "из-за пиратов мы продали в три раза меньше"?
Просто мне кажется что роль пиратов очень сильно преувеличена — даже без навороченной защиты, с чем-то простым (типа напоминалки о платности), большинству (которое способно заплатить) проще купить чем заморачиваться с пиратскими версиями.
Это примерно та же история что и с пиратсвом фильмов и музыки — оно вроде как и есть, но в то же время не мешает издателям получать сверхприбыли и многократно отбивать стоимость продукции, причём совершенно не факт что те кто спиратил заплатили бы.
Лица, права и законные интересы которых нарушены владельцем социальной сети, могут обжаловать его решения в суде, «в том числе с исками о возмещении убытков, компенсации морального вреда, защите чести, достоинства и деловой репутации».
Вот этого момента похоже никто не заметил, а он пожалуй может перекрыть по своей значимости все остальные "цензурные" пункты, потому что сейчас пользователь любой социалки и вообще любого "бесплатного" сервиса (почта, хостинг картинок и блогов etc) практически бесправен.
Если это действительно будет реализовано (правильно реализовано) — то сетям придётся сильно постараться чтобы не вымарать то что "незаконным контентом" не является и правил не нарушает — иначе им придётся за это отвечать.
Ошибаетесь. Флуд в чистом виде — это статьи про упаковку на ресурсе посвященному IT, причём про упаковку которая к этому самому IT совсем не имеет отношения.
Что этот самый верхний уровень должен с этой информацией делать?
В случае невозможности что-то сделать он может (даже должен) как минимум сообщить об этом, сделав запись в лог (или выведя сообщение) — это сильно поможет в отладке и корректировке кода, потому что завершение с сообщение в духе "программа завершилась по ошибке" не дает ровно никакой полезной информации.
Вот как? Мнение того кто ест имеет меньшее значение чем того кто готовит? Не по этой ли причине потребители получают и товары и упаковки которые их не устраивают? Ведь ценность мнения их производителей и разработчиков выше, по вашей логике.
Если позволите, буду писать и выкладывать по мере появления внутренней мотивации.
Для экономии времени в следующей раз сразу сделайте пометку в начале статьи — "пишу для себя; мне всё равно что вы думаете; уверен в своей правоте; ваши мнения меня не интересуют и буду рад вам это сказать ещё раз в комментариях".
Просить написать значительно менее трудоемко, чем написать.
Необязательно быть поваром чтобы высказаться о том как приготовлено блюдо — хочется верить что пишите вы для всех, а не только для писателей, и что вам действительно важно мнение читателей.
специальные сахарницы, с узким горлышком — дозатором
Так себе изобретение — не помню ни одного раза когда высыпалось хотя бы меньше чем хочется, всегда такая порция что хоть вешайся потом. Вообще любые дозаторы обречены — если только не "заточены" на заведомо маленькие порции (как солонки и перечницы, например, хотя и там монстры попадаются).
Это когда один раз перепад — смешно, а когда это происходит два-три месяца каждый день — уже не смешно. Хотя попробуйте, может таки посмеетесь.
на порядки (т.е. в 100 раз минимум)
В 10 тоже. Посчитайте затраты на помещение с кондиционированием в жарком или холодном климате, если у вас нет DC а небольшая совсем не IT компания.
Все стоит в обычной серверной без какого либо экстрима по кондиционированию.
Вот — "обычная серверная" уже предполагает кондиционирование и предоставляет необходимый режим. Но "обычные серверные" есть не у всех, знаете-ли, а данные хранить где-то нужно — посему покупаются (уже нет) устройства для ленточек (слава рекламе и пробивным продажникам) и потом получаем проблемы.
Я могу привести ссылку на сотни погибших лент, который лежали в помещении при температуре около 30 градусов днём и 15 градусов ночью — сойдёт за неофициальную спецификацию? Что примечательно, лежавшие в том же помещении HDD совершенно не пострадали.
Хотя если говорить про производителя — то официально для длительного хранения нужна температура от 16 до 25°C, с относительной влажностью от 20 до 50% (правда, ни слова про то что будет если она будет колебаться в этих пределах ежедневно).
Теперь мысленно перенесемся в климатическую зону где температуры и влажность "на улице" сильно за пределами этой спецификации большую часть года — и получаем "спецусловия" — помещение со стабильной температурой и влажностью, т.е. кондиционированием, а не "бросил и забыл". Хотя да — в условиях DC это и так уже есть, тут можно сэкономить, но ведь ленты используются не только в DC, правда ведь?
В критерии не написано: узкое горлышко — the best forever.
Именно это и написано. У вас всего две части — "хорошо" и "плохо", без уточнений. А то что каждый из элементов в каждой из частей может быть (а может и не быть) применен в зависимости от ещё сотни факторов — ни слова.
Вы проходитесь по списку и сравниваете — "есть — должно быть" — и если кто-то вдруг решит пройтись по вашему (а я уверен — кто-то обязательно найдётся, и может быть даже станет ответственным лицом по производству упаковок), то все банки с кофе должны быть забракованы за широкое горлышко, а все упаковки для крупногабаритных товаров — за невозможность держать одной рукой.
Если вы скажете что нужно применять здравый смысл и всё такое — отлично, дайте хотя бы краткое описание в каких случаях какой критерий применять (и не применять), с примерами (выше уже просили).
Так что всё-таки прямое назначение HTTP — прикладное, а не транспортное.
Про это выше уже ответили — грань между транспорторм и приложением очень размыта. Банальный SMTP тоже может использоваться как транспорт.
Если бы вы немного внимательнее читали про REST, то знали бы что в нём на одном URL может находится одна сущность.
Здорово. А теперь представим что у нас ошибка в URL и вместо "GET /users/user-name" ушёл запрос "GET /uzars/user-name" — как клиент узнает что у него ошибка в URL? По спецификации нужно вернуть 404 в обоих случаях.
И нет, никто не прибил гвоздями это требование — у кого-то она одна, у кого-то их много, потому что REST — это не стандарт, не говоря уже просто многочисленные REST-like. Почему так? Да именно потому что в "чистом" виде REST применим ну в очень узком круге приложений, для чего-то реально сложного он уже недостаточен и скатывается только к транспортной роли.
Неужели Вы верите в возможность реализации стандарта, который сможет описать совершенно любые детали ошибок?
Верю. Это не так сложно как кажется для большинства ошибок — потому что большинство же запросов обладают чем-то общим, и многое можно вывести на абстрактный уровень, хотя на самом высоком уровне достаточно будет хотя бы привёдённого мной списка.
Правда, основная проблема в другом — большинство просто не заморачивается детальной диагностикой и классификацией, это ж сколько кода нужно "лишнего", ведь гораздо проще вернуть 400 на любую проблему при разборе запроса и пусть клиент сам решает что там пошло не так, хотя аж в давно забытых года и во времена DOS уже были сделаны первые шаги в этом направлении — с разделением ошибок на классы и даже рекомендациями по их обработке.
При том что широкое горло в банке с растворимым кофе (или сахаром, или солью, не говоря уже про жгучий перец и т.п.) не провоцирует "избыточное нанесение", а вот узкое очень сильно затруднило бы это самое "нанесение", точнее доставание продукта — а ведь достают его оттуда как раз мелкими порциями.
Суть моего примера как раз в том что нельзя всё мерять одной линейкой — "узкое горло" не всегда удобно для "требуется мало продукта".
Её удобно держать одной рукой, удобно поставить и повесить.
Очень актуально для упаковок холодильников, микроволновок и прочих устройств — не то что одной рукой, у них часто даже ручек нет, что уж тут говорить про "повесить".
У нее широкое горло – хотя требуется мало продукта.
Да, безусловно, это очень большое упущение — банки с растворимым кофе, а также упаковки с солью и сахаром должны иметь очень узкое горло — и не менее узкие ложечки для добывания продукта в минимальных количествах.
Её содержимое нельзя просто использовать – нужно иметь (ложку, кисточку, спонжик и т.п.).
Ну как же без этого… давайте в каждую банку или коробку с сыпучим товаром будем класть ложечки и прочее, ведь ни у кого нет ложечек и т.п., а предприятиям по переработке мусора недостаточно сырья для переработки.
А теперь серьёзно — нет универсальных принципов для упаковки, кроме очень узкого списка — типа маркировки и описания/индикации содержимого, всё это сильно зависит от вида товара.
И хватит уже делать из упаковки шедевры исскусства — потому что 99% всех упаковок идут в мусор сразу после доставания товара, главное — функция и практичность, а не внешний вид. Когда я вижу в рекламе товара ссылку на "супер-пупер" упаковку очень хочется спросить этих гением от рекламы — они продают упаковку или собственно товар?
Правда, за $12 500 можно купить SSD объемом в 50 ТБ, но и это очень недешево.
… или можно купить 50 SSD накопителей по 2 TB каждый, или чёртову дюжину накопителей по 8 TB с суммарной ёмкостью 100 TB, — по цене около $10000 за все.
А ленты… их на пыльную полку не положить, нужны специальные условия для хранения и эксплуатации — т.е. к стоимости накопителей добавляется стоимость инфраструктуры для их использования и хранения, и расходы возрастают на порядки.
у HTTP есть заметный плюс — подробная и продуманная спецификация, которая уже не одно десятилетие применяется на практике.
Да — пока HTTP используется по прямому назначению — как транспорт. Хотя транспорт для всего — это уже несколько больше чем HTTP, ибо уже не совсем гипертекст, так что имя вводит в заблуждение, да.
Почти все знают что означают коды 200, 404 и 500.
200 — да, все знают — запрос был отправлен, обработан и получен ответ.
404 — нет объекта операции или нет endpoint? А если операция затрагивает больше одного объекта?
500 — проблемы у LB, прокси или самого приложения?
Про остальные коды уже раньше высказывались — с ними те же проблемы.
Транспорт должен отвечать только за одну вещь — собственно, доставку запросов и ответов на них, то есть — 200 если доставлено приложению и оно дало ответ, и любой другой >= 300 если не получилось это сделать.
Все остальные ошибки (с детализацией или без) должны быть внутри ответов (они в любом случае часто очень специфичны для конкретного приложения).
И ещё — любые сообщения об ошибках (структурированные или нет) должны давать достаточно информации чтобы клиент смог понять:
что он сделал не так и как это исправить:
если "нетаков" много, то каждый должен быть сообщен индивидуально и подробно:
плохо: "неправильный параметр", "неправильное значение в каком-то параметре".
хорошо: "параметр xyz неизвестен", "значение парметра xyz должно быть целым числом в диапазоне 100-200", "параметр xyz необходим для выполнения запроса"
имеет ли смысл повторять запрос (если он не выполнился с абстрактным "ошибка сервера")
Очевидно, что в случае кодов HTTP (и даже дополнительных заголовков), их явно недостаточно даже для этого минимума.
KVM с виртуальными устройствами (virtio*) никак не может быть быстрее чем прямой доступ к устройствам на хосте, это невозможно в принципе. А docker может быть медленнее потому что использует overlayfs, да ещё и не в один слой — там потери побольше будут.
За счёт того что добавляется хороший оверхед, да ещё и включены митигации всяких процессорных эксплойтов — то проседание реально может быть очень ощутимым.
С контейнерами конечно проще, но и там влияют митигации (как и на сам хост, собственно) — в зависимости от загрузки и паттернов использования до 50% может быть проседание, так что если хост не используется для публичного хостинга, то mitigations=off очень сильно помогает, особенно если там быстрые устройства (NVMe, 10GbE & co).
не всегда правильно настроенная виртуальная среда и гостевая ОС дадут просадку в производительности
Не всегда — пока это вычислительные задачи, cpu-bound. Попробуйте погонять тесты которые используют либо дисковый либо сетевой обмен данными — вот где виртуализация можеть сильно просадить производительность, вплоть до "в разы".
Если не Home — то позволяет точно, устанавливается в политиках.
Вообще-то нет, ошибка перевода, в оригинале:
Т.е. "десятую часть" — в десять раз дешевле. Да и в этом контексте странно было бы ожидать что хотят продавать в десять раз дороже.
А кто-то это реально считал? Есть какие-то экономические обоснованния сего утверждения — например типа "если бы не пираты, то наши продажи выросли бы в три раза" или хотя бы "из-за пиратов мы продали в три раза меньше"?
Просто мне кажется что роль пиратов очень сильно преувеличена — даже без навороченной защиты, с чем-то простым (типа напоминалки о платности), большинству (которое способно заплатить) проще купить чем заморачиваться с пиратскими версиями.
Это примерно та же история что и с пиратсвом фильмов и музыки — оно вроде как и есть, но в то же время не мешает издателям получать сверхприбыли и многократно отбивать стоимость продукции, причём совершенно не факт что те кто спиратил заплатили бы.
Вот этого момента похоже никто не заметил, а он пожалуй может перекрыть по своей значимости все остальные "цензурные" пункты, потому что сейчас пользователь любой социалки и вообще любого "бесплатного" сервиса (почта, хостинг картинок и блогов etc) практически бесправен.
Если это действительно будет реализовано (правильно реализовано) — то сетям придётся сильно постараться чтобы не вымарать то что "незаконным контентом" не является и правил не нарушает — иначе им придётся за это отвечать.
Ошибаетесь. Флуд в чистом виде — это статьи про упаковку на ресурсе посвященному IT, причём про упаковку которая к этому самому IT совсем не имеет отношения.
В случае невозможности что-то сделать он может (даже должен) как минимум сообщить об этом, сделав запись в лог (или выведя сообщение) — это сильно поможет в отладке и корректировке кода, потому что завершение с сообщение в духе "программа завершилась по ошибке" не дает ровно никакой полезной информации.
Вот как? Мнение того кто ест имеет меньшее значение чем того кто готовит? Не по этой ли причине потребители получают и товары и упаковки которые их не устраивают? Ведь ценность мнения их производителей и разработчиков выше, по вашей логике.
Для экономии времени в следующей раз сразу сделайте пометку в начале статьи — "пишу для себя; мне всё равно что вы думаете; уверен в своей правоте; ваши мнения меня не интересуют и буду рад вам это сказать ещё раз в комментариях".
Необязательно быть поваром чтобы высказаться о том как приготовлено блюдо — хочется верить что пишите вы для всех, а не только для писателей, и что вам действительно важно мнение читателей.
Так себе изобретение — не помню ни одного раза когда высыпалось хотя бы меньше чем хочется, всегда такая порция что хоть вешайся потом. Вообще любые дозаторы обречены — если только не "заточены" на заведомо маленькие порции (как солонки и перечницы, например, хотя и там монстры попадаются).
Это когда один раз перепад — смешно, а когда это происходит два-три месяца каждый день — уже не смешно. Хотя попробуйте, может таки посмеетесь.
В 10 тоже. Посчитайте затраты на помещение с кондиционированием в жарком или холодном климате, если у вас нет DC а небольшая совсем не IT компания.
Вот — "обычная серверная" уже предполагает кондиционирование и предоставляет необходимый режим. Но "обычные серверные" есть не у всех, знаете-ли, а данные хранить где-то нужно — посему покупаются (уже нет) устройства для ленточек (слава рекламе и пробивным продажникам) и потом получаем проблемы.
Я могу привести ссылку на сотни погибших лент, который лежали в помещении при температуре около 30 градусов днём и 15 градусов ночью — сойдёт за неофициальную спецификацию? Что примечательно, лежавшие в том же помещении HDD совершенно не пострадали.
Хотя если говорить про производителя — то официально для длительного хранения нужна температура от 16 до 25°C, с относительной влажностью от 20 до 50% (правда, ни слова про то что будет если она будет колебаться в этих пределах ежедневно).
Теперь мысленно перенесемся в климатическую зону где температуры и влажность "на улице" сильно за пределами этой спецификации большую часть года — и получаем "спецусловия" — помещение со стабильной температурой и влажностью, т.е. кондиционированием, а не "бросил и забыл". Хотя да — в условиях DC это и так уже есть, тут можно сэкономить, но ведь ленты используются не только в DC, правда ведь?
Именно это и написано. У вас всего две части — "хорошо" и "плохо", без уточнений. А то что каждый из элементов в каждой из частей может быть (а может и не быть) применен в зависимости от ещё сотни факторов — ни слова.
Вы проходитесь по списку и сравниваете — "есть — должно быть" — и если кто-то вдруг решит пройтись по вашему (а я уверен — кто-то обязательно найдётся, и может быть даже станет ответственным лицом по производству упаковок), то все банки с кофе должны быть забракованы за широкое горлышко, а все упаковки для крупногабаритных товаров — за невозможность держать одной рукой.
Если вы скажете что нужно применять здравый смысл и всё такое — отлично, дайте хотя бы краткое описание в каких случаях какой критерий применять (и не применять), с примерами (выше уже просили).
Про это выше уже ответили — грань между транспорторм и приложением очень размыта. Банальный SMTP тоже может использоваться как транспорт.
Здорово. А теперь представим что у нас ошибка в URL и вместо "GET /users/user-name" ушёл запрос "GET /uzars/user-name" — как клиент узнает что у него ошибка в URL? По спецификации нужно вернуть 404 в обоих случаях.
И нет, никто не прибил гвоздями это требование — у кого-то она одна, у кого-то их много, потому что REST — это не стандарт, не говоря уже просто многочисленные REST-like. Почему так? Да именно потому что в "чистом" виде REST применим ну в очень узком круге приложений, для чего-то реально сложного он уже недостаточен и скатывается только к транспортной роли.
Верю. Это не так сложно как кажется для большинства ошибок — потому что большинство же запросов обладают чем-то общим, и многое можно вывести на абстрактный уровень, хотя на самом высоком уровне достаточно будет хотя бы привёдённого мной списка.
Правда, основная проблема в другом — большинство просто не заморачивается детальной диагностикой и классификацией, это ж сколько кода нужно "лишнего", ведь гораздо проще вернуть 400 на любую проблему при разборе запроса и пусть клиент сам решает что там пошло не так, хотя аж в давно забытых года и во времена DOS уже были сделаны первые шаги в этом направлении — с разделением ошибок на классы и даже рекомендациями по их обработке.
При том что широкое горло в банке с растворимым кофе (или сахаром, или солью, не говоря уже про жгучий перец и т.п.) не провоцирует "избыточное нанесение", а вот узкое очень сильно затруднило бы это самое "нанесение", точнее доставание продукта — а ведь достают его оттуда как раз мелкими порциями.
Суть моего примера как раз в том что нельзя всё мерять одной линейкой — "узкое горло" не всегда удобно для "требуется мало продукта".
Очень актуально для упаковок холодильников, микроволновок и прочих устройств — не то что одной рукой, у них часто даже ручек нет, что уж тут говорить про "повесить".
Да, безусловно, это очень большое упущение — банки с растворимым кофе, а также упаковки с солью и сахаром должны иметь очень узкое горло — и не менее узкие ложечки для добывания продукта в минимальных количествах.
Ну как же без этого… давайте в каждую банку или коробку с сыпучим товаром будем класть ложечки и прочее, ведь ни у кого нет ложечек и т.п., а предприятиям по переработке мусора недостаточно сырья для переработки.
А теперь серьёзно — нет универсальных принципов для упаковки, кроме очень узкого списка — типа маркировки и описания/индикации содержимого, всё это сильно зависит от вида товара.
И хватит уже делать из упаковки шедевры исскусства — потому что 99% всех упаковок идут в мусор сразу после доставания товара, главное — функция и практичность, а не внешний вид. Когда я вижу в рекламе товара ссылку на "супер-пупер" упаковку очень хочется спросить этих гением от рекламы — они продают упаковку или собственно товар?
… или можно купить 50 SSD накопителей по 2 TB каждый, или чёртову дюжину накопителей по 8 TB с суммарной ёмкостью 100 TB, — по цене около $10000 за все.
А ленты… их на пыльную полку не положить, нужны специальные условия для хранения и эксплуатации — т.е. к стоимости накопителей добавляется стоимость инфраструктуры для их использования и хранения, и расходы возрастают на порядки.
Да — пока HTTP используется по прямому назначению — как транспорт. Хотя транспорт для всего — это уже несколько больше чем HTTP, ибо уже не совсем гипертекст, так что имя вводит в заблуждение, да.
Про остальные коды уже раньше высказывались — с ними те же проблемы.
Транспорт должен отвечать только за одну вещь — собственно, доставку запросов и ответов на них, то есть — 200 если доставлено приложению и оно дало ответ, и любой другой >= 300 если не получилось это сделать.
Все остальные ошибки (с детализацией или без) должны быть внутри ответов (они в любом случае часто очень специфичны для конкретного приложения).
И ещё — любые сообщения об ошибках (структурированные или нет) должны давать достаточно информации чтобы клиент смог понять:
Очевидно, что в случае кодов HTTP (и даже дополнительных заголовков), их явно недостаточно даже для этого минимума.
KVM с виртуальными устройствами (virtio*) никак не может быть быстрее чем прямой доступ к устройствам на хосте, это невозможно в принципе. А docker может быть медленнее потому что использует overlayfs, да ещё и не в один слой — там потери побольше будут.
За счёт того что добавляется хороший оверхед, да ещё и включены митигации всяких процессорных эксплойтов — то проседание реально может быть очень ощутимым.
С контейнерами конечно проще, но и там влияют митигации (как и на сам хост, собственно) — в зависимости от загрузки и паттернов использования до 50% может быть проседание, так что если хост не используется для публичного хостинга, то mitigations=off очень сильно помогает, особенно если там быстрые устройства (NVMe, 10GbE & co).
Не всегда — пока это вычислительные задачи, cpu-bound. Попробуйте погонять тесты которые используют либо дисковый либо сетевой обмен данными — вот где виртуализация можеть сильно просадить производительность, вплоть до "в разы".
Не было там таких "нативных" команд — кроме случая косвенной адрессации посредством регистра, но и то с ограничениями (
*x++ и *--x).И это "что-то" нужно обычному пользователю? Потому что обычно то что может купить только корпорация обычно и нужно только корпорации.