Category: техника

Category was added automatically. Read all entries about "техника".

404

высокофилософское, админское

Очень огорчает, когда инструмент вместо механизма подсовывает кусок полиси. Кому-то когда-то казалось, что это полиси разумно и правильно, а теперь оно выглядит как произвольная 0x00007u и «не пущу».

404

(no subject)

Если я вычисляю arcsin на телефоне для оценки среднего угла наклона маршрута в навигаторе, я типичный пользователь телефона или нет?
404

Сегодня я узнал чудное

Множество современной электроники работает на механических маятниках. Маленьких маятниках, конечно, но всё-таки механических.

https://en.wikipedia.org/wiki/Microelectromechanical_system_oscillator

Так что, возможно, рассказы про solid state devices без mechanical parts - это неким образом неправда. Внутри там нечто трясётся на сотнях килогерц или даде мегагерцах.

По мотивам вот этой статьи: https://arstechnica.com/gadgets/2018/10/helium-implicated-in-weird-iphone-malfunctions/
404

Наблюдение

Европейская бытовая техника в РФ стоит меньше, чем в Европе (поправка, на Кипре). Не сильно меньше, но меньше - процентов на 5-7%. НДС и таможенные сборы с лихвой перекрываются конкурентным высокооборотистым рынком и отлаженной логистикой.
404

grace arp

А вот такой у меня вопрос. Если у нас на линуксах на какой-то интерфейс взгромоздили ip-адрес, то если линуксу в этой сети ничего от жизни не надо, то он и слать ничего не будет, правильно? Никаких grace arp, neighbor solicitation, etc?

Т.е. если раньше этот arp был заполнен на одном сервере, и тот ушёл резко в даун, то подъём на новом месте этого адреса как secondary или на потрошках внутренних бриджей, без "специального пинга" до маршрутизатора никак не дойдёт, правильно?

И как с этим жить?

UPD: arp_notify не работает на уже поднятых интерфейсах.

https://bugs.launchpad.net/neutron/+bug/1672433
404

Алгоритм построения перспективы

(ниже мои наивные рассуждения, которые могут быть в корне неверны).

Итак, первая вещь, которую надо сделать, это определить горизонт. Если выпрямиться и смотреть прямо перед собой, то в условиях земной гравитации, линия горизонта проходит строго посреди взгляда.

Следующая - определить "окно" изображения (положение кадра) относительно горизонта. В моём случае коробка лежит передо мной снизу, а кадр почти на полную свою высоту ниже горизонта.

Выглядит это так:



Так как кадр ниже горизонта, то перспектива будет направлена "вверх", т.к. точки схождения двухточечной перспективы всегда на горизонте.

Следующий вопрос: как соотносится расстояние между точками на горизонте с размером кадра и его "высотой" до горизонта?

Вероятнее всего, оно зависит от расстояния и фокусного расстояния линзы. Так же интуитивно понятно, что при нормальных условиях (пейзажный рисунок) надо рисовать с экивалентом полтинника, то есть 120 градусов FOV'а.

Вероятнее всего, правильный метод определения расположения двух точек перспективы - это измерение крайних размерностей изображаемого объекта, точнее, их углового размера. Но как это сделать?

Начнём с радикального. Пусть мы хотим нарисовать что-то очень в отдалении от нас, например, гигантский сарай вдалеке, экивалент 500-700мм фокусного расстояния. В этом случае у нас в кадр будет попадать почти ничего. И наши точки перспективы (относительно кадра) будут ну очень очень очень далеко. понять это очень легко: если мы "зумим" картинку, то мы из неё вырезаем кусочек в середине. При условии, что горизонт и точки перспективы не меняются, у нас (относительно вырезанного кусочка) расстояние до точек схождения перспективы, измеряемое в процентах размера кадра (то есть вырезанного кусочка), оказывается сильно больше.

Вот пример:


(извините за порванные ленты, так положено)

Рассмотрим другой экстримальный вариант:



