Естественно, мы люди бедные, мы будем нацеливаться повторить рентген-томограф из фекалий и древисины.
Интересующий моментов, естественно, много. У вас линейные (одномерные) детекторы или матричные (двумерные)? Полностью готовое изделие (детектор) ставите в своё устройство или сами производите?
Рентген-КТ неживых объектов сильно проще, потому что не нужны высокие скорости перемещения, высокие быстродействия опроса детектора, передачи и сохранения информации, не нужно беспокоиться и дозовой нагрузке (в большинстве случаев).
Но всё равно хватает технических сложностей. Охлаждение трубки/источника. Как у вас вопрос решён? И вообще, режим работы — импульсный или непрерывный?
Какую мощность в целом потребляет источник, учитывая, что у них смехотворные КПД?
Это всё-таки нишевый продукт. Для определённых стран, для определённых людей. Скажем, я не пользуюсь 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 (только один свой хост в сети), де-факто виртуальной (хотя никому нет дела), но ни разу не приватной, с главным акцентом на проксирование.
А кто говорил, что virtual private network должна обслуживать 5 хостов?
По определению, network — это когда хостов, которые вы объединили с целью обмена данными между ними, больше 1.
Иначе я могу говорить «моя могущественная корпорация», скрывая под этим одного лишь себя (ну а что, в моей корпорации всего один сотрудник — я сам).
Есть например, hamachi - там вами обьявленный функционал вполне себе имеется.
К Хамачи никаких претензий нет, он-то как раз по праву может и должен называться VPN.
Я могу взять 3—5—10—50 компьютеров в разных точках земного шара и с помощью Hamachi сделать для них видимость того, будто они находятся в одной локальной сети, словно они стоят в одном офисе, в одном здании. Я могу слать anycast-пакеты и делать прочие вещи, которые можно делать в локальной сети.
Хамачи именно что виртуализирует, т.е. создаёт для хостов полное ощущение, что они соединены физическим линком, при этом эта сеть частная, изолированная от других.
В последнее время говорят в основном про последнее, ибо понятно, почему и зачем. И никому там собственно "виртуальная" сеть не нужна. Им надо чтобы сайты открывались
Так и ради бога, только не называйте это VPN. Называйте это проксирование, туннелирование, PPP-туннелями.
Иначе в отдельно взятой стране вводят запреты на рекламу VPN, и в итоге под раздачу попала технология, которая вообще не про это.
Всю жизнь, если ты хотел скрыть свой IP или обойти блокировки, были прокси-серверы. Обычно это были HTTP proxy, Socks proxy. Но в принципе проксирование возможно и на более низких уровнях модели OSI.
В какой момент и какой заразе пришла в голову идея сервис по предоставлению заграничного прокси называть VPN-сервисом?
Это как мошеннические звонки взять и начать обзывать термином «мини-АТС» и доиграться до запрета мини-АТС как класса технических устройств. И даже если мошенники реально используют мини-АТС в своей внутренней кухне, это не причина ассоциировать в головах широких масс людей понятие «мини-АТС» с мошенническими звонками и доводить до запрета мини-АТСок вследствие обретения такой дурной славы.
Потому что мини-АТС вообще не для этого придуманы и производятся. Он. Вообще не про это.
Термин VPN сейчас знают все, кому не лень. От детей до пенсионеров. Его знают те, кто в норме не должен знать этот термин. Я, конечно, за рост технической грамотности и желал бы, чтобы как можно больше людей знали про VPN, но тогда они наравне с этим должны знать, что такое VLAN, NAT и т.п. А они не знают этого, но VPN знают, и в головах тех, кто в норме вообще не должен был знать этого термина, VPN — это что-то связанное с обходом блокировок, а вовсе не то, чем технология является на самом деле.
Что еще хуже: практически ничего из того, что отличает VPN от других механизмов, для обхода блокировок не нужно и не используется.
В итоге ненужная шумиха вокруг технологии привела к запрету нейтральной технологии.
Хотя, даже если бы ни было никакой истории с запретами, мой поинт остался таким же.
Другая вещь, которая получила такую же дурную славу и стала известна тем, кому и не следовало бы о ней знать — понятие ASIC. Это понятие должно было бы оставаться в поле деятельности тех, кто проектирует интегральные схемы. Ну, ладно, таких небожителей мало — в поле деятельности тех, кто проектирует платы, используя интегральные схемы.
Нет же, теперь от разных проходимцев, жаждущих легких денег, которые не смогут выговорить слово «транзистор», я слышу в свой адрес вопросы «знаешь ли ты, что такое ASIC? А сможешь сделать ASIC?». Я-то знаю...А вот вы неправильно знаете.
Но можно ли продолжать называть технологию названием «VPN» если она потеряла саму свою суть и, скажем, в мобильных приложениях, позиционирующих себя как VPN, в принципе нет возможности создать свою private сеть, скажем, с 5 хостами, самостоятельно назначив им IP-адреса в этой сети и т.п.?
VPN это по определению про many-to-many relationship между хостами. В сегодняшних реалиях на один условный OpenVPN приходится тысячи приложений и сервисов, которые позиционируют себя как VPN, но на самом деле предоставляют только услугу проксирования трафика. Используют ли они под капотом VPN-овские протоколы (если такая постановка вопроса вообще корректна, ведь сама идея VPN не заставляет вас использовать под капотом какой-то конкретный протокол — вы можете изобрести собственный), большой вопрос.
Еще тема для размышлений: почему банальное проксирование трафика стали называть VPN, и какого лешего все используют этот термин, если у большинства пользователей нет ни цели создавать именно network (с количеством хостов больше 1), ни, как оказывается — возможности.
Это всё звучит хорошо на Хабре. Это всё оборачивается нервяком в реальной жизни. При большом желании и огромном финансировании можно и в космос полететь. Однако мой посыл в том, насколько производители изделий усложняют жизнь: раньше открутил 4 винтика, поменял стекло на заранее сделанное, закрутил 4 винтика. А сейчас изгаляться, придумывая способы матирования, способы приклеивания, способы изготовления рамок.
Самое простое решение - наверное взять на фонаре, который собираемся ставить, и нанести риску наждачной бумагой наверное P600 или P400 шлифмашинкой или просто вручную
Удачи потом вернуть этот фонарь по гарантии, если что с ним случится.
Неужели нет способа достать с той же лестницы 3-4 метра(страховочное снаряжение желательно)
Работа электроинструментом с приставных лестниц запрещена правилами ТБ. Но отдельно хочется спросить: к чему вы собираетесь пристёгиваться страховочной привязью. Вот в люльке вышки я пристёгиваюсь к поручням или к специально предназначенным для этого проушинам. А на лестнице к чему? К самой лестнице? Чтобы веселей вниз лететь было вместе с лестницей?
Естественно, мы люди бедные, мы будем нацеливаться повторить рентген-томограф из фекалий и древисины.
Интересующий моментов, естественно, много. У вас линейные (одномерные) детекторы или матричные (двумерные)? Полностью готовое изделие (детектор) ставите в своё устройство или сами производите?
Рентген-КТ неживых объектов сильно проще, потому что не нужны высокие скорости перемещения, высокие быстродействия опроса детектора, передачи и сохранения информации, не нужно беспокоиться и дозовой нагрузке (в большинстве случаев).
Но всё равно хватает технических сложностей. Охлаждение трубки/источника. Как у вас вопрос решён? И вообще, режим работы — импульсный или непрерывный?
Какую мощность в целом потребляет источник, учитывая, что у них смехотворные КПД?
Хорошая стать для сайта, где сидят люди, балдеющие по археологии.
Но для Хабра хотелось бы совсем другого: разбор томографа, его конструкции, какая трубка, какой сенсор, параметры среза, напряжение трубки.
Самодельный или серийный, на чем выполняется реконструкция и т.п.
Это всё-таки нишевый продукт. Для определённых стран, для определённых людей. Скажем, я не пользуюсь 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 (только один свой хост в сети), де-факто виртуальной (хотя никому нет дела), но ни разу не приватной, с главным акцентом на проксирование.
По определению, network — это когда хостов, которые вы объединили с целью обмена данными между ними, больше 1.
Иначе я могу говорить «моя могущественная корпорация», скрывая под этим одного лишь себя (ну а что, в моей корпорации всего один сотрудник — я сам).
К Хамачи никаких претензий нет, он-то как раз по праву может и должен называться VPN.
Я могу взять 3—5—10—50 компьютеров в разных точках земного шара и с помощью Hamachi сделать для них видимость того, будто они находятся в одной локальной сети, словно они стоят в одном офисе, в одном здании. Я могу слать anycast-пакеты и делать прочие вещи, которые можно делать в локальной сети.
Хамачи именно что виртуализирует, т.е. создаёт для хостов полное ощущение, что они соединены физическим линком, при этом эта сеть частная, изолированная от других.
Так и ради бога, только не называйте это VPN. Называйте это проксирование, туннелирование, PPP-туннелями.
Иначе в отдельно взятой стране вводят запреты на рекламу VPN, и в итоге под раздачу попала технология, которая вообще не про это.
Всю жизнь, если ты хотел скрыть свой IP или обойти блокировки, были прокси-серверы. Обычно это были HTTP proxy, Socks proxy. Но в принципе проксирование возможно и на более низких уровнях модели OSI.
В какой момент и какой заразе пришла в голову идея сервис по предоставлению заграничного прокси называть VPN-сервисом?
Это как мошеннические звонки взять и начать обзывать термином «мини-АТС» и доиграться до запрета мини-АТС как класса технических устройств. И даже если мошенники реально используют мини-АТС в своей внутренней кухне, это не причина ассоциировать в головах широких масс людей понятие «мини-АТС» с мошенническими звонками и доводить до запрета мини-АТСок вследствие обретения такой дурной славы.
Потому что мини-АТС вообще не для этого придуманы и производятся. Он. Вообще не про это.
Термин VPN сейчас знают все, кому не лень. От детей до пенсионеров. Его знают те, кто в норме не должен знать этот термин. Я, конечно, за рост технической грамотности и желал бы, чтобы как можно больше людей знали про VPN, но тогда они наравне с этим должны знать, что такое VLAN, NAT и т.п. А они не знают этого, но VPN знают, и в головах тех, кто в норме вообще не должен был знать этого термина, VPN — это что-то связанное с обходом блокировок, а вовсе не то, чем технология является на самом деле.
Что еще хуже: практически ничего из того, что отличает VPN от других механизмов, для обхода блокировок не нужно и не используется.
В итоге ненужная шумиха вокруг технологии привела к запрету нейтральной технологии.
Хотя, даже если бы ни было никакой истории с запретами, мой поинт остался таким же.
Другая вещь, которая получила такую же дурную славу и стала известна тем, кому и не следовало бы о ней знать — понятие ASIC. Это понятие должно было бы оставаться в поле деятельности тех, кто проектирует интегральные схемы. Ну, ладно, таких небожителей мало — в поле деятельности тех, кто проектирует платы, используя интегральные схемы.
Нет же, теперь от разных проходимцев, жаждущих легких денег, которые не смогут выговорить слово «транзистор», я слышу в свой адрес вопросы «знаешь ли ты, что такое ASIC? А сможешь сделать ASIC?». Я-то знаю... А вот вы неправильно знаете.
Это не противоречит моим словам.
Но можно ли продолжать называть технологию названием «VPN» если она потеряла саму свою суть и, скажем, в мобильных приложениях, позиционирующих себя как VPN, в принципе нет возможности создать свою private сеть, скажем, с 5 хостами, самостоятельно назначив им IP-адреса в этой сети и т.п.?
VPN это по определению про many-to-many relationship между хостами. В сегодняшних реалиях на один условный OpenVPN приходится тысячи приложений и сервисов, которые позиционируют себя как VPN, но на самом деле предоставляют только услугу проксирования трафика. Используют ли они под капотом VPN-овские протоколы (если такая постановка вопроса вообще корректна, ведь сама идея VPN не заставляет вас использовать под капотом какой-то конкретный протокол — вы можете изобрести собственный), большой вопрос.
Еще тема для размышлений: почему банальное проксирование трафика стали называть VPN, и какого лешего все используют этот термин, если у большинства пользователей нет ни цели создавать именно network (с количеством хостов больше 1), ни, как оказывается — возможности.
Кто-то строит марсоход.
Кто-то ищет лекарство от рака.
А кто-то делает генератор информационного мусора.
Базово это зависит не от тактовой частоты, а от крутизны фронта.
Статью нейросеть писала?
Это всё звучит хорошо на Хабре. Это всё оборачивается нервяком в реальной жизни. При большом желании и огромном финансировании можно и в космос полететь. Однако мой посыл в том, насколько производители изделий усложняют жизнь: раньше открутил 4 винтика, поменял стекло на заранее сделанное, закрутил 4 винтика. А сейчас изгаляться, придумывая способы матирования, способы приклеивания, способы изготовления рамок.
Удачи потом вернуть этот фонарь по гарантии, если что с ним случится.
Работа электроинструментом с приставных лестниц запрещена правилами ТБ. Но отдельно хочется спросить: к чему вы собираетесь пристёгиваться страховочной привязью. Вот в люльке вышки я пристёгиваюсь к поручням или к специально предназначенным для этого проушинам. А на лестнице к чему? К самой лестнице? Чтобы веселей вниз лететь было вместе с лестницей?