Мы используем файлы cookie и сервисы аналитики. Ознакомьтесь с нашей Политикой сбора данных и выберите, какие типы cookie вы разрешаете:
cookie_policy_accepted — хранит ваш выбор cookiePHPSESSID — сессияkey3 — запоминание входа_ix — единая сессия входа на ixbt.comadminuserskey — вход администратораtopic_add_autosave — автосохранение черновикаls_photoset_target_tmp — временные данные загрузки фотоgeo_country — определяет ваш регион_ga, _ga_*, _ym_uid, _ym_d, _ym_* — статистика посещений__gads, __gpi — таргетирование объявленийВы всегда можете изменить свои предпочтения в настройках.
Ответ 112936154951569893631@google на комментарий
Потому что нельзя украсть то, на что не может быть собственности. Патенты охраняют реализацию, а не идею. Не что можно сделать, а как это сделать. Ответ, а не вопрос.
Если ваш сосед изобрел автомобиль, вы можете посмотреть на то, как он катается, и сделать себе такой же. Если вы скопируете чертежи соседа, вы нарушите закон. А если вы сами придумаете, как сделать ДВС, и у вас получится оригинальная отличная от соседской конструкция — к вам претензий не будет. Точно так же, если вы посмотрите на оконный или сенсорный интерфейс и сами придумаете, как такое запрограммировать, не видя кода Apple, к вам никто не придерется.
И Apple тоже никому не платила за идею сделать мобильный телефон, и за идею встроить в него камеру, и за идею сделать в нем браузер — хотя это кто-то уже делал раньше. За конкретные использованные чужие технические решения — платила. А за концептуальные идеи «неплохо бы сделать то или это» — нет.
Так что да, это нормально.
Ответ vasyapupkin835 на комментарий
Гугл не чинит никаких препятствий тому, чтобы пользователи Айфонов ставили на них Андроид вместо iOS :D Более того, и не может этому препятствовать, поскольку Андроид вообще Free :)
Не уверен, что технически возможно поставить на Айфон Андроид (хотя вроде совсем недавно в новостях что-то такое мелькало), но это не Гугл виноват.
Ответ Lambert на комментарий
К сожалению, так и есть. Метод конкуренции Apple — не улучшать свои продукты, а делать подножки конкурентам. В частности, путем превращения популярных продуктов в свои эксклюзивы. Создать свой эксклюзив — вполне честный прием, а вот купить продукт, который делался для всех, и превратить в эксклюзив, чтобы навредить пользователям конкурентов — грязный трюк. Но так было с Siri (которая проектировалась как кроссплатформенная, но была выкуплена; в результате остальному миру пришлось тратить ресурсы на создание альтернатив, а выкупленная Сири в Apple в итоге захирела и уступила этим альтернативам), так, вполне возможно, скоро будет с Shazam, и вот теперь новый пример.
Ответ Lambert на комментарий
Гугл и своих проектов немало закрывает. Поскольку поддерживает эксперименты и научный поиск, финансируя в проекты с неопределенными перспективами. И, разумеется, весьма часто эти проекты в итоге проваливаются. Но, тем не менее, такая поддержка исследований приносит обществу намного больше пользы, чем консервативные инвестиции в гарантированный результат. Потому, собственно, корпорация добра таковой и является.
Но речь не об этом, я повторю вопрос: приведите пример проекта, который Гугл выкупил, чтобы сделать эксклюзивом, отключив для пользователей iOS.
Ну и в свете того, что отсекается 80% рынка в пользу 15%, читать про «помочь как можно большему числу людей» особенно мерзко.
Честно говоря, создается впечатление, что это не «поддержка партнера в трудную минуту», а «кредитор в счет долга начинает отбирать у должника средства производства».
Ответ pcHelp на комментарий
Дальше началась очень неудобная лента вместо меню+тулбар, после чего я перешел на Libre.
Ответ AlexVR на комментарий
А у магистрального роутера на границе стран вполне может быть йоттатриллион с одной стороны и йоттатриллион с другой. И триллионы потоков, идущих через него одновременно из одной половины в другую. И вы предлагаете ему запоминать все эти сессии, чтобы для всех пакетов помнить, какие куда направлять?
Да, где-то на границах паутины, когда информация уже направляется к конкретным абонентам, можно было бы урезать адреса. Но это означало бы переменный формат пакета — что, скорее всего, сильно усложнило бы обработку, увеличило нагрузку на магистральные маршрутизаторы, да и ошибок добавило. Кроме того, форматы с переменной длиной адреса обычно УВЕЛИЧИВАЮТ длину для адресов максимальной длины.
Что, по-моему, можно было бы убрать — это обратный адрес. Скажем, при установлении соединения клиент сообщает серверу свой обратный адрес, и они договариваются об идентификаторе сессии (в котором можно всего 16 бит оставить — все равно, по-моему, нельзя открыть больше TCP сессий на один порт). И дальше в пакетах идет только адрес получателя и этот идентификатор, и сервер уже запоминает своих клиентов и знает, на какие адреса им отвечать по данному идентификатору. Не маршрутизаторы запоминают весь трафик через них, что нереально, а только сервер и клиент при установления соединения запоминают адреса друг друга. Маршрутизатору ведь по дороге обратный адрес не нужен, ему надо в один конец доставлять пакеты, обратный адрес нужен только в конце цепочки серверу для ответа.
Да, я знаю, обратный адрес нужен для того, чтобы на него отправлять сообщения об ошибках. Но вполне можно сделать так: перенести обратный адрес в опциональный подзаголовок. Обычные пакеты идут без обратного адреса, и в случае ошибок просто дропаются; если клиент видит, что его пакеты теряются, он посылает служебный PING с подзаголовком обратного адреса, и на него ему уже присылают диагностику. Ну и в пакетах установления соеднинения подзаголовок обратного адреса указывается. А в основном обмене вместо него идентификатор сессии.
Вот это, по-моему, можно было бы сделать, но других жизнеспособных путей сокращения заголовков я не вижу.
Ответ AlexVR на комментарий
Ответ AlexVR на комментарий
Я еще раз все обдумал и разложил по полочкам. И ключевое разделение проходит вот где: есть локальные сети и есть глобальные.
В локальных сетях абонентов мало, все видят друг друга непосредственно и маршрутизация не нужна. Поэтому там и используют небольшие пакеты с короткими адресами, которые идут напрямую получателю. И это не с WPAN/WBAN началось, а задолго до того, еще в проводных соединениях. Скажем, USB использует семибитные адреса, допуская до 127 устройств (по крайней мере, до второй версии, на более поздние я детально спецификацию не изучал). I2C тоже использовала семибитные адреса, позже было введено расширение до десятибитных. Это вот то, что мне сходу вспомнилось.
А вот в глобальных сетях вам нужна единая адресация по всему миру — соответственно, неизбежна большая разрядность адреса — и маршрутизация, и здесь я не вижу особых альтернатив IPv6. Да, заголовок составляет 40 байт, но из них 32 байта — адреса. Что вы предлагаете урезать? Уменьшить разрядность адреса — риск через несколько лет попасть в ту же ловушку нехватки адресов, с которой мы столкнулись с IPv4. А остальные поля всего 20% заголовка составляют, и на них много не сэкономить. Да и, скажем, поле длины тоже необходимо. Как раз в заголовке IPv4 было больше спорных полей, а в IPv6 многое почистили или перенесли в опциональные «подзаголовки» .
Если использовать для идентификации абонентов что-то еще — публичные ключи, как вы предлагали — то, скорее всего, их длина выйдет даже больше (или же количество потенциально адресуемых устройств выйдет намного меньше). И получается, что идентифицировать абонента можно чем угодно, но дальше как раз для уменьшения оверхеда лучше транслировать адрес в единую систему IPv6, и к каждому пакету уже приписывать именно его, используя для доставки.
И ответ на ваш вопрос про «единый протокол» получается такой. Для глобальных сетей IPv6 или его аналог — но, опять же, с большими адресами и вытекающими отсюда большими заголовками, и роутингом — неизбежен. А для локальной сети можно либо использовать его же и терпеть оверхед, либо сделать альтернативный с короткими адресами, потеряв единство.
Ну и в результате мы логически приходим к тем решениям, которые сейчас и реализованы.
Ответ Druid34 на комментарий
Спасибо, стараюсь :)
Ответ 110034068225937681114@google на комментарий
И вопроса нет. Разумеется, клавиатура самое то. Двухэкранные устройства все равно не взлетели, поскольку два экрана визуально в один не объединяются, не получается сделать без видимой линии раздела, а контента, ориентированного на два мобильных экрана, нет. Это устройство для тех, кому нужна физическая клавиатура, если не нужна — лучше брать простое одноэкранное устройство.
Пока не довели до ума (и незаградительной цены) раскладушки с единым гибким экраном.
Ответ yat345 на комментарий
Да, зачем в ноутбуке порты, можно разветвители с собой возить. Зачем в ноутбуке накопитель, можно внешние диски с собой возить. Зачем в ноутбуке клавиатура, можно клавиатуру с собой возить. Зачем в ноутбуке экран, можно монитор с собой возить...
Можно, все можно. Только идея ноутбука именно в том, чтобы быть самодостаточным и интегрировать разумный объем необходимой периферии, чтобы не возить с собой конструктор. И вот один разъем — это уже НЕ разумный объем.
Но при этом Tor тоже работает через маршрутизацию. Идентифицировать сервер можно как угодно — публичными ключами, текстовыми URL'ами или как-то еще, но потом все равно надо определить, через какие промежуточные узлы всемирной сети доставить туда пакет. И поэтому Tor работает поверх IP, но, насколько я понимаю функционирование Тора, добавляет прохождение пакетов через дополнительные гейты для сокрытия источника и получателя.
Кроме того, в новости говорится, что китайцы в свой протокол, наоборот, закладывают возможности для усиления контроля властей над трафиком. Вряд ли они будут делать поддержку анонимности.
Вот «местные» сети — когда абоненты напрямую видят друг друга без необходимости маршрутизации — да, в IP не нуждаются. И поэтому Bluetooth гарнитура общается с телефоном без IP. А вот когда вы по Блютусу подключаете телефон к ноутбуку как сотовый модем и выходите через него в сеть, через Блютус идут IP-пакеты.
Но в целом это еще одна сторона той же модели OSI — если вам не нужны сервисы, предоставляемые конкретным уровнем, вы можете спуститься ниже и использовать нижележащий слой. Не нужен для местной связи сетевой уровень (отвечающий за маршрутизацию для дальних расстояний) — не используйте и работайте ниже IP. Мышка по USB тоже без маршрутизации подключается.
Но глобальная связь без маршрутизации не обойдется, и это совсем не «костыль из 70х». Заявлять так — все равно что сказать, что «кому нужны эти костыли из 70х самолеты. я к другу в соседний подъезд пешком хожу». Тут дело не в устарелости технологий, а в том, что для простых задач они не нужны.
С другой стороны, есть и тренд на то, чтобы даже с мышкой по USB через IP связываться. Именно для удобства единообразий — проще всегда использовать один протокол, который универсален и в который заложена маршрутизация для тех случаев, когда нужно, чем менять протоколы в зависимости от ситуации.
А светофоры — это вообще отдельный вопрос. Там проблема в том, что у существующих физических уровней слишком долгий handshake. Машина, проносящаяся мимо базовых станций с радиусом в сотню метров на скорости 100 км/час не будет успевать их «цеплять» по тем же WiFi или Bluetooth. Но это претензия не к среднему уровню, а к нижнему, и это вообще другой вопрос.
Ответ AlexVR на комментарий
Мешам точно так же нужна маршрутизация. WPAN-ам/WBAN-ам не нужна, но по ним точно так же можно гонять IP-пакеты, без маршрутизации, как в Интранете. Еще раз: в том и удобство, что можно независимо развивать слои ниже и слои выше, а на среднем оставлять одну и ту же абстракцию адресуемого пакета.
Ответ AlexVR на комментарий
Совершенно верно, но их совсем не зря уложили на разные уровни. Не вдаваясь в нюансы семиуровневой модели, есть:
* нижние уровни — физические (провод — Ethernet, радио — WiFi, оптика и так далее)
* средние, которые абстрагируются от нижних уровней, обертывая их в универсальную концепцию «пакета», который может доставляться по любой физической среде, плюс обеспечивают глобальную адресацию, маршрутизацию, надежность и так далее
* верхние, которые уже наделяют передаваемые данные конкретным содержанием
И название NewIP предполагает, что протокол целится на средние уровни, где его конкурентами, в общем-то, только IPv4 либо IPv6 и являются. Либо, уровнем выше (тоже в рамках средних), TCP, UDP или ряд служебных (ICMP, ARP, и т.д.) А вы смешали все в кучу и атакуете как раз то, что и является самым разумным в современной архитектуре.
Ответ AlexVR на комментарий
Зачем? HTTP годится далеко не для всех задач. В том и смысл многоуровневой модели, что ОС предоставляет приложениям универсальный сервис «доставка данных» (TCP/UDP), а приложения могут передавать по ним HTTP или что-то еще. Если жестко зашить в средний уровень HTTP, для множества приложений среда станет кривой и неудобной, придется городить костыли, чтобы на базе построенного по схеме запрос-ответ HTTP реализовать, например, постоянный риалтаймовый обмен (это вся голосовая и видеосвязь, это компьютерные игры, это удаленные рабочие столы и т.д.)
В том и разумность современной архитектуры, что сеть предоставляет УНИВЕРСАЛЬНУЮ среду доставки любых данных, а приложения поверх нее задействуют свои прикладные протоколы — которых огромное множество, они совершенствуются и создаются новые — и нет необходимости каждый раз переделывать встроенный в ОС сетевой стек или перестраивать глобальную инфраструктуру.
Ответ AlexVR на комментарий
А это, наоборот, нижний уровень. Физический слой, по которому можно гонять IP-пакеты так же, как по Эзернету, Вайфаю и т.д. И разделить верхние и нижние уровни средним слоем универсальных абстракций — очень разумно. Кстати, не только в сетевых протоколах.
Ответ AlexVR на комментарий
А это вообще чушь. Как вы предлагаете жить без «роутинга», тянуть от вас отдельный кабель к каждому серверу?
Люди это все еще на примере почты поняли. Когда-то, когда нужно было послать сообщение, отправляли отдельного гонца или почтового голубя напрямую от отправителя к адресату. Каждое письмо везли отдельно. А потом изобрели централизованную почту, вся корреспонденция, допустим, из Европы в Америку собирается в мешки, везется через океан, там развозится по разным городам и там уже доставляется адресатам. Благодаря системе адресации и роутинга. И умные люди, делавшие сети, это прекрасно понимали. Поэтому вместо отдельных кабелей «от каждого к каждому» имеется сеть. Ну а любой пакет проходит эту сеть по своему маршруту.
Ответ lMariusl на комментарий
Средство вложения денег — предприятия, недвижимость или драгоценности, использовать для этой цели машину глупо, поскольку стоящая сгниет, а бегающая износится. Феррари — именно дорогая игрушка для тех, кому хочется погонять на спортивной машине, ощутить скорость, и кто при этом может себе это позволить. И флагманские смартфоны — такие же дорогие игрушки, если нужно просто средство связи — флагман брать совсем необязательно.
И потом, к любому другому рынку это относится в той же степени. Экстремальные процессоры за тысячу долларов, сверхтоповые видеокарты за пару тысяч или стодюймовые телевизоры тоже никогда не составляли заметный процент продаж в общей массе — и не рассчитывались на это.
Что значит «напрямую»? Без маршрутизации, непосредственно от каждого устройства к каждому предлагают кабель тянуть?
А с маршрутизацией и так любое устройство в Интернете любому может IP пакет послать, разве нет? Могут быть проблемы из-за NAT и нескольких устройств с одним адресом, но это костыль из-за ограничений адресации IP v4. Эти проблемы уже решены в рамках IP v6, надо только окончательно повсюду внедрить.
Поэтому я вообще не понял, что и зачем предлагают китайцы.
Ответ 19516217@vkontakte на комментарий
Нормальный телефон можно купить в разы дешевле. В зависимости от задач, соответствующий им аппарат можно взять за 20, за 10, а то и за 5 тыс, если только звонилка нужна.
По моим представлениям, в штаб квартире сидит менеджмент, который издает распоряжения, прочие административные службы (бухгалтерия, например), и, видимо, программисты тоже там. Не вижу, зачем к кому-то из них ходить посетителям. И не вижу, зачем кому-то из них вообще находиться в штаб-квартире и зачем вообще ее открывать. Заводы без рабочих не могут, а все, кто в штаб-квартире работают, могут работать из дома. ИМХО.