Любому человеку фотографу понятно, что такое получается от широкоугольного объектива. Более того, вполне понятно, что масштаб искажений будет усиливаться по мере отдаления от горизонта. Чем ниже (на холсте) находится объект относительно горизонта, тем больше геометрические искажения.

Из всего этого я пока что для себя всё равно не определил, как правильно выставлять точки проекции, но кое-что в происходящем я таки понял.

Впрочем, можно сказать ещё одну интересную вещь, сравнивая кубики. На втором рисунке возникает ощущение, что кубик

а) большой
б) находится у нас почти под ногами.

А вот на первом рисунке как раз ощущение, что он вдалеке, и не очень ниже взгляда зрителя.

Таким образом, выбор варианта (первый или второй), в утрированном виде, определяется расстоянием и высотой (глубиной) до объекта. Чем объект ниже (в физическом смысле), тем больше он ближе к версии 2. Чем он больше и дальше (к горизонту) - тем ближе он к версии 1.

Таким образом, если мы говорим про коробку перед глазами, то нам не подходит ни один из вариантов - коробка не настолько ниже горизонта (2), но и она не настолько далеко от нас (1).

tbc
404

робот-пылесос

Он (xDevice xBot-1) меня всем устраивал, но у него обнаружилась проблема - через 5-10 дней эксплуатации начинался жуткий болгарочный визг. Это не проблема экземпляра, я один уже сдал. Второй начал делать так же чуть позже, но тоже начал. Насколько я понимаю, там вентилятор за что-то цепляется.

Сегодня поеду сдавать обратно; вероятнее всего возьму iRobot/scuba. Он примерно в два раза дороже (всё, что ниже их в прайсе почти 1-в-1 как этот самый xBot, так что, думаю, эта проблема у всех может проявиться), заодно хочется оценить как именно он будет мыть.
404

UDP tunnel over dual side NAT

Построение туннеля между двумя узлами, каждый из которых за ортодоксальным NAT'ом без каких-либо манипуляций с натом. Полагается, что пропускается наружу всё (как в обычной домонетке).

http://samy.pl/pwnat/

via habrahabr.

Что-то серьёзное и интересное.


