В упор не понял подход. Правила чтения по-польски в оригинале осваиваются максимум за полчаса безо всяких корявых псевдо-транслитераций. От того, что автор показал в статье, просто кровь из глаз идет. Зачем? Особенно при наличии гуглопереводчика, который дает вполне сносный перевод?
Нет, это не "то же самое слово". Błąd по-польски - ошибка. Слово того же корня, что и, например, błądzić - блуждать, сбиваться с дороги. То слово, что вы имеете в виду, по-польски будет kurwa.
Тем не менее, версия, что хорошие зубы объясняются отсутствием сахара в диете, критики не выдерживает. Во-первых, сахар и аналогичные сладкие углеводы до самого недавнего времени вообще были весьма редкими пищевыми компонентами. Во-вторых, сахар влияет на зубы не телепатическим образом, а создавая богатую углеводами среду в ротовой полости. А для этого требуется липкая или долгоиграющая сосательная субстанция, т.е. что-то типа конфет или иных кондитерских изделий на базе того же меда. Доступ к такого рода лакомствам был в первую очередь у богатых (бедные их могли потреблять разве что по большим праздникам), то есть именно они должны были быть более подверженными его негативным эффектам.
Другое дело, что каждая такая виртуалка должна быть посчитана, и на неё должны быть выделены гарантированные ресурсы.
Вот совершенно не обязательно. При нормальной организации труда всегда есть девелоперское окружение, возможно, не обеспечивающее QoS и не гарантирующее избытка ресурсов, но имеющее достаточно ресурсов для упрощенного выделения ВМ-ки для разработчиков. Резерв мощностей под такую разработку всегда можно оставить, благо они много не требуют, а если и требуют, то разрабы могут смириться с медленной работой. А уже когда система сделана, отлажена, продемонстрирована и принята, ее мигрируют в продуктив тем или иным способом. Это стандартная схема в крупных корпорациях.
В вашем примере вы создавали виртуалки по запросу сотрудников, и даже не интересовались, сколько им понадобится ресурсов, и выдержит ли ваш сервер.
Не стоит заниматься телепатией, она обычно не работает. ;) У меня разработчик / препод объяснял, что именно ему нужно, я соотносил с резервами и выделял место соответственно. Процедура была сугубо неформальной, но она была - с исследованием запроса, с документированием каждой ВМки (включая DNS-алиасы и ответственных персон), с настройкой бэкапа и т.п. Ситуация, в которой я бы потерял сервер при переезде или переконфигурации сети, была просто немыслимой. И это при том, что я практически в одиночку тащил немаленькую Винтел-инфрастурктуру. Для корректной организации работы больших трудозатрат не нужно, нужен лишь правильный подход.
Правда жизни заключается в том, что потребности средней тестовой машины (грубо - 16-24 Гб ОЗУ, 100-200 Гб на диске и близкие к нулевым потребности CPU) практически неразличимы на фоне железных серверов с терабайтами ОЗУ и сотнями терабайт на дисках. Даже в самых бедных условиях кластер для разработки банально строится на паре серверов low-end и внешнего SATA-дискового массива с подключением по iSCSI. Дисковые иопсы будут низкими, но для демонстрации концепта сгодятся.
И заметьте, я рассуждаю в терминах технологий десятилетней давности. В современных условиях даже это железо не требуется. Любой публично-облачный сервис с удовольствие предоставит ВМ-ки и / или контейнеры любой конфигурации по схеме Pay as you go или аналогичной.
Зачем увольнять сотрудника, который на простое системы чему то научился?
За то, что человек чему-то научился, надо поощрять. Увольнять надо за то, что он явочным порядком, без согласований, предупреждений, авторизации и контроля, занялся перестройкой критичного бизнес-процесса. Это как если бы человек в автомобиле без спросу заменил квадратное, но каменное колесо круглым, но картонным. Крутится оно, конечно, заметно лучше, но лишь до первой лужи.
Видимо вы никогда не работали в корпорациях.
Видимо, телепатия все-таки не ваш конек. :D Мой опыт работы включает, в числе прочего, многолетнюю работу техлида Винтел-тима в не-российской международной конторе с примерно четырьмя тысячами виртуальных виндовых серверов, парой сотен физических и несколькими десятками тысяч пользователей. А еще у меня в биографии есть многолетняя работа ведущего Винтел-специалиста в российском системном интеграторе, которому по долгу службы пришлось насмотреться на самые разные изумительные конфигурации в инфраструктурах клиентов. И именно на основании этого опыта я и рассуждаю.
Автора положено было наказать за то, что создал риски на пустом месте. Не имеет значения ни предыстория, ни мотивация. Важно, что он своей инициативой создал проблемы в устоявшемся бизнес-процессе, причем так, что никто из отвечающих за него лиц об этом даже не подозревал.
Благими намерениями выложена дорога в ад. Давно уже сказано...
Я не говорю про разработку, я говорю про платформу. Получить виртуалку при правильной организации работы в ИТ - это несколько кликов мышкой в веб-интерфейсе. При чуть менее правильной - пятнадцать минут работы сисадмина. Приватные облака десять лет назад прекрасно делала и ВМВарь, и Майкрософт. У меня такая система была организована в не самом крупном и богатом провинциальном университете (о бюджетах сами догадываетесь) именно в то время. Каждый препод, кто запрашивал виртуалку, ее получал, причем в состоянии высокой готовности. Тот факт, что в данном конкретном банке получить виртуалку в штатной системе виртуализации было невозможно или крайне тяжело, и говорит о состоянии дел в его ИТ. Некомпетентность и непрофессионализм, это единственный диагноз.
Далее, проекты "на попробовать" ни при каких обстоятельствах не должны выходить за рамки "попробовать". Из описания же автора явно следует, что система явочным порядком пошла в продуктив - без тестирования, без фиксации данного факта в реестре систем банка, без одобрения стейкхолдеров, при этом буквально в состоянии "из говна и палок". Такая инициатива похвальна, если она кончается нормальным внедрением. Когда она кончается явочным переносом критичной нагрузки на нечто, сляпанное на коленке, и об этом не подозревает никто из тех, кому положено знать, это неполное соответствие служебным обязанностям. Простой банковских систем означает совершенно конкретные финансовые потери. За такое совершенно справедливо увольняют, даже если катастрофы удалось избежать.
Если у бизнеса есть на что-то заказ, существуют процедуры его реализации, начиная с обсуждения на соответствующих уровнях. Если админы баз данных, CRM-системы (или что у них там) утверждают, что нечто нужное сделать нельзя приниципиально, а некто опровергает это на практике, но админы игнорируют, существуют более высокие уровни, на которых инициируется проект - вплоть до правления банка. Опять же, если этого не делается, если директора отделений жалуются на проблемы, но все кончается пофигизмом службы ИТ, это бардак в организации системы управления.
Часть, относящаяся к внутрибанковским процессам, интересна, спасибо. Но на самом деле этот рассказ - великолепный пример того, почему непрофессионалов и близко нельзя подпускать к построению ИТ-систем, особенно критичных для бизнеса.
Применяемые для построения систем решения не просто скверные - катастрофичные. ПК под столом создает гигантские операционные риски, особенно если на него завязана хоть сколь-нибудь важная система. ПК под столом свойственно дохнуть из-за пыли, перегрева (особенно летом), сбоев электропитания или десктопного железа, не рассчитанного на режим работы 24х365, а также просто от швабры уборщицы тети Маши. Привязка адреса приложения к IP-адресу, да еще и без какого-либо понимания, привязан этот адрес к МАС-у или выдается случайно, тоже находится за гранью добра и зла. Ну и про тот факт, что никто не обеспечивал физический контроль доступа к системам обработки критичных данных, тоже должен был поставить на уши и службу ИТ, и службу безопасности, не говоря уже про внешних аудиторов.
На самом деле задача вполне оперативно решалась созданием виртуальных машин в режиме высокой доступности (ни за что не поверю, что у банка в начала 2010-х не было системы виртуализации), что не требует вообще никаких инвестиций, по крайней мере, немедленных. Тот факт, что этого не было сделано, а автор не получил очень больно по рукам за такие решения независимо от их полезности, может свидетельствовать только о тотальном бардаке в банке.
Верно, ДТП - это прежде всего человеческий фактор (хотя и технический сплошь и рядом встречается - лысая резина, например, или сгоревшая лампочка в поворотнике). Но вообще-то вам будет сугубо параллельно, свалится вам на голову машина в полтонны-тонну весом из-за отказа движков или из-за того, что очередному юному шумахеру моча в голову ударила и он разгнаться решил там, где не стоит. Да, человеческий фактор может исключить полностью автоматизированная система управления всем транспортом без возможности ручного управления. Но до такого решения сейчас как до Луны. В лучшем случае это будет в середине века. В реалистичном сценарии - еще плюс лет двадцать-тридцать.
Убирать провода со столбов каждый раз, чтобы посадить такое такси, это слегка перебор, нэ? :D
Что же до новых улиц, то я как-то ни разу не видел улицы, построенные с нуля. Это может быть разве что на окраинах. Полная переделка всей проводной инфраструктуры на существующей улице может оказаться по стоимости как бы не сопоставимой с альтернативными решениями типа трамвайной линии (с прилагающимися к ней трамваями). Кроме того, убрать трамвайные и троллейбусные провода под землю невозможно в принципе.
Ленинские горы - как бы не самое типовое место в Москве. ;) А антигравитация, увы, от ДТП никак не спасет. Даже оставляя в стороне отказы антигравитационной системы, антигравитация не аннулирует массу и, как следствие, инерцию. С практической точки зрения это будет означать лишь, что машина с отказавшей системой управления будет падать не вертикально, а под углом.
В дополнение к комментарию JediPhilosopher следует также заметить, что в городах летающие машины вообще никаких шансов не имеют. Во-первых, отказ двигателей означает падение аппарата с высоты на головы людей или в гущу дорожного трафика. Результаты сами себе можете представить. В отличие от вертолета, такая хрень даже на авторотации сесть не сможет.
Во-вторых, любая улица современного города - это переплетение проводов практически над всей ее поверхностью, а достаточно часто - еще и древесные кроны. Никакой аппарат там не взлетит и не сядет даже вертикально. Крыши домов тоже исключаются: в подавляющем большинстве они не рассчитаны на дополнительную нагрузку и неустойчивы к повреждениям поверхности (в том числе гидроизоляции). Сейчас даже жильцам на крыши вход воспрещен, чтобы не топтались лишний раз. Даже если дом выдержит нагрузку "аэротакси", крышу придется дополнительно переоборудовать, плюс придется решать вопрос спуска-подъема пассажиров и их прохода по зачастую частной территории - а за чей счет?
Такие аппараты могли бы - при условии обеспечения безопасности - оказаться полезными в пригородном трафике. Но c ресурсом даже полчаса полета на скорости 60 км/ч - не, серьезно?
Нет. На пользовательских устройствах самая лучшая ОС - та, которую изучать вообще не надо. Пользователь не работает с ОС, она ему по большей части сугубо параллельна. Он работает с приложениями. Чем меньше ОС отвлекает на себя внимания от приложений, тем лучше. В идеале пользователь вообще не должен подозревать о ее существовании. Чем больше ее надо "изучать", тем более это скверная пользовательская ОС. Это именно то, чего не понимают разрабы даже домашних версий Линукса.
Как уже замечено выше, основная причина популярности индийского аутсорса - именно дешевизна. Да, средих них попадаются и очень квалифицированные и вменяемые люди (я с такими работал), с которыми иметь дело - одно удовольствие. Но также среди них масса людей, которым лишь бы отпихнуться от проблемы. Их английский весьма специфичен - зачастую сильно ломаный, с уникальными оборотами, не употребляемыми в стандартном английском, ну и с акцентом у них достаточно тяжко. Я к нему не один год приноравнивался. В целом на фоне европейцев они в большинстве смотрятся тускло.
До сих пор помню, как в 98-м, кажется, фирма Novell отдала написание клиента Нетвари для Винды индийцам. До того клиент был компактный, быстрый и идеально работающий. Но в один прекрасный момент фирма выкатила новую версию, написаную индийцами на Джаве. Мама дорогая... Они потом года полтора или два баги чистили, пока, наконец, хотя бы основные проблемы убрали.
Типичная для кодера узость мышления. В бесконечно-очередной скучный раз ставится знак равенства между кодерством и ИТ. Автор либо не подозревает, либо не желает понимать, сколько в ИТ других профессий - подержка серверной инфраструктуры, сетевики, безопасники, IOT, bigdata... Программеры - лишь одна из профессий, причем далеко не самая массовая. Чтобы в ИТ радикально сменить область деятельности, совершенно не обязательно менять техническую карьеру на административную, тем более что технари в массе склонны к интроверсии, плохо с ней совместимой.
С вами бессмысленно дискутировать. Вам бессмысленно что-то объяснять. Вы воюете не с реальными оппонентами, а с воображаемым врагом, созданным в вашем сознании зомбоящиком. Практически все ваши "возражения" не имеют к действительности никакого отношения, опираясь на банальные подтасовки и передергивания. "Вакцины неэффективны" вместо "вакцины от ковида неэффективны" - типичный пример. Тысячи вас таких, ретрансляторов ящика...
Писать в VAERES может кто угодно. Но подавляющее большинство простых людей даже не подозревает о ее существовании. И даже если мы примем, что там одни ламеры нетянучие, вы полагаете, что они не в состоянии сделать выводы в стиле "укололся - пошел на больничный с высокой температурой"?
У нас на работе уже стандартно и неофицильно дают день больничного после прививки, потому что это ширево вырубает если не всех подряд, то минимум каждого второго. Температура, слабость, ломота в теле - типичные симптомы. Намек: это не Россия и ширяют здесь отнюдь не "Спутником".
> До сих пор никто не показал, что это именно так.
Золотые слова. Не доказал никто, но используется повсеместно - от "статистики" ВОЗ до правительных постановлений о локдаунах. Позитивный результат теста? Все, умер от ковида, даже если был инфаркт или неоперабельный рак в терминальной стадии. Но в случае с прививками, разумеется, все совершенно не так. Даже если через неделю после нее от миокардита умирает подросток или от нетипичного тромбоза молодой здоровый солдат без единой болезни, "связь не установлена". Зато в случае жертвы автокатастрофы связь с ковидом устанавливается мгновенно. В Англии уже дважды от таких "жертв ковида" официально статистику чистили, но можете не сомневаться, их по-прежнему добавляют.
> Можно пруфлинк?
Да ради бога. Вот первый попавшийся: на три "предотвращенных прививкой смерти от ковида" приходится два умерших от поствакцинных осложнений. https://www.mdpi.com/2076-393X/9/7/693/htm
Ради интереса посмотрел некоторые пункты из "разоблачения". Увы, все та же демагогия, не относящаяся к делу, опирающаяся на банальной подмене понятий. "Вирусы не были выделены" (вместо "вирус ковида не был выделен"), вероятность смерти от прививки сравнивается с вероятностью умереть от ковида при положительном тесте (вероятность заразиться ковидом полностью игнорируется, не говоря уже про фальсификацию статистики за счет добавления в нее даже жертв автокатастроф и тяжелых болезней типа рака или диабета - и нет, не надо врать насчет указаний CDC, они не применяются на практике), непонимание базовых принципов извращения ковидной статистики в пропаганде (когда сначала дается ОБЩЕЕ количество "заболевших", а потом приводится показатели смертности от имеющих симптомы) и так далее.
В общем, очередной манифест ковидоверов, чуть более чем полностью построненный на пересказе официальной пропаганды из желтой прессы своими словами. О реальных аргументах скептиков автор не подозревает (ну, либо намеренно ихигнорирует). Скучно, девушки.
Описание системы VAERS верно. Вывод - как минимум странный.
Да, в эту систему попадают предположительные последствия без проверки и доказательства фактической связи. Однако, во-первых, это все-таки пишут не люди с улицы, а врачи. Во-вторых, это ДОБРОВОЛЬНАЯ система, не обязательная. А это означает, что туда не попадает огромное количество реальных случаев. Да, эта система неполностью отражает реальную ситуацию, но не отражает в ОБЕ стороны, а не только в одну, как вам бы хотелось. В-третьих, если официальная статистика уже полтора года применяет в отношении ковида принцип "после значит вследствие", то почему тот же принцип не может применять противостоящая сторона? Или опять принцип "друзьям все, врагам закон"?
На практике система VAERS может использоваться как минимум для проверки относительной ситуации. Вы можете философствовать как угодно, но это не отменяет факта, что количество рапортов о побочках после начала вакцинации от ковида увеличилось на два порядка, причем исключительно за счет побочек от ковидных вакцин.
О том, что данные VAERS соответствуют перекрестным проверкам по другим источникам (в том числе по медицинским изданиям), можно просто помолчать. Ковидоверам это неинтересно.
В упор не понял подход. Правила чтения по-польски в оригинале осваиваются максимум за полчаса безо всяких корявых псевдо-транслитераций. От того, что автор показал в статье, просто кровь из глаз идет. Зачем? Особенно при наличии гуглопереводчика, который дает вполне сносный перевод?
Нет, это не "то же самое слово". Błąd по-польски - ошибка. Слово того же корня, что и, например, błądzić - блуждать, сбиваться с дороги. То слово, что вы имеете в виду, по-польски будет kurwa.
Тем не менее, версия, что хорошие зубы объясняются отсутствием сахара в диете, критики не выдерживает. Во-первых, сахар и аналогичные сладкие углеводы до самого недавнего времени вообще были весьма редкими пищевыми компонентами. Во-вторых, сахар влияет на зубы не телепатическим образом, а создавая богатую углеводами среду в ротовой полости. А для этого требуется липкая или долгоиграющая сосательная субстанция, т.е. что-то типа конфет или иных кондитерских изделий на базе того же меда. Доступ к такого рода лакомствам был в первую очередь у богатых (бедные их могли потреблять разве что по большим праздникам), то есть именно они должны были быть более подверженными его негативным эффектам.
Вот совершенно не обязательно. При нормальной организации труда всегда есть девелоперское окружение, возможно, не обеспечивающее QoS и не гарантирующее избытка ресурсов, но имеющее достаточно ресурсов для упрощенного выделения ВМ-ки для разработчиков. Резерв мощностей под такую разработку всегда можно оставить, благо они много не требуют, а если и требуют, то разрабы могут смириться с медленной работой. А уже когда система сделана, отлажена, продемонстрирована и принята, ее мигрируют в продуктив тем или иным способом. Это стандартная схема в крупных корпорациях.
Не стоит заниматься телепатией, она обычно не работает. ;) У меня разработчик / препод объяснял, что именно ему нужно, я соотносил с резервами и выделял место соответственно. Процедура была сугубо неформальной, но она была - с исследованием запроса, с документированием каждой ВМки (включая DNS-алиасы и ответственных персон), с настройкой бэкапа и т.п. Ситуация, в которой я бы потерял сервер при переезде или переконфигурации сети, была просто немыслимой. И это при том, что я практически в одиночку тащил немаленькую Винтел-инфрастурктуру. Для корректной организации работы больших трудозатрат не нужно, нужен лишь правильный подход.
Правда жизни заключается в том, что потребности средней тестовой машины (грубо - 16-24 Гб ОЗУ, 100-200 Гб на диске и близкие к нулевым потребности CPU) практически неразличимы на фоне железных серверов с терабайтами ОЗУ и сотнями терабайт на дисках. Даже в самых бедных условиях кластер для разработки банально строится на паре серверов low-end и внешнего SATA-дискового массива с подключением по iSCSI. Дисковые иопсы будут низкими, но для демонстрации концепта сгодятся.
И заметьте, я рассуждаю в терминах технологий десятилетней давности. В современных условиях даже это железо не требуется. Любой публично-облачный сервис с удовольствие предоставит ВМ-ки и / или контейнеры любой конфигурации по схеме Pay as you go или аналогичной.
За то, что человек чему-то научился, надо поощрять. Увольнять надо за то, что он явочным порядком, без согласований, предупреждений, авторизации и контроля, занялся перестройкой критичного бизнес-процесса. Это как если бы человек в автомобиле без спросу заменил квадратное, но каменное колесо круглым, но картонным. Крутится оно, конечно, заметно лучше, но лишь до первой лужи.
Видимо, телепатия все-таки не ваш конек. :D Мой опыт работы включает, в числе прочего, многолетнюю работу техлида Винтел-тима в не-российской международной конторе с примерно четырьмя тысячами виртуальных виндовых серверов, парой сотен физических и несколькими десятками тысяч пользователей. А еще у меня в биографии есть многолетняя работа ведущего Винтел-специалиста в российском системном интеграторе, которому по долгу службы пришлось насмотреться на самые разные изумительные конфигурации в инфраструктурах клиентов. И именно на основании этого опыта я и рассуждаю.
Автора положено было наказать за то, что создал риски на пустом месте. Не имеет значения ни предыстория, ни мотивация. Важно, что он своей инициативой создал проблемы в устоявшемся бизнес-процессе, причем так, что никто из отвечающих за него лиц об этом даже не подозревал.
Благими намерениями выложена дорога в ад. Давно уже сказано...
Я не говорю про разработку, я говорю про платформу. Получить виртуалку при правильной организации работы в ИТ - это несколько кликов мышкой в веб-интерфейсе. При чуть менее правильной - пятнадцать минут работы сисадмина. Приватные облака десять лет назад прекрасно делала и ВМВарь, и Майкрософт. У меня такая система была организована в не самом крупном и богатом провинциальном университете (о бюджетах сами догадываетесь) именно в то время. Каждый препод, кто запрашивал виртуалку, ее получал, причем в состоянии высокой готовности. Тот факт, что в данном конкретном банке получить виртуалку в штатной системе виртуализации было невозможно или крайне тяжело, и говорит о состоянии дел в его ИТ. Некомпетентность и непрофессионализм, это единственный диагноз.
Далее, проекты "на попробовать" ни при каких обстоятельствах не должны выходить за рамки "попробовать". Из описания же автора явно следует, что система явочным порядком пошла в продуктив - без тестирования, без фиксации данного факта в реестре систем банка, без одобрения стейкхолдеров, при этом буквально в состоянии "из говна и палок". Такая инициатива похвальна, если она кончается нормальным внедрением. Когда она кончается явочным переносом критичной нагрузки на нечто, сляпанное на коленке, и об этом не подозревает никто из тех, кому положено знать, это неполное соответствие служебным обязанностям. Простой банковских систем означает совершенно конкретные финансовые потери. За такое совершенно справедливо увольняют, даже если катастрофы удалось избежать.
Если у бизнеса есть на что-то заказ, существуют процедуры его реализации, начиная с обсуждения на соответствующих уровнях. Если админы баз данных, CRM-системы (или что у них там) утверждают, что нечто нужное сделать нельзя приниципиально, а некто опровергает это на практике, но админы игнорируют, существуют более высокие уровни, на которых инициируется проект - вплоть до правления банка. Опять же, если этого не делается, если директора отделений жалуются на проблемы, но все кончается пофигизмом службы ИТ, это бардак в организации системы управления.
Часть, относящаяся к внутрибанковским процессам, интересна, спасибо. Но на самом деле этот рассказ - великолепный пример того, почему непрофессионалов и близко нельзя подпускать к построению ИТ-систем, особенно критичных для бизнеса.
Применяемые для построения систем решения не просто скверные - катастрофичные. ПК под столом создает гигантские операционные риски, особенно если на него завязана хоть сколь-нибудь важная система. ПК под столом свойственно дохнуть из-за пыли, перегрева (особенно летом), сбоев электропитания или десктопного железа, не рассчитанного на режим работы 24х365, а также просто от швабры уборщицы тети Маши. Привязка адреса приложения к IP-адресу, да еще и без какого-либо понимания, привязан этот адрес к МАС-у или выдается случайно, тоже находится за гранью добра и зла. Ну и про тот факт, что никто не обеспечивал физический контроль доступа к системам обработки критичных данных, тоже должен был поставить на уши и службу ИТ, и службу безопасности, не говоря уже про внешних аудиторов.
На самом деле задача вполне оперативно решалась созданием виртуальных машин в режиме высокой доступности (ни за что не поверю, что у банка в начала 2010-х не было системы виртуализации), что не требует вообще никаких инвестиций, по крайней мере, немедленных. Тот факт, что этого не было сделано, а автор не получил очень больно по рукам за такие решения независимо от их полезности, может свидетельствовать только о тотальном бардаке в банке.
Верно, ДТП - это прежде всего человеческий фактор (хотя и технический сплошь и рядом встречается - лысая резина, например, или сгоревшая лампочка в поворотнике). Но вообще-то вам будет сугубо параллельно, свалится вам на голову машина в полтонны-тонну весом из-за отказа движков или из-за того, что очередному юному шумахеру моча в голову ударила и он разгнаться решил там, где не стоит. Да, человеческий фактор может исключить полностью автоматизированная система управления всем транспортом без возможности ручного управления. Но до такого решения сейчас как до Луны. В лучшем случае это будет в середине века. В реалистичном сценарии - еще плюс лет двадцать-тридцать.
Убирать провода со столбов каждый раз, чтобы посадить такое такси, это слегка перебор, нэ? :D
Что же до новых улиц, то я как-то ни разу не видел улицы, построенные с нуля. Это может быть разве что на окраинах. Полная переделка всей проводной инфраструктуры на существующей улице может оказаться по стоимости как бы не сопоставимой с альтернативными решениями типа трамвайной линии (с прилагающимися к ней трамваями). Кроме того, убрать трамвайные и троллейбусные провода под землю невозможно в принципе.
Ленинские горы - как бы не самое типовое место в Москве. ;) А антигравитация, увы, от ДТП никак не спасет. Даже оставляя в стороне отказы антигравитационной системы, антигравитация не аннулирует массу и, как следствие, инерцию. С практической точки зрения это будет означать лишь, что машина с отказавшей системой управления будет падать не вертикально, а под углом.
В дополнение к комментарию JediPhilosopher следует также заметить, что в городах летающие машины вообще никаких шансов не имеют. Во-первых, отказ двигателей означает падение аппарата с высоты на головы людей или в гущу дорожного трафика. Результаты сами себе можете представить. В отличие от вертолета, такая хрень даже на авторотации сесть не сможет.
Во-вторых, любая улица современного города - это переплетение проводов практически над всей ее поверхностью, а достаточно часто - еще и древесные кроны. Никакой аппарат там не взлетит и не сядет даже вертикально. Крыши домов тоже исключаются: в подавляющем большинстве они не рассчитаны на дополнительную нагрузку и неустойчивы к повреждениям поверхности (в том числе гидроизоляции). Сейчас даже жильцам на крыши вход воспрещен, чтобы не топтались лишний раз. Даже если дом выдержит нагрузку "аэротакси", крышу придется дополнительно переоборудовать, плюс придется решать вопрос спуска-подъема пассажиров и их прохода по зачастую частной территории - а за чей счет?
Такие аппараты могли бы - при условии обеспечения безопасности - оказаться полезными в пригородном трафике. Но c ресурсом даже полчаса полета на скорости 60 км/ч - не, серьезно?
Нет. На пользовательских устройствах самая лучшая ОС - та, которую изучать вообще не надо. Пользователь не работает с ОС, она ему по большей части сугубо параллельна. Он работает с приложениями. Чем меньше ОС отвлекает на себя внимания от приложений, тем лучше. В идеале пользователь вообще не должен подозревать о ее существовании. Чем больше ее надо "изучать", тем более это скверная пользовательская ОС. Это именно то, чего не понимают разрабы даже домашних версий Линукса.
Без лоха и жизнь плоха. Впрочем, вы все равно ничего не понимаете. Те, кому надо, и госзаказ оформят, и бабла отвалят на святое дело борьбы с вирусом.
Как уже замечено выше, основная причина популярности индийского аутсорса - именно дешевизна. Да, средих них попадаются и очень квалифицированные и вменяемые люди (я с такими работал), с которыми иметь дело - одно удовольствие. Но также среди них масса людей, которым лишь бы отпихнуться от проблемы. Их английский весьма специфичен - зачастую сильно ломаный, с уникальными оборотами, не употребляемыми в стандартном английском, ну и с акцентом у них достаточно тяжко. Я к нему не один год приноравнивался. В целом на фоне европейцев они в большинстве смотрятся тускло.
До сих пор помню, как в 98-м, кажется, фирма Novell отдала написание клиента Нетвари для Винды индийцам. До того клиент был компактный, быстрый и идеально работающий. Но в один прекрасный момент фирма выкатила новую версию, написаную индийцами на Джаве. Мама дорогая... Они потом года полтора или два баги чистили, пока, наконец, хотя бы основные проблемы убрали.
Очередной "специалист", не отличающий сисадмина от сотрудника первой линии техподдержки. Грустно, девушки.
Типичная для кодера узость мышления. В бесконечно-очередной скучный раз ставится знак равенства между кодерством и ИТ. Автор либо не подозревает, либо не желает понимать, сколько в ИТ других профессий - подержка серверной инфраструктуры, сетевики, безопасники, IOT, bigdata... Программеры - лишь одна из профессий, причем далеко не самая массовая. Чтобы в ИТ радикально сменить область деятельности, совершенно не обязательно менять техническую карьеру на административную, тем более что технари в массе склонны к интроверсии, плохо с ней совместимой.
С вами бессмысленно дискутировать. Вам бессмысленно что-то объяснять. Вы воюете не с реальными оппонентами, а с воображаемым врагом, созданным в вашем сознании зомбоящиком. Практически все ваши "возражения" не имеют к действительности никакого отношения, опираясь на банальные подтасовки и передергивания. "Вакцины неэффективны" вместо "вакцины от ковида неэффективны" - типичный пример. Тысячи вас таких, ретрансляторов ящика...
Писать в VAERES может кто угодно. Но подавляющее большинство простых людей даже не подозревает о ее существовании. И даже если мы примем, что там одни ламеры нетянучие, вы полагаете, что они не в состоянии сделать выводы в стиле "укололся - пошел на больничный с высокой температурой"?
У нас на работе уже стандартно и неофицильно дают день больничного после прививки, потому что это ширево вырубает если не всех подряд, то минимум каждого второго. Температура, слабость, ломота в теле - типичные симптомы. Намек: это не Россия и ширяют здесь отнюдь не "Спутником".
> До сих пор никто не показал, что это именно так.
Золотые слова. Не доказал никто, но используется повсеместно - от "статистики" ВОЗ до правительных постановлений о локдаунах. Позитивный результат теста? Все, умер от ковида, даже если был инфаркт или неоперабельный рак в терминальной стадии. Но в случае с прививками, разумеется, все совершенно не так. Даже если через неделю после нее от миокардита умирает подросток или от нетипичного тромбоза молодой здоровый солдат без единой болезни, "связь не установлена". Зато в случае жертвы автокатастрофы связь с ковидом устанавливается мгновенно. В Англии уже дважды от таких "жертв ковида" официально статистику чистили, но можете не сомневаться, их по-прежнему добавляют.
> Можно пруфлинк?
Да ради бога. Вот первый попавшийся: на три "предотвращенных прививкой смерти от ковида" приходится два умерших от поствакцинных осложнений. https://www.mdpi.com/2076-393X/9/7/693/htm
Ради интереса посмотрел некоторые пункты из "разоблачения". Увы, все та же демагогия, не относящаяся к делу, опирающаяся на банальной подмене понятий. "Вирусы не были выделены" (вместо "вирус ковида не был выделен"), вероятность смерти от прививки сравнивается с вероятностью умереть от ковида при положительном тесте (вероятность заразиться ковидом полностью игнорируется, не говоря уже про фальсификацию статистики за счет добавления в нее даже жертв автокатастроф и тяжелых болезней типа рака или диабета - и нет, не надо врать насчет указаний CDC, они не применяются на практике), непонимание базовых принципов извращения ковидной статистики в пропаганде (когда сначала дается ОБЩЕЕ количество "заболевших", а потом приводится показатели смертности от имеющих симптомы) и так далее.
В общем, очередной манифест ковидоверов, чуть более чем полностью построненный на пересказе официальной пропаганды из желтой прессы своими словами. О реальных аргументах скептиков автор не подозревает (ну, либо намеренно ихигнорирует). Скучно, девушки.
Описание системы VAERS верно. Вывод - как минимум странный.
Да, в эту систему попадают предположительные последствия без проверки и доказательства фактической связи. Однако, во-первых, это все-таки пишут не люди с улицы, а врачи. Во-вторых, это ДОБРОВОЛЬНАЯ система, не обязательная. А это означает, что туда не попадает огромное количество реальных случаев. Да, эта система неполностью отражает реальную ситуацию, но не отражает в ОБЕ стороны, а не только в одну, как вам бы хотелось. В-третьих, если официальная статистика уже полтора года применяет в отношении ковида принцип "после значит вследствие", то почему тот же принцип не может применять противостоящая сторона? Или опять принцип "друзьям все, врагам закон"?
На практике система VAERS может использоваться как минимум для проверки относительной ситуации. Вы можете философствовать как угодно, но это не отменяет факта, что количество рапортов о побочках после начала вакцинации от ковида увеличилось на два порядка, причем исключительно за счет побочек от ковидных вакцин.
О том, что данные VAERS соответствуют перекрестным проверкам по другим источникам (в том числе по медицинским изданиям), можно просто помолчать. Ковидоверам это неинтересно.