Кирилл @MrKirushko
Инженер-программист
Information
- Rating
- 3,626-th
- Location
- Москва, Москва и Московская обл., Россия
- Date of birth
- Registered
- Activity
Specialization
Software Developer, Embedded Software Engineer
Lead
Git
C++
C
Linux
OOP
English
Software development
Qt
Programming microcontrollers
Embedded Linux
Да вроде работает все... Впрочем, если не нравится Globalstar то есть еще как минимум Iridium. Это еще дороже, но зато это 2-направленный канал + телефония.
Лично мои часы вообще отсчитывают механические колебания небольшого шлифованного кристаллика кварца с тонким серебряным напылением на торцах подключенный в электрический генератор со стандартными параметрами, размеры которого подогнаны так чтобы в такой конфигурации эти колебания происходили с частотой примерно 32768 раз в секунду и чтобы при отклонении температуры и давления от стандартных эта частота не слишком уползала. Казалось бы сплошной хаос, куча всего может на это "время" повлиять и идеальной точности тут как своих ушей не видать, но мне для своих нужд хватает с головой и уже лет 5 как я время не переставлял и батарейку не менял даже. А главное - никакой цезиевой плазмы, минимальный вес и помещается в компактный пластиковый корпус на руку на ремешке.
Так в этом то и заключается главная идея революции в физике 21-го века и ее понимание относительности. Началась она, правда, еще раньше, еще с термодинамики, когда в физику пришло понятие вероятности и вместе с ней как новые статистические параметры (температура) так и новое понимание старых (давление). Это был первый шаг к познанию того что полностью и с абсолютной точностью познать невозможно в принципе. В 21-м веке эта идея просто сделала еще несколько важных шагов и дошла до своей высшей точки.
Суть как раз в том и состоит что мы не знаем заходили ли наш "мальчик" на "обед" или нет, мы вообще не знаем об его жизни ничего и даже его не видим. Чем он занимается дома под одеялом пока никто не видит мы никогда не узнаем. Даже о том что эти мальчики вообще есть мы можем только догадываться потому как в какой-то момент мы можем услышать как кто-то подходит и характерным голосом говорит "здрассти".
А раз проникнуть во внутреннее устройство мира и понять его истинную сущность мы никак совершенно не можем - так к чему заниматься самообманом. Вместо того чтобы пытаться опираться на вымышленные представления и из них пытаться вывести модели реально наблюдаемых явлений, гораздо лучше напрямую описывать наблюдаемые явления и сами наблюдаемые эффекты без привязки к чему либо, безо всяких посторонних прибавлений. Причем вплоть до присвоения общих наблюдаемых свойств самому времени и пространству, опираясь таким образом на вымышленное пространство приближенное не к истинному а к эффективно наблюдаемому. И не важно чем эти свойства нашего субъективного пространства в природе на самом деле для нас обеспечиваются и какова на самом деле геометрия истинного пространства - какой смысл вообще говорить про это "на самом деле", если абсолютной истины если она вообще существует мы все равно никогда не узнаем. Это как в географии - все пользуются или сферическими координатами - широта, долгота и высота (и не важно что на самом деле земля не шарообразная и даже не эллипсоидная) или специальными плоскими, 3-мерная прямоугольная система координат для каких-либо практических целей тут просто неприменима (и то что из-за этого вместо для работы с большими расстояниями вместо линейных уравнений нам теперь просто неизбежно, сходу и в ассортименте, нужна тригонометрия никого никогда не смущало).
К сожалению такой подход существенно усложняет необходимый для анализа математический аппарат (как по сути так и просто по вычислительной сложности), но зато мы можем сразу строить точные модели. Уже не раз история показывала что в математических моделях пригодность для практического применения при достаточной точности в итоге всегда побеждает и понятность и универсальность и все остальное.
Если вы все сидите в одном небольшом городе и вас таких не более пары сотен энтузиастов то да, если небольшая скорость устраивает то можно и без опорных узлов. Но если вас таких больше или если расстояния такие что нужна длинная цепочка ретрансляции - тогда уже нет, без интернета оно хоть сколько-то адекватно работать уже не будет.
Тоже хотелось бы узнать. Используем StaterKit-овские модули с тем же контроллером, пока никаких проблем с краевыми разъемами в которые они вставляются замечено не было.
Так спору нет что вариантов множество. Если есть деньги и скорость особо не нужна то давно есть американский globalstar, в России он вполне легален а обмен идет напрямую с серверами в США не требуя вообще никакой инфраструктуры на территории РФ. Если хочется полной автономии то LoRa на 433 и даже 800 МГц уже есть в коммерческой эксплуатации (всякие пульты охраны, умные электросчетчики и прочее). То есть при определенных условиях даже и прятаться ни от кого не прийдется. Но все эти существующие варианты либо требуют доступа опорных узлов в Интернет (LoRaWAN) либо для массового использования (не то что типичными лопоухими обывателями, а вообще) просто в принципе непригодны.
Тот же globalstar, к примеру, вполне пойдет чтобы переслать записи температур за неделю с какой-нибудь метеостанции в РосГидроМедЦентр или чтобы короткую текстовую шифровку об итогах вербовки агентов и необходимости готовить счета на Сейшелах на случай успешного выполнения ими задания в Пентагон по электронной почте отправить, но о современном Web-серфинге, не то что о YouTube, с ним можно даже не мечтать. И это - при совершенно конской цене как терминалов так и траффика.
Мелкие некоммерческие эксперименты же единичных радиолюбителей и энтузиастов на политический ландшафт не влияют, центральные власти не интересуют, и выделение ресурсов на заранее проигрышную борьбу с ними не оправдывают. А на переход во что-то большее у этой дохлой темы надежды просто нет.
Ну если косвенно - тогда default-ная реализация в том же Linux например. Версия ядра 4.1, tcp_ipv4.c - при получении ICMP-сообщения от роутера о необходимости фрагментации (уменьшения MTU для снижения потери пакетов - тот же стандартный Path MTU Discovery только для TCP он уже обязательный), автоматически формируется SYN-пакет, при этом обновляются данные MTU для текущего алгоритма congestion control, и тут же перепосылается уже сразу ясно что потерянный (отброшенный маршрутизатором) пакет. Все индицируемые в рамках ICMP ошибки также в этом модуле обрабатываются. Это только то что я так сходу увидел. Уверен, есть и еще куча подвязок и на разных системах они разные.
То что TCP со временем в таких сетях жестко тормозит и стабильно периодически уходит в разрыв соединения - это просто было проверено экспериментально, на реальном контроллере при подключении к реальному Linux-серверу (у РЖД одна такая изолированная сеть есть). В общих четрах причины, конечно, понятны, но как в точности это происходит, поможет ли включение в конфиге ядра "TCP: advanced congestion control" и смена алгоритма CUBIC на что-то другое (на большей части узлов сети, разумеется), как это будет проявляться на других реализациях TCP, начиная с какого размера и загрузки сети это происходит гарантированно, какие особенности конфигурации сети могли бы на этот эффект повлиять, и как можно полностью воспроизвести этот эффект на маленькой стендовой сети - ответы на все эти вопросы я не выяснял и точных моделей не строил. Возможно, если хорошо погуглить, найдутся какие-то исследования на эту тему, но итогового практического вывода о необходимости оставлять ICMP как минимум внутри сети это в любом случае не меняет.
"Запеленговать" передатчик можно почти всегда и вне зависимости от того что он передает - достаточно чтобы его общая выходная мощность была заметна на фоне шума или его излучение имело характерные особенности. Если ваша задача - спрятаться в эфире, то единственное что остается - мимикрировать под массовые частные радиопередатчики (Bluetooth/WiFi/GSM/LTE/LPD/...). А все они (как минимум на клиентской стороне) работают на ограниченных мощностях и ограниченных ширинах канала и для построения крупной открытой сети со свободной маршрутизацией (а иначе это просто пейджер, мы то хотим чтобы любой произвольный абонент такой сети могу кому угодно сообщение послать, хоть всем абонентам сразу если они на него подписаны) без опоры базовых станций на наземные каналы передачи (а из адекватных данной задаче это только Интернет) они в принципе непригодны.
Так что отсутствие особого внимания ко всем этим mesh-сетям со стороны контролирующих органов вполне понятно - для них даже сейчас эта проблема уже по сути полностью решена. Им достаточно контролировать сеть Интернет (а точнее свой национальный сегмент) и ловить тех кто особо нагло передает в эфир явно вне безлицензионных и разрешенных ему лично диапазонов или на явно на порядки завышенной мощности (а это нужно делать в любом случае - просто чтобы такие персонажи законным операторам радиосвязи для их обычной служебной деятельности помех не создавали). После этого все остальное с математической неизбежностью закрывается автоматически.
Ну, не единственное... OpenVPN на своей VPS-ке уже года 3 как безотказно выручает нас в плане доступа до YouTube-чика. По крайней мере в Москве и МО.
Что касается ICMP - вы самого главного не казали: того что ICMP - это не только PING. Этот протокол не только и не столько "используются для диагностики", его главная задача - контроль доступности узлов и межсетевых ограничений для обычных соединений. И если в UDP этот функционал используется только в рамках "Path MTU Discovery" и то опционально, то для TCP это гораздо более важно. Тут это нужно для контроля загрузки канала а некоторые реализации протокола TCP (congestion control алгоритмы но и не только) без этой информации являются неустойчивыми и через какое-то время при работе через такую "черную дыру" (когда узел просто кидает пакет в сеть и ждет от нее ответного сообщения ответного узла и надеется на лучшее, потому как никаких сведений о встретивших этот пакет на пути затруднениях и вообще о его маршруте у узла-отправителя нет) гарантированно происходит разрыв соединения (перед этим ваша система, разумеется, накидает в сеть как следует мусора, который в ней собственно в итоге и застрянет). И если полная блокировка ICMP в небольшой локальной сети просто приведет к повышению времени установления соединений, увеличению загрузки сети служебными пакетами, и как итог - к снижению эффективной пропускной способности сети, то полная блокировка же этого протокола в сети масштабов национального сегмента Интернета просто в течение нескольких минут наглухо положит весь этот сегмент и все.
Так что, если бы могли - не сомневайтесь, отрубили бы, может даже разок попробовали уже. Не от большой щедрости, заботы о ближнем и доброты у них эта дыра существует. Даже при полной и тотальной изоляции сети как минимум до IP-адресов из "белого списка" пропускать ICMP все равно прийдется (а уж на них то каким-нибудь админам по тихому развернуть несколько VPN "для своих" как раз и будет самое милое дело). Просто заткнуть эту дыру без радикального изменения архитектуры сети и перехода на альтернативные протоколы передачи данных при сохранении емкости сети практически невозможно. А с учетом того что мы даже на IPv6 уже сколько лет перейти никак не можем, не то что какие-то новые протоколы сетевого уровня разрабатывать и внедрять, ожидать тут каких-то изменений в ближайшем будущем не стоит. Поэтому дыры всегда были, есть, и будут. Как говорится, ищущий да обрящет :).
Если по вашему примеру, главное - не лошади а извозчики, но в остальном если на дворе 1850-й год (а сегодня для уровня развития ИИ - как 18-й век для автомобилей) то все верно. Как пришел 20-й век и эти технологии хоть немного дозрели - так и стоило начинать о них думать. Заодно и многие извозчики ваши к тому моменту уже посмотрели на это все и захотели стать водителями.
Для того периода здоровые, ухоженные и сытые лошади - это и вправду был хоть и не залог успеха, но один из совершенно необходимых его компонентов, а автомобили - это были лишь игрушки для богатых и денег они никак не приносили а только впустую жрали.
А что до вашей железной дороги - так это чудо не только не спасение для руководства, а вообще наоборот, оно во времена бума имело все шансы просто с концами похоронить всю вашу контору. Требования к качеству и тщательности организации работы персонала и вообще адекватности менеджмента на железной дороге только выше чем с парком единичных повозок - тут уже нужно не только знать заранее когда, сколько и чего вы повезете по каждому отдельному паровозу и его составу. Тут это нужно знать по каждому вагону и даже по каждому грузо-месту, потому как если выгрузить мешок не на той станции куда ему было надо, то есть риск попасть на клиента которому прийдется компенсировать все его связанные с вызванными вашей дуростью задержками издержки и еще лично ехать извиняться с подарками, и молиться чтобы на какой-нибудь ваш склад в один вечер не подъехала бригада крупных ребят с битами и факелами. Это не говоря уже о рисках (и цене ликвидации) аварий в случае перегрузки или неравномерной загрузки. Сход состава - это вам не телегу перевернуть, эту проблему ваш машинист как-нибудь своими силами и без лишних расходов для компании уже точно не решит.
Многие пытались тогда зайти в этот бизнес, но почти все в итоге прогорели. Большинство из них на прибыль так никогда и не вышли, а многие на этом вообще потеряли все что имели. А те немногие кто смог таки ценой огромных расходов пройти все пробы и ошибки и через какое-то время организовать все что нужно чтобы хоть как-то худо-бедно с этой технологией работать, и в итоге вышел через какое-то время в плюс и даже по итогу заработал - те все равно со временем столкнулись с неразрешимыми на тот момент как чисто техническими, так и организационными проблемами, и в итоге были почти во всех странах все полностью поглощены местными национальными монополиями, которым до момента появления решений этих самых проблем просто прощалось и компенсировалось все.
Если на дворе конец 18-го века, то без хороших друзей в правительстве в железные дороги лучше даже и не соваться, да и даже с такими связями успех далеко не гарантирован, в самом лучшем случае он будет стоить кучи нервов, и будет длиться недолго. В то время не в ЖД, а в рабов и табачные да сахарные плантации вкладываться надо было - те кто так тогда поступил подняли такие бабки, что потом смогли выйти в американскую нефтянку или морские перевозки выйти, в свое время обладали огромным влиянием не целые регионы, не то что отдельные страны (некоторые из которых просто скупили целиком с потрохами и на десятилетия пустили на бананы), и в итоге на сегодня их потомки ничего за всю жизнь не делая и никакими компаниями не управляя просто с доходов того старого вложенного в самые разные активы капитала живут припеваючи и являются одними из богатейших людей планеты. Даже те кто просто имел один небольшой участок, склад, повозку, пресс для тростника, 2-х рабочих, осла и договор с десятком местных фермеров - уже тогда заработали очень неплохо (конечно, только те у кого осел был сыт и ровно не хромая по кругу ходил, и у кого рабочие получали достаточно чтобы они охотно следили за прессом и постоянно вальцы регулировали чтобы соку побольше отжимать, и еще была подменная машина и договоры с местными слесарями, фабриками и литейными цехами на своевременный ремонт, поставку, подгонку и установку стабильно ломавшихся и изнашивавшихся запчастей - у тех кто просто сидел за океаном и ждал отчетов о работе доход хоть и был, но по абсолютным величинам и их перспективам дела как правило шли сильно хуже, чаще всего большую часть всех каким-то чудом добытых годных продуктов просто уводили местные управляющие, да воровали сами месяцами на этих вечно простаивавших заведениях не видящие зарплаты рабочие) и для некоторых это стало началом очень крупного бизнеса. ЖД - даже для крупной компании далеко не лучший пример.
В общем, если не забывать о главном, о людях (о ваших специалистах), и при принятии решений следовать за ними, то когда для нужных технологий уже точно подойдет время то все произойдет само собой и не беспокойтесь - не заметить этого или это игнорировать уже просто не получится. А если на своих специалистов ложить болт и считать что пусть они там сами как-нибудь работают и решают проблемы своими силами как хотят и нас со всякой мелкой ерундой вроде нехватки материалов или критического износа инструментов пусть не беспокоят, потому как мы им как раз для этого зарплату и платим - тогда будет у вас вечная жопа, в любом деле и в любые времена. Это было верно 8000 лет назад когда дома строили из сырых кирпичей замешанных на глине с соломой и рабочим платили пшеном и пивом, а навязка на шнурке 2-х узелков, а потом еще 3-х таких же через 3, 4 и 5 расстояний между первыми двумя для получения прямого угла между обтянутых таким шнурком вешек - это уже была вершина цепочки доступных технологий. Это столь же верно сегодня. И пока разумные машины не станут способны ставить, обдумывать и решать задачи полностью без участия человека, так оно и будет дальше. А когда спустя много лет это будущее наконец наступит - тогда ведь не только в исполнителях, но и в руководителях нужда отпадет. Тогда вообще всеми процессами и даже обществом и государством будут управлять машины, у них это будет получаться 100% быстрее и качественнее чем у живых протирающих в кабинетах штаны управленцев, которых они заменят даже раньше чем смогут заменить и половину живых исполнителей.
Ну так если сил не хватает то пригласите еще! Если весь ваш интерфейс или алгоритмы даже оставить из 2001-го года, то сильно хуже пользователям не станет (а по мнению многих - так даже и удобнее будет), но вот если карты и справочники адресов огранизаций в 2025-м году будут из 2001-го, то это полное фиаско получится. Ваши картографы - это самое главное что то делает вашу программу вообще полезной, основа ее всей, и самый ценный ресурс всего вашего картографисеского подразделения. На них у вас там все программисты работать должны и по их первым просьбам скрипты для обработки данных подготавливать, по отдельным зонам отрабатывать, и на проверку к ним отправлять. Будем надеяться что ситуация с этим моментом будет улучшаться.
Самое главное что нужно понимать манагерам - это то что если у тебя есть какая-то задача и ты сам своими силами решить задачу не в состоянии, то для тебя ее решение - это чисто имя и фамилия. От этого никогда никак не получится уйти и от этого до конца никак не абстрагироваться, а попытки всего этого всегда будут стоить дополнительных денег. Более того, даже и в целом любая компания - это на 99.99% лишь люди которые в ней работают. От каждого из них зависит ее будущее и настоящее, а от их всех вместе это зависит полностью. Можно пытаться внедрять ИИ, делить компании, внедрять подрядчиков субподрядчиков для "хеджирования рисков", пытаться процессы максимально автоматизировать и в целом "устранять человеческий фактор", но на конце этой цепочки всегда будет Вася который делает какую-то работу. А Вася - он сидит на копеечном фиксированном окладе и ему на это все побоку, если он сегодня плохо выспался то результата у вас до следующего дня не будет. Поэтому своего Васю по каждому участку и каждому направлению нужно если не знать в лицо, то уж точно четко понимать как у него дела, что и как он делает, и что ему для этого нужно. Это - самое главное для вашего бизнеса.
Поэтому же самое лучшее место для повышения производительности в которое нужно вкладываться первым делом это самый нижний, исполнительный уровень. База - это чтобы Вася получал достаточно чтобы не думать каждый день о деньгах. После этого для начала в подмастерье к Васе нанять Петю чтобы если в системе был какой-то минимальный запас прочности. Потом нужно оборудование регулярно обновлять и отдельно следить за ним (тут тоже - слесаря Семена заменить никак не выйдет и даже если они сидит в другой компании с который у вас договор то это не значит что о нем можно не беспокоиться - у вас в конторе обязательно кто-то с ним должен быть знаком лично). После этого можно уже и выше переходить - к организации микрологистики, еще выше уровень - информационно-справочные системы и базы данных. И пропускать этапы нельзя, поскольку организационно-технические меры более высокого уровня без корректного сопровождения более низкоуровневых процессов будут почти бесполезны. А самое главное - все кто принимает в компании решения должны точно понимать чем занимается их фирма, какие ресурсы и как в точности для чего используются и откуда что берется, понимать суть процессов и понимать характер потоков ресурсов на всех уровнях не только в денежном но и в натуральном выражении и в плане их назначения для технологических процессов. Иначе ваш Вася просто будет смотреть на вас как на дебилов и должного взаимопонимания не получится.
Нам нужны не "умные" и не "дружественные" компании, а технологически - ориентированные. Даже модный ныне machine learning это суррогат - по хорошему статистическую модель процессов у вас должна не машина а человек составлять (штатный аналитик), и не по фактическим данным а на основе понимания сути и причин всех происходящих у вас процессов, а по сырым данным их следует только проверять. Если компания в первую очередь следит за сохранением и преумножением своих технологических возможностей и компетенций то все эти ИИ и прочее - это настолько высокий уровень организации и эффект от него будет столь мизерный, что большинству компаний (для всех кроме самых крупных) оно и не нужно. Если же компания большую часть своих ресурсов просто постоянно и стабильно по тем или иным причинам просирает, если в ней огромная текучесть кадров, если в ней происходят какие-то существенные теневые централизованно не контролируемые процессы, и в целом если хозяйский подход отсутствует - тогда внедрение таких систем это гарантированно лишь красивый и модный способ спустить в трубу кучу бабла, не получив взамен ничего полезного ни для вас ни для ваших клиентов и никак не увеличив ни ваши доходы ни устойчивость вашей компании.
И главное - было бы ради чего! Все эти отрисовки полос на линиях дорог все равно в нормальном масштабе на экране смартфона/навигатора не видно, а погрешность GPS в движении (если он вообще работает и глушилок нет) все равно в пределах метров так 15 и точно показать по какой полосе ты едешь ни сегодня ни в обозримом будущем он не сможет. Да что там говорить - когда по дублеру едешь Яндекс часто привязывается к основной трассе и даже когда да нее уже метров 30 показывает как будто бы едешь там. Про все это 3D, рекламу, тучу значков и все прочее даже и говорить смысла нет - оно только занимает ресурсы и без того тормозящего смартфона и отвлекает водителя. И вот в итоге какой смысл с таким рением смотреть в это невнятное "будущее" и что-то под него сейчас делать создавая всем неудобства прямо сегодня, когда реальной пользы от этого никому почти и нет? Вот когда оно наступит - тогда и меняйте! По сути это все - лишь дешевые оправдания служащие лишь цели показать что какие-то работы ведутся, какие-то движения есть, и значит проект нужно продолжать и выделять на него деньги и дальше. Вот и все.
Зеленое - значит там жить можно. Серое, синее или белое - значит нет.
Там они давно неактуальные, но лучше такие чем никаких.
Ни в коем разе! Если нет наследования (а точнее - полиморфизма, как его следствия), то нет не то что смысла в ООП, но по сути не остается и самого ООП. Без него ООП вырождается в просто подобие карго-культа, с соблюдением его ритуалов (синтаксиса) но без каких-либо реальных целей и преимуществ.
Просто возьмите вместо объектов структуры данных, а вместо методов - обычные функции (если нужна красота - то заверните их в namespace-ы или модули) и в итоге по сути ничего не изменится. Смотрите сами:
Было -
TMyCalss* object = new TMyCalss(); object.method(); delete object;
Стало -
TMyDataStruct* data = MyDataInit(); MyDataMethod(data); MyDataClose(data);
Все то же самое (а код стал даже понятнее, как минимум ключевых слов страшных меньше). В итоге из плюсов остаются только синтаксические удобства конкретного языка вроде автоматического вызова конструктора при выходе объекта выделенного на стеке из зоны видимости в С++. У идеи того что уже эти плюшки на 100% оправдывают разведение объектов во все поля, конечно, есть сторонники. Но нужно понимать что и они на самом деле не сторонники ООП, а просто любители всех этих плюшек, даже если сами этого не осознают.
ООП не мертво и в некоторых случаях даже полезно (чужие библиотеки, сложная настраиваемая пользователем логика и т.д.), но просто для большинства задач оно не нужно совершенно, но до недавнего времени его было принято пихать во все что только можно даже несмотря на то что обычно это лишь приводило к бессмысленному распуханию кода, снижению его читабельности и уменьшению производительности получаемых программ.
Проверить нужно ли оно конкретно вам для вашей задачи очень просто - посмотрите и подумайте насколько вам нужно наследование классов и чего будет стоить от него избавиться. Если при отказе от наследования общее количество и сложность кода вашей программы особо не увеличится, значит ООП вам просто не нужно. Если же в этом случае ему на замену прийдется писать некий абстрактный интерфейс или кучу заменяющего его if/else/if/else/if/else...-кода - тогда для вашего случая по крайней мере для какой-то части программы ООП действительно полезно и потому должно быть использовано.
Если уж залез на Эверест, то просто плюнуть мало, нужно еще и по нужде сходить, скинуть говно вниз со всей этой высоты, и фото сделать. Тогда можно будет потом сделать плакат с этой фоткой и надписью "Срал я на весь этот сраный мир" и считать что теперь то уж жизнь свою ты прожил не напрасно.
Слабовато как-то планируют. Я вот лично перед сном иногда размышляю о полетах на меркурий и переработке этой планеты в сетку солнечных панелей вокруг всего солнца. Уж если забыть про физику и просто мечтать, то уж тогда лучше сразу на широкую ногу.