Как оно работает? Сервер (с серым адресом за NAT'ом) пингует узел 3.3.3.3 (хз почему этот адрес) с увеличивающимся TTL, т.е., грубо говоря, делает trace. увеличение TTL прекращается, как только мы вышли за пределы NAT'а (т.е. нам начали отвечать с белых адресов).

stateful nat открывает пересылку ICMP о происходящем серверу.

Далее, клиент притворяется "маршрутизатором" и отсылает "серверу" сообщение ICMP о недоступности 3.3.3.3 на его белый адрес. Наружу клиента выпустят, а NAT сервера считает, что присланный ICMP - ответ от маршрутизатора и пропускает его. Таким образом, мы имеем возможность обратиться к серверу ЗА натом от клиента, который тоже ЗА NAT'ом. Т.к. мы перестали увеличивать TTL, мы знаем, что все приходящие ICMP, кроме как с ближайшего хопа за NAT'ом - это сообщения от клиента. Эта техника используется только для получения белого адреса NAT'а клиента.

Теперь про передачу трафика. Она организуется очень просто: Если клиент отправляет UDP-пакет на указанный адрес и порт [dst address+port], а потом на NAT приходит пакет c dst=src, то это полагается ответом на UDP-запрос, и ответ отдаётся отправителю. Если обе стороны проделают этот трюк, с использованием согласованных номеров портов и зная IP друг друга (см выше), то UDP-датаграммы будут ходить между ними СКВОЗЬ NAT.

Всё дальнейшее, надеюсь, понятно из рисунка (если у кого-то рисунок показывается не целиком, http://desunote.ru/pub/pwnat_udp_tun.png).



PS Дайте инвайт на хабр!
404

Регламент обслуживания серверной

Написал примерный регламент обслуживания:

Уборка
Уборка (штатная) - раз в две недели.
Протирка пыли с оборудования - раз в месяц
Чистка шкафов - раз в год [май 2009]

Кондиционер
Промывка фильтра - раз в два месяца[февраль 2009]
Профилактический осмотр кондиционера - два раза в год, апрель и сентябрь. [сентябрь 2009]

Активное оборудование - Удаление пыли
"серверные" - раз в пол-года [апрель 2009]
"десктопные" - раз в год [апрель 2009]

Замена систем охлаждения
Кулеры в "серверных" серверах - раз в три года[июнь 2009]
Кулеры в десктопных серверах - не регламентировано[июнь 2009]
Коммутаторы/маршрутизаторы - раз в три года[август 2010]

Проверка оборудования
Критические рейды - раз в год [август 2009]
Бэкап сервер - раз в пол-года [февраль 2009]
Некритические рейды, прочие винты - раз в два года [октябрь 2009]
Проверка памяти серверов (ночной проход мемтеста), раз в пол-года [январь 2009]
Аккумуляторы
Замена аккумуляторов в стоечных УПСах - раз в три года. [лето 2010]
Замена аккумуляторов камер видео-наблюдения - раз в пять лет (?)[2012]

СКС
Проверка правильности таблицы коммутации и сохранности маркировки шнуров - раз в два года [июль 2009]



... теперь думаю, как его выполнять...
404

Компьютерные сети - простейшие основы принципов работы (часть 10)

В прошлом уроке мы разобрались как именно пакеты превращаются в кадры, и как осуществляется маршрутизация в "свои" сегменты (в которых маршрутизатор имеет порты и адреса). Чуть раньше мы выяснили, как обрабатывается таблица маршрутизации.

Сегодня мы сфокусируемся на "локальной" маршрутизации.

Локальная маршрутизация - это последний (в некоторых случаях он же и первый) прыжок между сегментами сети. ("Прыжок" - это не жаргон, это вполне себе офицальный термин - hop). При этом маршрутизатор обнаруживает, что адрес получателя, если к нему применить маску какого-то из своих интерфейсов, совпадает с номером сети этого интерфейса. Он отправляет пакет в качестве содержимого кадра. К кадру дописывается мак-адрес интерфейса (через который отправляется пакет), мак-адрес получателя (который мы узнаём с помощью ARP).

Рассмотрим простую схему: три сегмента сети (для удобства это будут 10.0.0.0/8, 172.16.0.0/12 и 192.168.0.0/16), соединённые маршрутизатором.

Маршрутизатор имеет три интерфейса (мак-адреса нам не интересны) с IP-адресами:

10.0.0.1 netmask 255.0.0.0
172.16.0.1 netmask 255.240.0.0 (обратите внимание - граница маски проходит не по байту, bin(240)=11110000)
192.168.0.1 netmask 255.255.0.0

В каждом из сегментов сети у нас зоопарк из кучи разных железок, компьютеров и прочего активно из себя изображащего хлама.


Какие настройки сети у узлов в каждом из сегментов?

Во-первых, некий IP-адрес. (Пусть это будут 10.0.0.11, 172.16.0.12 и 192.168.0.13). Это маски сети (они совпадают с масками соотв. сетей у маршрутизатора - и это фундаментальное требование для работы сети). И это шлюз по умолчанию. Большинство рабочих станций (да и железок) ни сном ни духом о настоящей маршрутизации, и им достаточно понимания, что "это для соседа, а всё остальное на шлюз". Отсюда, кстати, и название "по умолчанию" - других-то альтернатив нет. В серьёзном сетевом железе есть "шлюз последней надежды", а для "сетевых тупичков" (домашних компьютеров, например), "последняя" надежда совпадает "с первой".

Итак, у каждого из них есть шлюз по-умолчанию. Это адреса нашего маршрутизатора, потому что он отлично знает, что делать с пришедшими пакетами - для рабочих станций более удобного "шлюза надежды" (на связь) не найти.

Пусть узел 192.168.0.13 решает(ся) отправить сообщение на узел 10.0.0.11. Он помещает сообщение (о том, какие это сообщения мы поговорим много позже) во внутрь IP-пакета.

Нам всё-таки придётся подумать о мак-адресах, так что назовём их для примера:
маршрутизатор: адреса 00-00-00-00-00-10, 00-00-00-00-00-172 и 00-00-00-00-00-192; узлы (чтобы не изобретать лишнего): 00-00-00-00-00-11, 00-00-00-00-00-12, 00-00-00-00-00-13. В реальной жизни маки совсем не такие красивые, но для простоты определения пусть они будут "говорящими".


Поля IP-пакета:
IP-адрес отправителя: 192.168.0.13
IP-адрес получателя: 10.0.0.11

Узел отправителя видит, что пакет адресован совсем не соседу (из 192.168.х.х), а хрен знает кому. Он решает передать это сообщение на шлюз, мол, "там разберутся". Для этого узел выясняет мак-адрес маршрутизатора (посылает ARP-запрос: "192.168.0.1, отзовись" (MAC-адрес отправителя 00-00-00-00-00-13, MAC-адрес получателя FF-FF-FF-FF-FF-FF), получает ARP-ответ "я" (MAC-адрес отправителя 00-00-00-00-00-192, MAC-адрес получателя 00-00-00-00-00-13). Выяснив MAC-адрес, узел передаёт IP-пакет (который с точки зрения нижележащих уровней уже не пакет, а просто набор байтов, т.е. данные) на второй уровень с наказом "от 00-00-00-00-00-13 к 00-00-00-00-00-192".

Второй уровень формирует кадр с адресами:

MAC-адрес отправителя: 00-00-00-00-00-13
MAC-адрес получателя: 00-00-00-00-00-192

Этот кадр скармливается первому уровню (которому пофигу на маки, ИП, авторские права и всё остальное - для него это 1110001010110110101001... и так по 8 часов в сутки от звонка до звонка). Устройство физического уровня начинает тужиться и выдаёт в среду передачи данных некую последовательность перепадов напряжения (для любознательных - манчестерский код).

Физический уровень у всех слушателей (повторю, У ВСЕХ СЛУШАТЕЛЕЙ в физическом сегменте) выслушивает то, что ему говорят, и передаёт "это выше". Выше второй уровень проверяет, что получили то, что нужно, и что данные адресованы именно "куда надо". Если нет, то кадр просто игнорируется.

Второй уровень на маршрутизаторе, обнаружив, что "это таки нам", заглядывает во внутрь и видит, что это "ИП-пакет". ИП-пакет идёт выше уровнем (дело в том, что передавать могут далеко не только ИП-пакеты, например, ARP запрос будет обрабатываться совсем по другому).

Уровень выше смотрит на полученное. Долго думает.
С одной стороны пакет "нам" (так говорит канальный уровень). С другой стороны в поле получателя не мой адрес... Ах, да, я же ещё и маршрутизатор. Пакет поступает в маршрутизацию. Маршрутизатор видит, что у него есть "связи" в соответствующем сегменте (10.0.0.0/8). Пакет попадает на очередь вывода в соответствующий интерфейс. Нам надо передать "это" узлу 10.0.0.11. Мы знаем, что он где-то рядом. Посылается ARP-запрос "10.0.0.11 c вещами на выход" (MAC-адрес отправителя 00-00-00-00-00-10, MAC-адрес получателя FF-FF-FF-FF-FF-FF). Получается ответ (от 00-00-00-00-00-11 к 00-00-00-00-00-10).

Теперь, зная мак-адрес цели, маршрутизатор с чистой совестью передаёт ИП-пакет на второй уровень (от 00-00-00-00-00-10 к 00-00-00-00-00-11).

Второй уровень спихивает это на первый, там шипят, это шипение слышат все, но воспринимает только обладатель мака 00-00-00-00-00-11.

На узле-получателе кадр проверяется, передаётся на третий уровень, где задумчиво говорят: "ба, четвёртый уровень, танцуй, тебе пакет".

Всё.