Можно убрать это нафиг и больше никогда не возвращать? Или чтобы нужно было принудительно в настройках профиля включать эту кнопку-объяснялку где-нибудь рядом с опциями для слабовидящих и слабослышаших?
Это такая бестактная наглая ложь,что она выдернула меня из постели и заставила написать комментарий.
Не поленитесь скачать QuickBasic, написать какую-нибудь простенькую программу, скомпилировать, а потом посмотреть полученный EXE-файл в hex-редакторе и найдите там исходник.
И что? Они там не просто так, наверное. И всегда существует масса способов оформить внешнее восприятие кода так, чтобы не путаться в скобочках. А если кого-то пара ВНЕШНИХ скобочек огорачает своей избыточностей, то может надо чем-нибудь другим заниматься?
Разве у новых языков это не так?
Плевать, как там хипстеры выделываются. У них design decisions делаются по принципу «лишь бы выпрендриться и отличиться от классики».
Категорически против убирания круглых скобок у условий.
Визуальную нагрузку — вы серьёзно? Дело попахивает СДВГ, если пара лишних скобочек мешает вам работать и адекватно воспринимать код.
К тому же, есть общая логика в том, что все control structure имеет унифицированный синтаксис keyword(...) statementsblock
Если убирать скобочки у if, то тогда по общей логике нужно убирать и у while, for, switch, а это не совместимо с тем, что у for внутри скобочек не просто выражение, а несколько выражений.
К тому же, скобочки у обычного if прекрасно контрастируют с отсутствием скобочек у #if, а устранение скобочек сближает по степени схожести.
Желание убрать скобочки — это когда делать больше нечего, а что-то сделать хочется.
А электро-энцефалограмма что в таком случае пишет при исследовании активности мозга?
Пишет побочный эффект протекания электрохимических процессов в миллиардах клеток (среднюю температуру по больницы).
Пока у нас в компьютерах вольты, на ЭЭГ даже не милливольты, а микровольты. Миллионная доля вольта. Потому что это побочный продукт.
Давайте зайдём в другой стороны: слово «нейромедиаторы» вам о чём нибудь говорит? Глутамат, серотонин, ацетилхолин? Если бы нервная ткань была просто сплетением проводов (но не металлических, а органичвеского происхождения), передающих электрические импульсы, то зачем бы всё это было необходимо?
Нужно очень сильное воздействие, в естественных условиях такой мощности "помех" просто нет.
Как насчёт аппарата МРТ? Как насчёт металлургических предприятий с печами дуговой плавки? Военные радары с киловаттными излучателями? Не в одном из перечисленых случаев люди не испытывают галлюцинации, не сбиваются с мыслей, не теряют сознание и не срываются в эпилептический припадок. От военных радовов воздействие наступало, но в виде поджаривания плоти.
Но, возможна например электро-судорожная терапия, когда мозг "перезагружают" именно электрическим разрядом.
Что если всё дело в том, что протекание электрических токов просто ломает и подавляет внутреннюю химию мозга?
Отвратительный синтаксис; такое впечатление, что создатели новомодных языков соревнуются в том, как бы эффективнее вызвать кровотечение из глаз читающего.
Также при встрече с очередной такой статьей ещё раз проникаешься мыслью, насколько же гениальны были создатели Си, и что лаконичнее уже ничего быть не может.
Все эти fn и двоеточия даром не нужны. Особенно сильно бесят сокращения pub и fn. Это какая жалкая экономия на спичках. Так и представляю себе, как автор языка уделал всех остальных программистов мира в скорости разработки за счет экономии на буквах. Только вот есть один большой просчет. Как же это так, что у нас есть красивый и компактный fn, и при этом остался омерзительный жирный return? Должно быть ret, а ещё лучше просто r. Экономия должна быть экономной. Ну и const нужно сократить до cn.
Спасибо, но я остаюсь на Си, ваш синтаксический сахар меня не усластил.
Естественно, мы люди бедные, мы будем нацеливаться повторить рентген-томограф из фекалий и древисины.
Интересующий моментов, естественно, много. У вас линейные (одномерные) детекторы или матричные (двумерные)? Полностью готовое изделие (детектор) ставите в своё устройство или сами производите?
Рентген-КТ неживых объектов сильно проще, потому что не нужны высокие скорости перемещения, высокие быстродействия опроса детектора, передачи и сохранения информации, не нужно беспокоиться и дозовой нагрузке (в большинстве случаев).
Но всё равно хватает технических сложностей. Охлаждение трубки/источника. Как у вас вопрос решён? И вообще, режим работы — импульсный или непрерывный?
Какую мощность в целом потребляет источник, учитывая, что у них смехотворные КПД?
Это всё-таки нишевый продукт. Для определённых стран, для определённых людей. Скажем, я не пользуюсь Uber и не знаю никого в моём окружении, кто использовал бы. Не считая, что чуть больше 10 лет назад я участвовал в стартапе по созданию Uber'а для медицинских перевозок, и там фаундеры конечно использовали Uber, но это Сан-Франциско.
А вот ютубом пользуется буквально каждый человек. Если отбросить людей, у которых вообще нет компьютерной грамотности и которые вообще не пользуются смартфоном (именно как смартфоном, а не бабушко-фоном) и компьютером, то я не знаю людей, которые не пользовались бы ютубом.
Так что ютубу это не простительно.
Да, забыл, кстати, ещё один бесящий баг: ставишь скорость 2x, и на первой же рекламе она сбрасывается до дефолтных 1x. Такой же эффект может оказать перемотка ролика двойным тапом по боковым краям видео. Ну как можно было написать такой кривой код?
Знаете, бороться с помехами на уровне кода — это последнее дело. В прямом смысле последнее — это значит вы на предыдущих рубежах ничего не смогли сделать с помехами. А должны были.
Когда говорят «разводку сделали правильно, но помехи всё равно одерживают верх», чаще всего это означает, что разводку сделали неправильно, но к своему несчастью неправильные решения считают за правильные.
Боль и вообще нервные импульсы — это не электрический сигнал. Иначе бы человек в присутствии источника сильных помех падал бы в обморок, сходил с ума и требовал бы экранирования фольгой.
В каком-то смысле ионы, проходящие через каналы в мембране клеток можно считать ионным током, но неовное волокно это не провод.
слишком быстрое вращение вала , к примеру прошли какой - то участок с одной скорости, а потом резко к примеру начали движение в два раза больше чем было
Если крутизна нарастания фронтов в выходном каскаде энкодера такая низкая, что при быстром вращении сигналы сливаются — значит вы не по задаче выбрали энкодер.
Если крутизна достаточная, но ваш MCU работает на слишком медленной частоте, или вместо прерываний использует опрос, который делается очень редко, то вы неправильно работаете с датчиком.
Это, грубо говоря, как с теоремой Найквиста-Шеннона aka Котельникова — вы должны заранее определиться с максимальной скоростью вращения вала энкодера, вычислить из неё максимальную частоту следования четверть-периодов (квадратур) и выбрать частоту опроса пинов как минимум вдвое больше, чтобы гарантированно ничего не пропустить. Или, если используете прерывания, убедиться, что прерывания успевают вовремя отработать.
Или использовать железную логику и превратить Ch.A + Ch.B в пару Step/Dir, потому что обрабатывать прерывания с такими сигналами должно быть быстрее.
Но в любом случае, если энкодер способен выдавать импульсы чаще, чем МК может обработать, бороться с этим отфильтровыванием запрещённых переходов — бесполезно. Потому что, допустим, вы откинули «запрещённый» переход и отловили легитимный переход. Откуда вы можете быть уверенными, что в интервале между двумя сэмплированиями от энкодера пришёл именно один переход? Может за это время там 3 или 10 переходных edge-в было? Ниоткуда. Поэтому фундаментально правильный подход это гарантированный оверсэмплинг, а не отбрасывание запрещённых переходов.
В оптическом энкодере да ещё и с интегрированным фронтендом (в котором наверняка есть триггеры Шмитта) такого быть не может.
Если у вас polling вместо event-based обработки сигналов, то при слишком медленном опросе и слишком быстром вращении вы можете пропустить оба фронта в интервале между двумя опросами. Но это не запрещённый переход, это, извините, выбранная вами частота опроса порта не соответствует максимально допустимой скорости вращения, определяемой техзаданием.
Я бы их всех разогнал: такого количества багов, как в YT, вряд ли где ещё найдешь в продуктах от таких гигантов.
И самая забагованная часть — это то, что появилось позже всего — шортсы. Если ранее сделанное еще как-то продолжает работать, то шортсы, такое впечатление, писали люди с желе вместо мозга.
В ряде случаев сбивается дискретность перелистывания роликов: отображается половина одного ролика и снизу половина следующего.
Если пролистывать ролики достаточно быстро, чуть быстрее, чем тупорылый код подгрузки и подмены ролика успевает отработать, то происходит рассинхронизация между самим видео и блоком комментариев: видео одно, а комментарии от следующего или предшествующего. Например, видео про сварку труб, а в комментариях все шлют проклятия какому-то наглому мотоциклисту.
Это буквально значит, если упростить, что когда детектируется необходимость смены ролика, вместо того, чтобы взять следующий элемент из цепочки id и подгрузить его:
В коде есть две отдельные независимые переменные, которые хранят id текущего ролика (или наше текущее положение в очереди цепочке айдишников) — одна используется для плеера, другая для комментариев. И когерентность между этими двумя переменными ничем не гарантируется, она зависит от фактора удачи, от того, в какой очерёдности произойдет ряд асинхронных событий. Т.е. это не просто нарушение принципа DRY, принципа, что должен быть один источник авторитетной информации, это ещё и кривой асинхронный код.
Кстати, есть еще и рассинхронизация между адресной строкой (хвала тем, кто придумал переписывание адресной строки без перезагрузки страницы) плеером и комментами. Т.е. ситуация, когда копируешь URL и вставляешь в другой браузер, либо отправляешь кому-то, а там совсем другой ролик — иногда случается. Ролик, который откроется по ссылке, будет, естественно, не случайным — а тем, который был за 1, 2 позиции «перед» тем роликом, который на самом деле проигрывался в момент копирования адреса из адресной строки. Только вот цепочка шортсов каждый раз генерируется случайная, поэтому перелистнуть на соседний после перехода по такой ссылке уже не получится — нужный ролик уже не будет соседним.
Отдельная песня — скроллинг комментариев. Если мы скроллим комменты и внезапно упираемся в конец, событие скроллинга уходит уровнем выше и триггерит перелистывание ролика. А иногда даже не нужно упираться в конец перечня комментов: просто в рандомный момент порция проворачивания колёсика мыши вместо прокручивания комментов чуть-чуть вниз меняет текущий ролик на следующий.
На мобильной версии в ряде случаев оверлей с кнопками лайк/дислайк/комменты просто не появляется. У предыдущего ролика есть, у следующего есть, а у текущего — не отображаются. Можешь сколько угодно крутить ролики вперёд/назад — кнопки не появятся. И нет, это не настройки ролика в духе «запретить комментирование» или «отключить лайки» — если запомнить название ролика, закрыть приложение, открыть заново и найти ролик через поиск — всё у него будет на месте.
Кем надо быть, чтобы написать такой глючный продукт? Бомжей с улицы там что ли набрали?
И вы хотите, чтобы у меня была капля сожаления к тем, кого увольняют? Ни капли. Я зол, и мой гнев праведный, потому что нет оправдания такому кривому коду, особенно когда за ним стоит IT-гигант.
При этом если этот второй хост не будет выполнять для первого хоста роль основного шлюза, то есть не будет роутить и NATить IP-пакеты, то строго говоря это по прежнему будет VPN, но в таком виде услуга нафиг никому не будет нужна.
С другой стороны, если сервис не будет использовать технологию VPN, но каким либо иным образом будет обеспечивать доступ в интернет, то обыватель не поймёт разницы и не почувствует подвоха.
Вывод: под видом VPN продают услугу по проксированию трафика. Если из этой услуги убрать проксирование и оставить VPN, то услуга потеряет смысл. Если убрать VPN и оставить проксирование — никто ничего не заметит. То есть собственно VPN играет в услуге не критическую роль, а 10-ую роль. Но в качестве названия услуги выбирают слово «VPN».
Ну и опять же: смысл VPN что ты один свой хост связываешь с другим своим хостом, и таких хостов может быть произвольное количество. При этом Vиртуальность заключается в том, что для хостов создаётся иллюзия, что они находятся в одной сети (хотя на деле это не так — между ними есть промежуточное звено в виде глобальной сети), а Privатность — в том, что посредники не видят, чем там обмениваются хосты в виртуальной приватной сети, сколько их там и т.п. В общем случае виртуальная сеть может вообще не иметь маршрутизации во внешнюю публичную сеть и это по прежнему легитимный случай VPN. Никто не смеет назвать это каким-то неполноценным VPN.
Что мы имеем на другой чаше весов? Вырожденный случай, когда сеть состоит только из двух хостов, причем только один из них — наш . Добавить ещё один свой хост или несколько в ту же виртуальную сеть нельзя (а это чуть ли не главная фишка VPN). Виртуальность, то есть создание видимости того, будто два хоста соединены напрямую, тонда как фактически это не так — если и есть, то в этом use case'е (обход блокировок) это роли не играет. Приватности никакой нет — второй хост контролируется третьими лицами и он видит всё, что мы передаем. То это это вырожденный случай network (только один свой хост в сети), де-факто виртуальной (хотя никому нет дела), но ни разу не приватной, с главным акцентом на проксирование.
Можно убрать это нафиг и больше никогда не возвращать? Или чтобы нужно было принудительно в настройках профиля включать эту кнопку-объяснялку где-нибудь рядом с опциями для слабовидящих и слабослышаших?
Это такая бестактная наглая ложь,что она выдернула меня из постели и заставила написать комментарий.
Не поленитесь скачать QuickBasic, написать какую-нибудь простенькую программу, скомпилировать, а потом посмотреть полученный EXE-файл в hex-редакторе и найдите там исходник.
И что? Они там не просто так, наверное. И всегда существует масса способов оформить внешнее восприятие кода так, чтобы не путаться в скобочках. А если кого-то пара ВНЕШНИХ скобочек огорачает своей избыточностей, то может надо чем-нибудь другим заниматься?
Плевать, как там хипстеры выделываются. У них design decisions делаются по принципу «лишь бы выпрендриться и отличиться от классики».
Категорически против убирания круглых скобок у условий.
Визуальную нагрузку — вы серьёзно? Дело попахивает СДВГ, если пара лишних скобочек мешает вам работать и адекватно воспринимать код.
К тому же, есть общая логика в том, что все control structure имеет унифицированный синтаксис
keyword(...) statementsblockЕсли убирать скобочки у if, то тогда по общей логике нужно убирать и у while, for, switch, а это не совместимо с тем, что у for внутри скобочек не просто выражение, а несколько выражений.
К тому же, скобочки у обычного if прекрасно контрастируют с отсутствием скобочек у #if, а устранение скобочек сближает по степени схожести.
Желание убрать скобочки — это когда делать больше нечего, а что-то сделать хочется.
Ах как всё легко и просто у людей. Ардуино головного мозга.
Дальше можно было бы прдискутировать относительно каких-то моментов, но автора тут нет, это перевод.
Человек просто любит кошек.
Пишет побочный эффект протекания электрохимических процессов в миллиардах клеток (среднюю температуру по больницы).
Пока у нас в компьютерах вольты, на ЭЭГ даже не милливольты, а микровольты. Миллионная доля вольта. Потому что это побочный продукт.
Давайте зайдём в другой стороны: слово «нейромедиаторы» вам о чём нибудь говорит? Глутамат, серотонин, ацетилхолин? Если бы нервная ткань была просто сплетением проводов (но не металлических, а органичвеского происхождения), передающих электрические импульсы, то зачем бы всё это было необходимо?
Как насчёт аппарата МРТ? Как насчёт металлургических предприятий с печами дуговой плавки? Военные радары с киловаттными излучателями? Не в одном из перечисленых случаев люди не испытывают галлюцинации, не сбиваются с мыслей, не теряют сознание и не срываются в эпилептический припадок. От военных радовов воздействие наступало, но в виде поджаривания плоти.
Что если всё дело в том, что протекание электрических токов просто ломает и подавляет внутреннюю химию мозга?
Отвратительный синтаксис; такое впечатление, что создатели новомодных языков соревнуются в том, как бы эффективнее вызвать кровотечение из глаз читающего.
Также при встрече с очередной такой статьей ещё раз проникаешься мыслью, насколько же гениальны были создатели Си, и что лаконичнее уже ничего быть не может.
Все эти fn и двоеточия даром не нужны. Особенно сильно бесят сокращения pub и fn. Это какая жалкая экономия на спичках. Так и представляю себе, как автор языка уделал всех остальных программистов мира в скорости разработки за счет экономии на буквах. Только вот есть один большой просчет. Как же это так, что у нас есть красивый и компактный fn, и при этом остался омерзительный жирный return? Должно быть ret, а ещё лучше просто r. Экономия должна быть экономной. Ну и const нужно сократить до cn.
Спасибо, но я остаюсь на Си, ваш синтаксический сахар меня не усластил.
Естественно, мы люди бедные, мы будем нацеливаться повторить рентген-томограф из фекалий и древисины.
Интересующий моментов, естественно, много. У вас линейные (одномерные) детекторы или матричные (двумерные)? Полностью готовое изделие (детектор) ставите в своё устройство или сами производите?
Рентген-КТ неживых объектов сильно проще, потому что не нужны высокие скорости перемещения, высокие быстродействия опроса детектора, передачи и сохранения информации, не нужно беспокоиться и дозовой нагрузке (в большинстве случаев).
Но всё равно хватает технических сложностей. Охлаждение трубки/источника. Как у вас вопрос решён? И вообще, режим работы — импульсный или непрерывный?
Какую мощность в целом потребляет источник, учитывая, что у них смехотворные КПД?
Хорошая стать для сайта, где сидят люди, балдеющие по археологии.
Но для Хабра хотелось бы совсем другого: разбор томографа, его конструкции, какая трубка, какой сенсор, параметры среза, напряжение трубки.
Самодельный или серийный, на чем выполняется реконструкция и т.п.
Это всё-таки нишевый продукт. Для определённых стран, для определённых людей. Скажем, я не пользуюсь Uber и не знаю никого в моём окружении, кто использовал бы. Не считая, что чуть больше 10 лет назад я участвовал в стартапе по созданию Uber'а для медицинских перевозок, и там фаундеры конечно использовали Uber, но это Сан-Франциско.
А вот ютубом пользуется буквально каждый человек. Если отбросить людей, у которых вообще нет компьютерной грамотности и которые вообще не пользуются смартфоном (именно как смартфоном, а не бабушко-фоном) и компьютером, то я не знаю людей, которые не пользовались бы ютубом.
Так что ютубу это не простительно.
Да, забыл, кстати, ещё один бесящий баг: ставишь скорость 2x, и на первой же рекламе она сбрасывается до дефолтных 1x. Такой же эффект может оказать перемотка ролика двойным тапом по боковым краям видео. Ну как можно было написать такой кривой код?
Знаете, бороться с помехами на уровне кода — это последнее дело. В прямом смысле последнее — это значит вы на предыдущих рубежах ничего не смогли сделать с помехами. А должны были.
Когда говорят «разводку сделали правильно, но помехи всё равно одерживают верх», чаще всего это означает, что разводку сделали неправильно, но к своему несчастью неправильные решения считают за правильные.
Боль и вообще нервные импульсы — это не электрический сигнал. Иначе бы человек в присутствии источника сильных помех падал бы в обморок, сходил с ума и требовал бы экранирования фольгой.
В каком-то смысле ионы, проходящие через каналы в мембране клеток можно считать ионным током, но неовное волокно это не провод.
Если крутизна нарастания фронтов в выходном каскаде энкодера такая низкая, что при быстром вращении сигналы сливаются — значит вы не по задаче выбрали энкодер.
Если крутизна достаточная, но ваш MCU работает на слишком медленной частоте, или вместо прерываний использует опрос, который делается очень редко, то вы неправильно работаете с датчиком.
Это, грубо говоря, как с теоремой Найквиста-Шеннона aka Котельникова — вы должны заранее определиться с максимальной скоростью вращения вала энкодера, вычислить из неё максимальную частоту следования четверть-периодов (квадратур) и выбрать частоту опроса пинов как минимум вдвое больше, чтобы гарантированно ничего не пропустить. Или, если используете прерывания, убедиться, что прерывания успевают вовремя отработать.
Или использовать железную логику и превратить Ch.A + Ch.B в пару Step/Dir, потому что обрабатывать прерывания с такими сигналами должно быть быстрее.
Но в любом случае, если энкодер способен выдавать импульсы чаще, чем МК может обработать, бороться с этим отфильтровыванием запрещённых переходов — бесполезно. Потому что, допустим, вы откинули «запрещённый» переход и отловили легитимный переход. Откуда вы можете быть уверенными, что в интервале между двумя сэмплированиями от энкодера пришёл именно один переход? Может за это время там 3 или 10 переходных edge-в было? Ниоткуда. Поэтому фундаментально правильный подход это гарантированный оверсэмплинг, а не отбрасывание запрещённых переходов.
В оптическом энкодере да ещё и с интегрированным фронтендом (в котором наверняка есть триггеры Шмитта) такого быть не может.
Если у вас polling вместо event-based обработки сигналов, то при слишком медленном опросе и слишком быстром вращении вы можете пропустить оба фронта в интервале между двумя опросами. Но это не запрещённый переход, это, извините, выбранная вами частота опроса порта не соответствует максимально допустимой скорости вращения, определяемой техзаданием.
И в каком случае на оптическом энкодере будет получен сигнал с картинки 2?
И какие переходы у квадратурного энкодера запрещённые?
Я бы их всех разогнал: такого количества багов, как в YT, вряд ли где ещё найдешь в продуктах от таких гигантов.
И самая забагованная часть — это то, что появилось позже всего — шортсы. Если ранее сделанное еще как-то продолжает работать, то шортсы, такое впечатление, писали люди с желе вместо мозга.
В ряде случаев сбивается дискретность перелистывания роликов: отображается половина одного ролика и снизу половина следующего.
Если пролистывать ролики достаточно быстро, чуть быстрее, чем тупорылый код подгрузки и подмены ролика успевает отработать, то происходит рассинхронизация между самим видео и блоком комментариев: видео одно, а комментарии от следующего или предшествующего. Например, видео про сварку труб, а в комментариях все шлют проклятия какому-то наглому мотоциклисту.
Это буквально значит, если упростить, что когда детектируется необходимость смены ролика, вместо того, чтобы взять следующий элемент из цепочки id и подгрузить его:
В коде есть две отдельные независимые переменные, которые хранят id текущего ролика (или наше текущее положение в
очередицепочке айдишников) — одна используется для плеера, другая для комментариев. И когерентность между этими двумя переменными ничем не гарантируется, она зависит от фактора удачи, от того, в какой очерёдности произойдет ряд асинхронных событий. Т.е. это не просто нарушение принципа DRY, принципа, что должен быть один источник авторитетной информации, это ещё и кривой асинхронный код.Кстати, есть еще и рассинхронизация между адресной строкой (хвала тем, кто придумал переписывание адресной строки без перезагрузки страницы) плеером и комментами. Т.е. ситуация, когда копируешь URL и вставляешь в другой браузер, либо отправляешь кому-то, а там совсем другой ролик — иногда случается. Ролик, который откроется по ссылке, будет, естественно, не случайным — а тем, который был за 1, 2 позиции «перед» тем роликом, который на самом деле проигрывался в момент копирования адреса из адресной строки. Только вот цепочка шортсов каждый раз генерируется случайная, поэтому перелистнуть на соседний после перехода по такой ссылке уже не получится — нужный ролик уже не будет соседним.
Отдельная песня — скроллинг комментариев. Если мы скроллим комменты и внезапно упираемся в конец, событие скроллинга уходит уровнем выше и триггерит перелистывание ролика. А иногда даже не нужно упираться в конец перечня комментов: просто в рандомный момент порция проворачивания колёсика мыши вместо прокручивания комментов чуть-чуть вниз меняет текущий ролик на следующий.
На мобильной версии в ряде случаев оверлей с кнопками лайк/дислайк/комменты просто не появляется. У предыдущего ролика есть, у следующего есть, а у текущего — не отображаются. Можешь сколько угодно крутить ролики вперёд/назад — кнопки не появятся. И нет, это не настройки ролика в духе «запретить комментирование» или «отключить лайки» — если запомнить название ролика, закрыть приложение, открыть заново и найти ролик через поиск — всё у него будет на месте.
Кем надо быть, чтобы написать такой глючный продукт? Бомжей с улицы там что ли набрали?
И вы хотите, чтобы у меня была капля сожаления к тем, кого увольняют? Ни капли. Я зол, и мой гнев праведный, потому что нет оправдания такому кривому коду, особенно когда за ним стоит IT-гигант.
При этом если этот второй хост не будет выполнять для первого хоста роль основного шлюза, то есть не будет роутить и NATить IP-пакеты, то строго говоря это по прежнему будет VPN, но в таком виде услуга нафиг никому не будет нужна.
С другой стороны, если сервис не будет использовать технологию VPN, но каким либо иным образом будет обеспечивать доступ в интернет, то обыватель не поймёт разницы и не почувствует подвоха.
Вывод: под видом VPN продают услугу по проксированию трафика. Если из этой услуги убрать проксирование и оставить VPN, то услуга потеряет смысл. Если убрать VPN и оставить проксирование — никто ничего не заметит. То есть собственно VPN играет в услуге не критическую роль, а 10-ую роль. Но в качестве названия услуги выбирают слово «VPN».
Ну и опять же: смысл VPN что ты один свой хост связываешь с другим своим хостом, и таких хостов может быть произвольное количество. При этом Vиртуальность заключается в том, что для хостов создаётся иллюзия, что они находятся в одной сети (хотя на деле это не так — между ними есть промежуточное звено в виде глобальной сети), а Privатность — в том, что посредники не видят, чем там обмениваются хосты в виртуальной приватной сети, сколько их там и т.п. В общем случае виртуальная сеть может вообще не иметь маршрутизации во внешнюю публичную сеть и это по прежнему легитимный случай VPN. Никто не смеет назвать это каким-то неполноценным VPN.
Что мы имеем на другой чаше весов? Вырожденный случай, когда сеть состоит только из двух хостов, причем только один из них — наш . Добавить ещё один свой хост или несколько в ту же виртуальную сеть нельзя (а это чуть ли не главная фишка VPN). Виртуальность, то есть создание видимости того, будто два хоста соединены напрямую, тонда как фактически это не так — если и есть, то в этом use case'е (обход блокировок) это роли не играет. Приватности никакой нет — второй хост контролируется третьими лицами и он видит всё, что мы передаем. То это это вырожденный случай network (только один свой хост в сети), де-факто виртуальной (хотя никому нет дела), но ни разу не приватной, с главным акцентом на проксирование.