Хм, простите конечно, но юг приморья еще куда ни шло (хотя курортом я бы его не назвал), но Сахалин то когда стал курортом?
Отсутствие инфраструктуры (транспортной в первую очередь, путешествовать на внедорожниках это конечно прикольно, но не тогда же когда без него толком никуда не попадешь), холодный океан с одной стороны и совсем чуть менее холодный Татарский пролив с другой (+12 вода летом это такой себе курорт), проблема выбраться на материк ( регулярно приходит циклон\метель и Южно-Сахалинск становится недоступен для авиасообщения), весьма бодрящие цены, отсутствие работы за пределами рыбной и нефтяной отрасли (да и с ними не все так уж и хорошо). Есть лыжные курорты, да.
Если сравнивать Южно-Сахалинск с другими городами ДВ он действительно неплох. Но никак не «город-курорт».
Raid10 — это страйп по зеркалам. Да, остальные зеркала будут целы, но вам то какая от этого радость, потерянные данные будут равномерно распределены среди ваших файлов, не говоря уже о крахе файловой системы.
Из полумертвых винтов можно и с кодированием вытащить данные.
В целом тут вы правы. Просто так данные оттуда не восстановить, но бОльшая часть данных все-таки будет доступна, хоть и в поврежденном виде, что для некоторых типов данных может быть и не особо критично (медиафайлы, допустим). Плюс, за счет того, что у нас будет 2 поврежденных винта с одинаковыми данными (а не какое-то количество поврежденных винтов с кодированными _разными_ данными, из которых достать что либо методом «этот сектор не читается с А, прочитается с Б»), сохраняется шанс «собрать» из них достаточно данных, чтобы собрать хотя бы одну рабочую или условно рабочую (с пропусками, забитыми нолями) копию, которую все-таки можно будет накинуть в оригинальный массив и достать все или почти все уже без совсем сложного гемороя с частичным восстановлением. Но конечно тут речь не о падениях вида «сервер упал с полки, на пол»:)
Ой как мне не нравится эта формулировка. Дело в том, что нормальное распределение по количеству вылетевших дисков вполне допускает, что (на больших отрезках времени) будет несколько вылетевших дисков.
Вы немного невнимательно прочитали, мне кажется. Речь идет о промежутке в 1411 дней, за которые бралась выборка, и 35 днях этой выборки (2.48% всех дней) вылетало больше 500 винтов в день. При том, что более 100 винтов в день вылетало в 55.4% дней, а более 200 — в 22.5% дней. То есть это как раз показывает, что в динамике выхода из строя есть всплески, которые выходят за рамки нормального распределения и есть предположение (исходящее из статистики), что по каким-то (однозначно не сказано каким) причинам винты тяготеют к выходу из строя группами, а не единичными устройствами, иначи они высыпались бы равномерно, в соответствии с износом. Кроме них кстати склонность к групповому выходу из строя показывают другие компоненты, но винты в лидерах судя по исследованиям.
Шанс (в Raid10) потерять 2 диска из одного зеркала — тоже не нулевой.
Безусловно, но разница в том, что даже потеряв оба зеркала данные все еще будут живы по крайней мере в остальном массиве, плюс есть шанс из двух полумертвых винтов с копиями все-таки вытащить какую-то часть (возможно очень большую) данных, т.к. это просто обычные копии, там нет никакого хитрого кодирования.
диски начали массово выходить из строя
У меня нет точного ответа на этот вопрос. Более того, не только мы с вами им задаемся. Есть вот такое исследование от китайского университета под названием "What Can We Learn from Four Years of Data Center Hardware Failures?", сделанное совместно и на основании данных Baidu.
В исследовании отмечает корреляция сбоев питания и сбоев жестких дисков. Кроме того, на странице 8 отмечается, что де-факто имеют место batch failures дисков, которые вероятно вызваны какими-то факторами, вроде одинаковых условий и нагрузки:
«We calculated N for each type of components, and Table V shows the results with N= 100, 200 and 500. We find that batch hard drive failures are common. During 2.48% of the days (35 out of 1,411 days), we observe over 500 hard drive failures. We also observe batch failures in components such as memory, power supplies, RAID cards, flash cards and fans.»
Для N=100 процент составляет 55.4, а для N=200 — 22.5%.
А из вкусного могут быть потожировые следы от рук.
Это тараканы любят, грызунам такое вроде не особо интересно.
Да и просто любопытство.
Коробка из сетки за 50 долларов вполне спасет от грызунов. Сталь прогрызать они пока не особо научились.
А не подскажете, где можно почитать про эту надежность? Просто, я 6 лет проработал СХДшником — и только сейчас в первый раз слышу про фантастическую надежность лент.
Ленты не «фантастически» надежны, они просто достаточно надежны для того, чтобы на них можно было полагаться и меньше подвержены случайным деструктивным воздействиям (банальная механическая прочность и отсутствие сложной механики, большинство же падений для жестких дисков фатальны в любом случае), вкупе с возможностью частичного восстановления за куда более разумные деньги, чем чтение данных с блинов мертвого диска, если там с механикой проблемы.
Но да, они все таки требовательны к условиям хранения (влажность в первую очередь).
Что касается исследований, то тут интересная ситуация. HP в 2012 году писал о том, что они взяли 10 кассет из офиса, которые там пролежали 10 лет и все они прочитались без ошибок. Официальный сайт LTO, как и производители оборудования (все полтора землекопа на текущий момент) говорят, что жизненный цикл кассеты равен по крайней мере 30 годам, в течении которых данные будут в сохранности, тот же Dell в своих документах пишет: " Cartridge Life. Durability – 1,000,000 passes on any area of tape, equates to over 20,000 end-to-end passes/260 full tape backups. Archival life – 30 years."
Вот еще исследование за 2015 год от HP, но они тоже заинтересованная сторона.
Настоящие полноценные исследования (кроме опровержения фейка про то, что в 71% случаев восстановление с ленты фейлится, который использовался много где и даже крупными компаниями для продвижения своих продуктов) к сожалению лично мне найти не удалось. Есть рендомные данные из тредов на разных ресурсах вроде этого, где люди с большим опытом хранения не отмечают проблем и говорят что все весьма и весьма надежно.
То есть безусловно сбои бывают и там, и там, нет никакой абсолютной надежности, но хранение больших объемов данных, которые могут понадобиться от «через месяц» до «никогда», но которые надо хранить и иметь возможность оттуда что-то вытащить — тут пленка все-таки пленка дешевле для того же (большого) объема, как раз благодаря относительно дешевым носителям и более низким сопутствующим расходам.
Raid6 это очень неоднозначное решение. 24х18Тб при fault tolerance 2 — это около 400 Тб эффективного хранилища и весьма рискованая система. Шанс потерять 3 диска из 24 один за другим, при том что второй и третий вывалятся в процессе ребилда — это конечно маловероятно, но шанс далеко не нулевой. Кроме того, при потере > 2 дисков мы потеряем вообще все данные. Возить бы такое физически я бы совсем не стал. При потере же обоих кассет с репликами мы потеряем только данные на этой касете, остальные будут в сохранности. В случае зеркалирования из массива тоже можно будет достать остальные данные.
Про выключение — странно. Предположу, что в вашей хранилке не было (не был включен) ресильверинга (когда в свободное время массив читает и пересчитывает чексуммы).
«Хранилка» была кластером с софтом, похожим концептуально на Hadoop с HDFS. Ресильверинга там действительно не было, но хранилка при этом данные не потеряла, т.к. erasure encoding с возможностью потери до 3 чанков и все это размазанное на сотни серверов с anti-affinity per-node per-drive. То есть даже потеряв одну машину целиком, терялся максимум 1 чанк данных из 3 (или даже 4, не помню уже) допустимых к потере для любых данных, что на ней хранились. Ну и быстрая распределенная система ребилда и небольшие диски тоже спасали.
Я не понял, почему диски с тройным резервированием находятся в одном месте. Ничего не мешает разнести.
Это еще сильнее увеличивает косты. 3 сервера вместо одного, каналы между ними, обслуживание и т.д. Ну то есть конечно можно (и нужно), но это еще сильнее стоимость повышает, а я старался привести что-то сравнимое по цене.
А если тихонечко сдохла холодная лента — вы об этом можете узнать только, когда она понадобится, и вовремя не предпринять шагов по созданию копии еще живой ленты
Ленты разных производителей, нормальные условия хранения (20-25 градусов, влажность 40-50) и вероятность выживания одной копии становится очень и очень высока. Да и мышь ленту вряд ли съест, коробка и сама кассета прочные, ничего вкусного, вроде бумаги, для грызунов там нет. Сама по себе лента тихо вряд ли сдохнет, но конечно имеет смысл перечитывать архив раз в 1-2 года. Там же нет тонкой механики никакой, физические воздействия (вроде упала со стола/полки) не страшны, даже если корпус каким-то образом повредится, то пленку можно переставить в другой, плюс кодирование внутри опять же весьма надежное.
Если сильно страшно за неведомые факторы, то можно экран сделать у коробки с кассетами экран из фольги/сетки, чтобы внешние поля не повредили и оно «тихо не умерло», а то мало-ли за стеной построят клинику и там МРТ с ума сойдет:)
На дисках вполне эффективна дедубликация. Если вы пишете архив базы раз в неделю — дедубликация будет очень эффективна.
Дедубликация (аппаратная) часто ломается о шифрование и еще чаще об сжатие с шифрованием. Тут все очень зависит от того, что за данные и в каком виде пишутся, поэтому этот фактор я не учитывал. Хранения какого-нибудь медиаархива в открытом виде это одно, хранение шифрованных пожатых дампов базы — это другое.
Так то оно так, но тут есть некоторый неочевидный эм, изъян.
Современная эксплуатация, если говорить за решения хотя бы среднего размера, по сложности освоения и обширности необходимых знаний весьма велика и весомо так превосходит объем знаний об этой области линейного программиста. И даже не особо линейного. И, возможно, она вообще по объему больше, чем обычный frontend/backend программист знает в рамках обязанностей по созданию продуктов.
Отсюда появляется специализация. Очень сложно хорошо знать две хоть и смежные, но очень объемные и разные области.
И эта самая специализация и приводит нас к тому, что «devops-разработчик» внезапно появляется в команде, потому что хоть кто-то должен обладать полнотой знаний в области «как заставить это правильно работать в рамках инфраструктуры». Люди, которые могут и продукт хороший написать, и качественно его поддерживать конечно существуют, но их 1. мало, 2. они стоят ну очень много денег и как следствие нанимаются каким-нибудь гуглом на позицию SRE, о которой ниже.
Есть еще вариант купить экспертизу на стороне, но проблемы как таковой это не решает.
Кстати Google эту проблему компетенций осознал весьма давно и вместо внедрения DevOps придумал структуры работы, где появляется позиция SRE, на которую нанимаются те редкие люди, которые неплохо понимают и в программирование как таковое, в рамках создания продукта, и в эксплуатацию этих продуктов. Вкупе с жесткими правилами и условиями попадания продукта в прод это в целом позволяет им неплохо и стабильно работать. Что конечно не исключает наличия больших выделенных команд, которые занимаются более специализированными вещами — сервера, сети, базы, автоматизация и вот это все.
То есть нет, devops — это далеко не классический админ, его область ответственности и знаний гораздо шире. DevOps как методология в целом не исключает наличие в команде человека, который специализируется на эксплуатации. Ни у кого же не вызывает удивление, что frontend/backend/mobile/embedded программисты имеют специализацию, так почему не может быть еще одной, с фокусом на интеграцию и эксплуатацию?
Более того, эта методология в реальной жизни в целом не исключает и команду поддержки инфраструктуры. В любом случае, работы в эксплуатации много и вопрос ее распределения каждая компания решает как может.
Вероятно все сильно зависит от нагрузки и power cycle.
Был у меня году в 2012 пара кластеров с суммарным количеством шпенделей в несколько тысяч. Вполне обычных по тем временам и относительно надежных дисков объемом по 1-2 Тб.
И вот однажды, по печальному стечению обстоятельств, один из кластеров с чуть более чем 2к шпенделей ребутнулся по питанию целиком. И один этот ребут не пережило порядка 50 дисков, которые до этого работали без нареканий. Вроде как не много, но еще 25-30 дисков менялись стабильно в течении каждого месяца, это уже практически ритуалом было, посмотреть в мониторинг, перетестировать и открыть тикет ребятам в ДЦ на замену.
И это реально было проблемой. Шанс потерять хотя бы 1 диск, ребутнув машину на 4 диска был весьма чувствительно ненулевым. Причем в ДЦ не было проблем с температурой, стойки не били, сервера не возили (отдельная кстати тема, перевозка выключенных серверов, даже максимально аккуратно — это всегда получение какой-то части мертвых дисков на выходе).
В общем, с точки зрения индивидуальной надежности HDD так себе носитель. Вот статистика на 2020 год по «идеальным условиям бэкапного хранилища в ДЦ», которую каждый год публикует Backblaze — www.backblaze.com/blog/backblaze-hard-drive-stats-for-2020
В среднем AFR гуляет вокруг 1%. Вроде не так уж и много (и плохо), но по их статистике AFR выше для первых нескольких месяцев использования и для некоторых моделей (топовые 18TБ Seagate имеют AFR в 12.5%).
В общем, архивный сторадж в идеальных условиях хорошего ДЦ, стабильной невысокой нагрузки, без перемещений и выключений питания жесткие диски вполне переживают и успешно, конечно же, используются (особенно если система внутри реплицирует данные с высокой надежностью).
В менее идеальных условиях — бэкапы с возможностью перемещения носителей в пространстве, отклонения по теплу (они весьма чувствительны и +10 градусов к номиналу дают статистически ощутимый прирост сбоев), небольшое количество дисков, power cycles, RAIDы отличные от 0/10 — это уже весьма лотерейная затея. Решение на пленочных кассетах для хранения холодного архива вполне может оказаться надежнее и дешевле в перспективе, если речь идет о сотнях ТБ.
Кстати можно даже примерно прикинуть стоимость на условные 200 ТБ архива. Сырой емкости при трехкратной репликации нужно 600 Тб. Представим что софт и люди для настройки этой весьма сложной информационной системы у нас бесплатные. Это 24 18ТБ диска, около 400 долларов за диск — 9600 долларов. Пусть еще 2000 стоит корзина, контроллер и вот это все. Итого — 11600.
Для кассет — LTO-8 стример 3500 долларов, сырая емкость кассеты — 12 Тб, нужно 17 кассет. Стоимость кассеты — около 75 долларов (по гуглу из наличия во втором попавшемся магазине). Итого — 1275 долларов за кассеты или 4875 долларов всего. Более чем в 2 раза дешевле. Надежность кассеты, лежащей на полке, вполне высока, но допустим мы параноики и пишем на 2х разных стримерах (мало ли), по 1 экземпляру на каждом и развозим копии в разные места, а то мало ли. Получается 9750 долларов. Все еще дешевле 11600 за хранилище на HDD, которое более уязвимо — данные физически в одном месте, ДЦ может сгореть/закрыться, сервер может понадобиться перевести и его уронят грузчики, а стопка на 24 винта, даже если их вынуть — весьма тяжелая (и скользкая) штука. В общем, для холодного бэкапа лента все еще более чем конкурентна и в плане стоимости, и в плане надежности. И емкость наращивать сильно дешевле.
Ну, эм, я говорил про 3060 Ti, да. 3060 действительно в продаже нет нигде вообще. По крайней мере пока-что. Кроме редких барыг в некоторых странах, которые откуда-то уже добыли карты на продажу.
На Wikipedia.
Строка «Expected tape durability, end-to-end passes». В зависимости от поколения от 9600 для первого до 20000 для шестого и выше.
Для полной записи всей емкости требуется от 48 до 208 полных проходов в зависимости от поколения.
Для LTO-5 это 80 проходов на полную запись и 16000 проходов предполагаемого ресурса, то есть порядка 200 полных записей (или полного чтения, все равно мотать же). Не особо надолго хватит.
Шутки ради, можно прям библиотеку купить за 2000 евро. Рабочую. На 678 кассет LTO-2:)
Но вообще, LTO поколения до 9-го совместимы на 2 поколения назад. То есть LTO-5 может работать с носителями LTO-4 и LTO-3. И такой драйв (LTO-5) сейчас можно найти за 250-400 евро. Приводы же LTO-7, последние совместимые с 5, будут доступны еще весьма и весьма долгое время (а сейчас ну слишком дороги), которого более чем хватит, чтобы накопить и неторопясь купить себе резервный совместимый драйв.
Как обладатель Blue Card могу сказать, что голубые карты не всех стран одинакого полезны.
ЧР одна из стран, где пользы от нее минимум. Она выдается на очень короткий срок (2 года, в сравнении с 3 в Польше или 4 в Германии), не дает преимуществ при получении ПМЖ (в Германии она сильно сокращает срок с 5 лет до 22 месяцев при наличии немецкого B1 или до 33 месяцев при немецком А1), а ее трансфер — действительно весьма замороченная штука, к тому же принимающая страна обычно требует минимум 2 года проживания у себя до ПМЖ, то есть тайм-слот «до ПМЖ», когда имеет смысл дергаться и транферить карту — не более 3 лет проживания с момента получения первой карты, но не менее 18 (вроде) месяцев, после которых стаж вообще становится можно перенести.
В итоге получается, что трансфер, который не растянет время до получения ПМЖ, разумен только в течении полутора лет, с 19 по 35 (37 в случае с Германией) месяц обладания голубой картой. После этого смысл несколько теряется и проще дождаться ПМЖ, а потом уже уезжать, если хочется. Правда дергаться после 5+ лет в одной стране вряд ли захочется (все таки страны ЕС не отличаются совсем уж кординальным образом), разве что там совсем не понравится, но тогда я думаю есть смысл уехать сразу после первых 18 месяцев.
Уточнение — я опять перепутал series S и X. Речь конечно же про X, старшую модель.
Но в плане разницы в цене между S и 3060 я внезапно оказался прав, там как раз примерно 4 раза, но и 3060 конечно мощнее:)
Я не уверен за ситуацию в СНГ, но в ЕС оно несколько по-другому (да и в США, судя по тому, что я вижу).
За 700 баксов 3060 в свободной продаже я не видел уже очень давно. В каталогах они есть, но по факту их нет в наличии никогда.
Карты из наличия меньше чем за 1300 я не нашел где купить, по крайней мере в Польше\Германии, т.к. они есть только у перекупов. Можно попробовать заказать где-нибудь и подождать произвольное время без гарантий (месяц, два, как повезет, многие магазины вообще заказы не принимают на них). В магазинах в наличии из современных карт, по крайней мере в Польше, есть AMD 6800XT за 2 тысячи долларов. Еще месяц назад за эти деньги можно было взять из наличия в магазине 3090.
Кроме того, игровой ПК это не только карточка, это еще хотя бы 500 долларов на минимальные процессор+материнка+память, если уже есть дисплей, корпус, БП и прочее, чтобы эта 3060 полноценно работала.
Итого, по минимуму, если сильно поискать, прямо сейчас или консоль за 700 новая с гарантией завтра курьером, или карточка за 1300 у перекупов с аукциона с шансом проблем + 500 баксов за остальное новое из магазина, итого разница в 2.5 раза. Кстати, за 2200 можно взять ноут с 3060 от MSI, по крайней мере прямо сейчас он есть в наличии на Amazon DE.
Далеко не все готовы или ждать месяцами, или связываться с аукционами и перекупами и это на самом деле большая проблема. Купить Xbox сейчас проще и быстрее. По крайней мере в Польше. В Германии Xbox-ов тоже нет.
На самом деле для Nvidia смысл в этом есть, и неплохой.
Рынок потребительских видеокарт для геймеров все еще достаточно крупный и прибыльный. При этом, есть не менее крупный и конкурентный рынок игровых приставок, где правит балом компания AMD, которая поставляет чипы для 2 из 3 крупнейших платформ, которые как раз обновились (есть еще Nintendo, но там совсем другая ситуация, а сами чипы старые, слабые и дешевые).
Мощность приставок последнего поколения примерно соответствует 3060, при этом сами приставки, по крайней мере Xbox Series S, есть в наличии и стоят в 4(!!) раза дешевле, чем просто 3060.
Я не в России, но в переводе на доллары прямо сейчас можно или купить Xbox с двумя играми или игрой + доп. контроллер за 700 долларов c доставкой завтра домой (что я сделал неделю назад), или 3060 за 800 в некоторых магазинах, где она иногда появляется в наличии с шансом ожидания от пары дней до пары месяцев.
Сейчас вот загуглил, вроде как есть в одном магазине 10 штук с поставкой 25 числа, но я почти уверен, что они все выкуплены уже и звонить бессмысленно. У перекупов 3060 в продаже нет, но есть 3060ti за 1300 долларов или 3070 за 1600.
Учитывая, что линейка игр для того же XBox весьма сильно повторяет линейку игр длы PC, а цены в на игры в steam и xbox store отличаются мало (а в Европе\США это так), то при сохранении ситуации, когда сборка игрового компьютера будет в 3-4 раза дороже покупки консоли той же мощности, это просто убьет рынок игровых PC, и когда бум майнинга пройдет, то продавать карты просто станет некому, у всех уже будут новые Xbox или PS5, поставки которых начинают налаживаться. И вот это уже прямая угроза будущему Nvidia.
На сайте что вы привели в роли подтверждения прямо написано обратное — https://searchads.apple.com/privacy/
Они не торгуют данными с девайсов и не используют их в рекламе. Да, я верю в написанное, потому что туда под лупой смотрит очень много людей в попытках доказать обратное, чтобы пойти с этим в суд и пошатать Apple.
Это не новость, Perforce весьма распространен в геймдеве по нескольким причинам:
1. Игровой проект чаще всего — гигантская монорепа, менеджить которую в гите крайне сложно.
2. Perforce из коробки хорошо умеет в бинари (да, есть Git LFS, но не так давно и не особо стабильно, когда тебе надо таскать и синкать гигабайты и терабайты бинарного контента), а игровой проект — это тонны бинарных данных, их на порядки больше по объему, чем непосредственно кода.
3. Возможность таскать проект к себе не целиком, что крайне актуально, когда его размер может быть в несколько терабайт. Partial checkout/commit и вот это все.
4. Система бранчей другая. Есть еще всякие штуковины типа «лока на директорию», аудит и подобное.
В общем — для определенных кейсов, в частности для геймдева, это удобная штука.
времени было много чтобы подождать пока файрфокс или опенофис соберутся
Офтопик конечно, но я тут проапгрейдился до 5950x со старенького Xeon и в общем-то сборка совершенно перестала напрягать. Всякая мелочевка собирается вообще мгновенно, apt индексы дольше пересчитывал, Firefox ~ за 9 минут от запуска emerge, а вот Chromium да, хром тот еще тормоз.
На счет готовности — ну очевидно я на нем не играю (в виртуалке играю, куда видюха проброшена), но вот в плане поработать все-таки удобнее, не смотря на WSL в винде. А мак просто выйдет безумно дорого в серьезной конфигурации. За коммерческий софт — да, пожалуй, но каждый выбирает инструмент под свои потребности:)
Ну не всегда.
Я некоторое время назад поменял Fedora на Gentoo, потому что несколько устал бороться с дефолтными конфигами и страным поведением системы в моих кейсах, связанных в основном с виртуализацией, несколькими видео- и звуковыми картами (pulse почему-то крайней нестабильно работал и вел себя странно, причем апдейт версии в рамках релиза федоры не помогал, возможно что-то с конфигами дефолтными было не так...), использованием Enlightenment в роли WM и отсутствия необходимости в полном пакете софта из гнома или kde и т.д. Ubuntu как вариант не рассматривал, она норм конечно, но я боюсь еще одна починка поломавшегося об цикличесую зависимость apt меня просто добьет. Случается это конечно весьма не часто (пожалуй раза 3 всего было за те 14 лет, что я ей пользовался так или иначе), но сама возможность такой ситуации меня несколько нервирует. Я если что лучше ручками поправлю или соберу, чем буду бороться с dependency cycling или подобным.
Но в прод да, я бы пожалуй ее не потащил, слишком много гемороя и мало смысла. Да и в большинстве случаев там все равно все в контейнерах, эксплуатационные расходы не окупят всей суеты.
Совершенно внезапно инженеры решают в первую очередь бизнесовые задачи с помощью инженерных навыков, а уже потом, иногда, развлекаются инженерией ради инженерии.
Вообще вся компания в первую очередь решает бизнесовые задачи, если это коммерческая компания, а не университет или RnD лаборатория, которая может себе позволить иногда заниматься инженерией ради инженерии в рамках исследований. Хотя их конечно потом все равно как-то коммерциализировать надо.
Нет никакого «бизнес решает бизнес», инженеры в коммерческой компании это не black box, в который с одной стороны грузят бабки тоннами, а с другой стороны он выдает идеальные инженерные продукты, которые берут какие-нибудь сейлзы и пытаются продать, это симбиоз специалистов, которые умеют делать много чего инженерного, но при этом не забывают, что их продукт придется продавать в каком-то виде.
Гугл при этом во многом похож именно на компанию, в которой engineering excellence (причем без customer experience) стоит во главе угла. Больших проблем это не создает потому, что есть стабильный поиск и относительно небольшая команда, которая занимается именно парой реклама+поиск и эта пара, как отличный печатный станок, приносит такое количество денег, которым можно закрыть любые коммерчески провальные эксперименты.
При этом, у гугла к сожалению за последнее время не получилось успешно запустить ни одного коммерческого продукта в новой для них нише и фейлились они не потому, что они технически плохо сделаны, а потому, что в них только technical excellence и есть, а вот про пользователя забыли. И кладбище закрытых продуктов продолжает шириться.
В целом ситуация то вполне объяснима — начиная именно с найма, они отбирают инженеров с хорошими фундаментальными знаниями, при этом не уделяя практически никакого внимания реальным навыкам решения реальных продуктовых проблем. Такие люди могут делать супер-крутые штуки, но им нужны не менее крутые визионеры и менторы уже над ними, которые будут задавать правильное направление и помогать правильно применять свои инженерные знания. Причем это должны быть весьма неординарные и сильные люди. А вот их уже нанять на несколько порядков сложнее. При том, что их нужно много, задача может стать крайне трудной, фактически близкой к невыполнимой.
Поэтому да, получается много сильных инженеров, которые делают технически крутые штуки, но при этом пользователи почему-то ими пользоваться не особо то хотят.
Пожалуй, из последнего в этом плане весьма показательна Stadia, которая фактически является иллюстрацией «как имея все технические компетенции, огромный бюджет и собственную общемировую маркетинговую машину провалить проект».
Запрет сняли. Более того, правила H1B изменились, и там теперь вместо лотереи сортировка по зарплате.
То есть начиная со следующего апрельского отбора, будут просто выдавать визы тем, кому предлагается максимальная зарплата, начиная с максимальной и по уменьшению, пока не закончится лимит виз или пока предлагаемая зарплата не станет ниже ~85К в год, что является нижним лимитом. Это очень сильно повышает шанс получения визы, если приглашает крупная компания, которая готова платить хорошие деньги. И машет ручкой галерам, которые выгребают львиную долю виз.
Всего виз в год — 65 тысяч.
При этом только крупные бодишопы типа Infosys, TATA и Deloitte, Accenture и прочие в сумме подавали под пол миллиона заявок, при этом предлагая среднюю зарплату, к примеру, у Infosys — 83к, у TATA — 70к, а они крупнейшие просители, почти 200 тысяч заявок, и нет ни одного «консалтинга», который бодишоп на самом деле, который, прося больше 10 тысяч виз предлагал бы более 92 тысяч в год в среднем.
Для сравнения, реальные среди реальных продуктовых компаний больше всего просят IBM India (35 тысяч заявок со средней 77к) и Microsoft (34 тысячи заявок со средней в 136к). За ними идет Google с 26 тысячами заявок и средней почти в 145к. Если посмотреть в детализации, то бОльшая часть предлагаемых зарплат ниже 200к. В общем, если не хочется лотереи, нужно пробиваться на позицию с компенсацией 200+, что почти гарантирует получение H1B.
А что, вы сторонник приницпа «сначала добейся»?
Я вот тоже с гуглерами работал достаточно много, даже на гугл работал контрактором через третью фирму, но с возможностью посмотреть внутрь, доступами и т.д. и на собеседования туда ходил, и вот на этой серии «технических собеседований» был.
Впечатления средние. Безусловно там есть люди с руками и головой (кто-то же все это делает, там есть очень крутые штуки), там отличный HR департамент (внешний по крайней мере), в столовой в целом неплохо кормят, да.
Но компетенции и внутренняя структура большинства на типичном уровне крупной технологической компании. Добиваться решения месяцами — легко. Пойти по цепочке технической эскалации и обнаружить что там на самом деле 1. не знают, 2. не хотят знать — легко.
Короче обычная большая контора. Хорошо, если повезет и хватит скилов попасть в те проценты людей, которые действительно занимаются крутыми вещами. Но шанс, скажем так, весьма не велик.
Да, отбор там настроен на решение вот таких вот общих технических задачек и это очень чувствуется, когда человек в общем то решать задачки на алгоритмы и подобное умеет, а вот конкретную бизнес-задачу чет как-то не очень. Поэтому да, тебе с легкостью могут рассказать как обходить граф и какие мат. теории и приемы существуют на этот счет, но вот пойти и подебажить компонент или подумать над решением конкретной технической проблемы, с которой сталкиваются кастомеры — тут начинается что-то удивительное и люди как-то оперативненько сливаются, потому что там внезапно не только теория графов нужна, а надо, совершенно неожиданно, что-то руками делать, думать другими абстракциями и вообще вписывать продукт в бизнес-ожидания и работать на удовлетворение кастомера, а не собственного любопытства.
Это не значит, что там люди глупые (совершенно нет), или плохие (тоже нет), но сама система так построена, что люди, работающие в ней, создают весьма интересные технические решения, которые повернуты к кастомеру задней полусферой.
Ну это как очень неплохой Google Cloud, у которого нет кастомерской поддержки, куда можно хотя бы написать, так что если что-то пойдет не так, ну… ой. А там иногда идет что-то не так. Поэтому везде сквозит ощущение про «тут не для тебя все, а чтобы технически круто было».
Про интерфейсы я вообще молчу, оно подлагивает, местами крайне медленно работает и совершенно не отзывчивое даже на Ryzen 9 5950x, аппаратным ускорением отрисовки через GTX 1650 и полугигабитным интернет-каналом. Я хрен знает, как написать такой интерфейс, чтобы он ТАК себя вел. Или как придумать решение, когда у при удалении бакета в сторадже из UI он начинает удалять все объекты внутри бакета рекурсивно (что в целом правильно). Даже если их там миллион (а вот это уже не очень). По объкту на запрос (вообще что-то странное). Что ожидаемо подвешивает браузер, да. Вообще, я думаю у многих найдется история такого порядка про гугловые продукты.
Так что, я совершенно согласен и с 0xd34df00d, и с UnclShura. Рваться туда по сути смысла очень уж большого нет, в подавляющем большинстве случаев в компаниях F500 будет +- так же, даже с опционами. Но да, мерча из гугла не будет, хвастаться будет сложно:)
Также для верхнеуровневых чипсетов Opti была заявлена поддержка двухпроцессорных систем, но обнаружить выпущенные на них платы с двумя сокетами не удалось.
Зацепила меня эта фраза, решил поискать и… нашел такие!
Материнская плата Acer J3.
Карта с процессорами (по словам автора, как раз Socket 4):
Бэкплейн:
Все это на чипсетах Opti 82c696 и Opti 82c693 соответственно.
По словам автора поста на форуме:
«It mainly featured in the the Acer Power and Acros line of computers, but was also found in other OEM systems like AMBRA, Apricot and perhaps a few Japanese makes as well. Several different CPU cards are available: single socket3, single socket4, dual socket4, single socket5 and dual socket5. As far as I know they are all based around OPTi chipsets, though I did hear a rumor a Triton board may exist.»
Отсутствие инфраструктуры (транспортной в первую очередь, путешествовать на внедорожниках это конечно прикольно, но не тогда же когда без него толком никуда не попадешь), холодный океан с одной стороны и совсем чуть менее холодный Татарский пролив с другой (+12 вода летом это такой себе курорт), проблема выбраться на материк ( регулярно приходит циклон\метель и Южно-Сахалинск становится недоступен для авиасообщения), весьма бодрящие цены, отсутствие работы за пределами рыбной и нефтяной отрасли (да и с ними не все так уж и хорошо). Есть лыжные курорты, да.
Если сравнивать Южно-Сахалинск с другими городами ДВ он действительно неплох. Но никак не «город-курорт».
В целом тут вы правы. Просто так данные оттуда не восстановить, но бОльшая часть данных все-таки будет доступна, хоть и в поврежденном виде, что для некоторых типов данных может быть и не особо критично (медиафайлы, допустим). Плюс, за счет того, что у нас будет 2 поврежденных винта с одинаковыми данными (а не какое-то количество поврежденных винтов с кодированными _разными_ данными, из которых достать что либо методом «этот сектор не читается с А, прочитается с Б»), сохраняется шанс «собрать» из них достаточно данных, чтобы собрать хотя бы одну рабочую или условно рабочую (с пропусками, забитыми нолями) копию, которую все-таки можно будет накинуть в оригинальный массив и достать все или почти все уже без совсем сложного гемороя с частичным восстановлением. Но конечно тут речь не о падениях вида «сервер упал с полки, на пол»:)
Вы немного невнимательно прочитали, мне кажется. Речь идет о промежутке в 1411 дней, за которые бралась выборка, и 35 днях этой выборки (2.48% всех дней) вылетало больше 500 винтов в день. При том, что более 100 винтов в день вылетало в 55.4% дней, а более 200 — в 22.5% дней. То есть это как раз показывает, что в динамике выхода из строя есть всплески, которые выходят за рамки нормального распределения и есть предположение (исходящее из статистики), что по каким-то (однозначно не сказано каким) причинам винты тяготеют к выходу из строя группами, а не единичными устройствами, иначи они высыпались бы равномерно, в соответствии с износом. Кроме них кстати склонность к групповому выходу из строя показывают другие компоненты, но винты в лидерах судя по исследованиям.
Безусловно, но разница в том, что даже потеряв оба зеркала данные все еще будут живы по крайней мере в остальном массиве, плюс есть шанс из двух полумертвых винтов с копиями все-таки вытащить какую-то часть (возможно очень большую) данных, т.к. это просто обычные копии, там нет никакого хитрого кодирования.
У меня нет точного ответа на этот вопрос. Более того, не только мы с вами им задаемся. Есть вот такое исследование от китайского университета под названием "What Can We Learn from Four Years of Data Center Hardware Failures?", сделанное совместно и на основании данных Baidu.
В исследовании отмечает корреляция сбоев питания и сбоев жестких дисков. Кроме того, на странице 8 отмечается, что де-факто имеют место batch failures дисков, которые вероятно вызваны какими-то факторами, вроде одинаковых условий и нагрузки:
Для N=100 процент составляет 55.4, а для N=200 — 22.5%.
Это тараканы любят, грызунам такое вроде не особо интересно.
Коробка из сетки за 50 долларов вполне спасет от грызунов. Сталь прогрызать они пока не особо научились.
Ленты не «фантастически» надежны, они просто достаточно надежны для того, чтобы на них можно было полагаться и меньше подвержены случайным деструктивным воздействиям (банальная механическая прочность и отсутствие сложной механики, большинство же падений для жестких дисков фатальны в любом случае), вкупе с возможностью частичного восстановления за куда более разумные деньги, чем чтение данных с блинов мертвого диска, если там с механикой проблемы.
Но да, они все таки требовательны к условиям хранения (влажность в первую очередь).
Что касается исследований, то тут интересная ситуация. HP в 2012 году писал о том, что они взяли 10 кассет из офиса, которые там пролежали 10 лет и все они прочитались без ошибок. Официальный сайт LTO, как и производители оборудования (все полтора землекопа на текущий момент) говорят, что жизненный цикл кассеты равен по крайней мере 30 годам, в течении которых данные будут в сохранности, тот же Dell в своих документах пишет: " Cartridge Life. Durability – 1,000,000 passes on any area of tape, equates to over 20,000 end-to-end passes/260 full tape backups. Archival life – 30 years."
Вот еще исследование за 2015 год от HP, но они тоже заинтересованная сторона.
Настоящие полноценные исследования (кроме опровержения фейка про то, что в 71% случаев восстановление с ленты фейлится, который использовался много где и даже крупными компаниями для продвижения своих продуктов) к сожалению лично мне найти не удалось. Есть рендомные данные из тредов на разных ресурсах вроде этого, где люди с большим опытом хранения не отмечают проблем и говорят что все весьма и весьма надежно.
То есть безусловно сбои бывают и там, и там, нет никакой абсолютной надежности, но хранение больших объемов данных, которые могут понадобиться от «через месяц» до «никогда», но которые надо хранить и иметь возможность оттуда что-то вытащить — тут пленка все-таки пленка дешевле для того же (большого) объема, как раз благодаря относительно дешевым носителям и более низким сопутствующим расходам.
Да, конечно же Raid 1/10.
Raid6 это очень неоднозначное решение. 24х18Тб при fault tolerance 2 — это около 400 Тб эффективного хранилища и весьма рискованая система. Шанс потерять 3 диска из 24 один за другим, при том что второй и третий вывалятся в процессе ребилда — это конечно маловероятно, но шанс далеко не нулевой. Кроме того, при потере > 2 дисков мы потеряем вообще все данные. Возить бы такое физически я бы совсем не стал. При потере же обоих кассет с репликами мы потеряем только данные на этой касете, остальные будут в сохранности. В случае зеркалирования из массива тоже можно будет достать остальные данные.
«Хранилка» была кластером с софтом, похожим концептуально на Hadoop с HDFS. Ресильверинга там действительно не было, но хранилка при этом данные не потеряла, т.к. erasure encoding с возможностью потери до 3 чанков и все это размазанное на сотни серверов с anti-affinity per-node per-drive. То есть даже потеряв одну машину целиком, терялся максимум 1 чанк данных из 3 (или даже 4, не помню уже) допустимых к потере для любых данных, что на ней хранились. Ну и быстрая распределенная система ребилда и небольшие диски тоже спасали.
Это еще сильнее увеличивает косты. 3 сервера вместо одного, каналы между ними, обслуживание и т.д. Ну то есть конечно можно (и нужно), но это еще сильнее стоимость повышает, а я старался привести что-то сравнимое по цене.
Ленты разных производителей, нормальные условия хранения (20-25 градусов, влажность 40-50) и вероятность выживания одной копии становится очень и очень высока. Да и мышь ленту вряд ли съест, коробка и сама кассета прочные, ничего вкусного, вроде бумаги, для грызунов там нет. Сама по себе лента тихо вряд ли сдохнет, но конечно имеет смысл перечитывать архив раз в 1-2 года. Там же нет тонкой механики никакой, физические воздействия (вроде упала со стола/полки) не страшны, даже если корпус каким-то образом повредится, то пленку можно переставить в другой, плюс кодирование внутри опять же весьма надежное.
Если сильно страшно за неведомые факторы, то можно экран сделать у коробки с кассетами экран из фольги/сетки, чтобы внешние поля не повредили и оно «тихо не умерло», а то мало-ли за стеной построят клинику и там МРТ с ума сойдет:)
Дедубликация (аппаратная) часто ломается о шифрование и еще чаще об сжатие с шифрованием. Тут все очень зависит от того, что за данные и в каком виде пишутся, поэтому этот фактор я не учитывал. Хранения какого-нибудь медиаархива в открытом виде это одно, хранение шифрованных пожатых дампов базы — это другое.
Современная эксплуатация, если говорить за решения хотя бы среднего размера, по сложности освоения и обширности необходимых знаний весьма велика и весомо так превосходит объем знаний об этой области линейного программиста. И даже не особо линейного. И, возможно, она вообще по объему больше, чем обычный frontend/backend программист знает в рамках обязанностей по созданию продуктов.
Отсюда появляется специализация. Очень сложно хорошо знать две хоть и смежные, но очень объемные и разные области.
И эта самая специализация и приводит нас к тому, что «devops-разработчик» внезапно появляется в команде, потому что хоть кто-то должен обладать полнотой знаний в области «как заставить это правильно работать в рамках инфраструктуры». Люди, которые могут и продукт хороший написать, и качественно его поддерживать конечно существуют, но их 1. мало, 2. они стоят ну очень много денег и как следствие нанимаются каким-нибудь гуглом на позицию SRE, о которой ниже.
Есть еще вариант купить экспертизу на стороне, но проблемы как таковой это не решает.
Кстати Google эту проблему компетенций осознал весьма давно и вместо внедрения DevOps придумал структуры работы, где появляется позиция SRE, на которую нанимаются те редкие люди, которые неплохо понимают и в программирование как таковое, в рамках создания продукта, и в эксплуатацию этих продуктов. Вкупе с жесткими правилами и условиями попадания продукта в прод это в целом позволяет им неплохо и стабильно работать. Что конечно не исключает наличия больших выделенных команд, которые занимаются более специализированными вещами — сервера, сети, базы, автоматизация и вот это все.
То есть нет, devops — это далеко не классический админ, его область ответственности и знаний гораздо шире. DevOps как методология в целом не исключает наличие в команде человека, который специализируется на эксплуатации. Ни у кого же не вызывает удивление, что frontend/backend/mobile/embedded программисты имеют специализацию, так почему не может быть еще одной, с фокусом на интеграцию и эксплуатацию?
Более того, эта методология в реальной жизни в целом не исключает и команду поддержки инфраструктуры. В любом случае, работы в эксплуатации много и вопрос ее распределения каждая компания решает как может.
Был у меня году в 2012 пара кластеров с суммарным количеством шпенделей в несколько тысяч. Вполне обычных по тем временам и относительно надежных дисков объемом по 1-2 Тб.
И вот однажды, по печальному стечению обстоятельств, один из кластеров с чуть более чем 2к шпенделей ребутнулся по питанию целиком. И один этот ребут не пережило порядка 50 дисков, которые до этого работали без нареканий. Вроде как не много, но еще 25-30 дисков менялись стабильно в течении каждого месяца, это уже практически ритуалом было, посмотреть в мониторинг, перетестировать и открыть тикет ребятам в ДЦ на замену.
И это реально было проблемой. Шанс потерять хотя бы 1 диск, ребутнув машину на 4 диска был весьма чувствительно ненулевым. Причем в ДЦ не было проблем с температурой, стойки не били, сервера не возили (отдельная кстати тема, перевозка выключенных серверов, даже максимально аккуратно — это всегда получение какой-то части мертвых дисков на выходе).
В общем, с точки зрения индивидуальной надежности HDD так себе носитель. Вот статистика на 2020 год по «идеальным условиям бэкапного хранилища в ДЦ», которую каждый год публикует Backblaze — www.backblaze.com/blog/backblaze-hard-drive-stats-for-2020
В среднем AFR гуляет вокруг 1%. Вроде не так уж и много (и плохо), но по их статистике AFR выше для первых нескольких месяцев использования и для некоторых моделей (топовые 18TБ Seagate имеют AFR в 12.5%).
В общем, архивный сторадж в идеальных условиях хорошего ДЦ, стабильной невысокой нагрузки, без перемещений и выключений питания жесткие диски вполне переживают и успешно, конечно же, используются (особенно если система внутри реплицирует данные с высокой надежностью).
В менее идеальных условиях — бэкапы с возможностью перемещения носителей в пространстве, отклонения по теплу (они весьма чувствительны и +10 градусов к номиналу дают статистически ощутимый прирост сбоев), небольшое количество дисков, power cycles, RAIDы отличные от 0/10 — это уже весьма лотерейная затея. Решение на пленочных кассетах для хранения холодного архива вполне может оказаться надежнее и дешевле в перспективе, если речь идет о сотнях ТБ.
Кстати можно даже примерно прикинуть стоимость на условные 200 ТБ архива. Сырой емкости при трехкратной репликации нужно 600 Тб. Представим что софт и люди для настройки этой весьма сложной информационной системы у нас бесплатные. Это 24 18ТБ диска, около 400 долларов за диск — 9600 долларов. Пусть еще 2000 стоит корзина, контроллер и вот это все. Итого — 11600.
Для кассет — LTO-8 стример 3500 долларов, сырая емкость кассеты — 12 Тб, нужно 17 кассет. Стоимость кассеты — около 75 долларов (по гуглу из наличия во втором попавшемся магазине). Итого — 1275 долларов за кассеты или 4875 долларов всего. Более чем в 2 раза дешевле. Надежность кассеты, лежащей на полке, вполне высока, но допустим мы параноики и пишем на 2х разных стримерах (мало ли), по 1 экземпляру на каждом и развозим копии в разные места, а то мало ли. Получается 9750 долларов. Все еще дешевле 11600 за хранилище на HDD, которое более уязвимо — данные физически в одном месте, ДЦ может сгореть/закрыться, сервер может понадобиться перевести и его уронят грузчики, а стопка на 24 винта, даже если их вынуть — весьма тяжелая (и скользкая) штука. В общем, для холодного бэкапа лента все еще более чем конкурентна и в плане стоимости, и в плане надежности. И емкость наращивать сильно дешевле.
Строка «Expected tape durability, end-to-end passes». В зависимости от поколения от 9600 для первого до 20000 для шестого и выше.
Для полной записи всей емкости требуется от 48 до 208 полных проходов в зависимости от поколения.
Для LTO-5 это 80 проходов на полную запись и 16000 проходов предполагаемого ресурса, то есть порядка 200 полных записей (или полного чтения, все равно мотать же). Не особо надолго хватит.
Но вообще, LTO поколения до 9-го совместимы на 2 поколения назад. То есть LTO-5 может работать с носителями LTO-4 и LTO-3. И такой драйв (LTO-5) сейчас можно найти за 250-400 евро. Приводы же LTO-7, последние совместимые с 5, будут доступны еще весьма и весьма долгое время (а сейчас ну слишком дороги), которого более чем хватит, чтобы накопить и неторопясь купить себе резервный совместимый драйв.
Как обладатель Blue Card могу сказать, что голубые карты не всех стран одинакого полезны.
ЧР одна из стран, где пользы от нее минимум. Она выдается на очень короткий срок (2 года, в сравнении с 3 в Польше или 4 в Германии), не дает преимуществ при получении ПМЖ (в Германии она сильно сокращает срок с 5 лет до 22 месяцев при наличии немецкого B1 или до 33 месяцев при немецком А1), а ее трансфер — действительно весьма замороченная штука, к тому же принимающая страна обычно требует минимум 2 года проживания у себя до ПМЖ, то есть тайм-слот «до ПМЖ», когда имеет смысл дергаться и транферить карту — не более 3 лет проживания с момента получения первой карты, но не менее 18 (вроде) месяцев, после которых стаж вообще становится можно перенести.
В итоге получается, что трансфер, который не растянет время до получения ПМЖ, разумен только в течении полутора лет, с 19 по 35 (37 в случае с Германией) месяц обладания голубой картой. После этого смысл несколько теряется и проще дождаться ПМЖ, а потом уже уезжать, если хочется. Правда дергаться после 5+ лет в одной стране вряд ли захочется (все таки страны ЕС не отличаются совсем уж кординальным образом), разве что там совсем не понравится, но тогда я думаю есть смысл уехать сразу после первых 18 месяцев.
Но в плане разницы в цене между S и 3060 я внезапно оказался прав, там как раз примерно 4 раза, но и 3060 конечно мощнее:)
Я не уверен за ситуацию в СНГ, но в ЕС оно несколько по-другому (да и в США, судя по тому, что я вижу).
За 700 баксов 3060 в свободной продаже я не видел уже очень давно. В каталогах они есть, но по факту их нет в наличии никогда.
Карты из наличия меньше чем за 1300 я не нашел где купить, по крайней мере в Польше\Германии, т.к. они есть только у перекупов. Можно попробовать заказать где-нибудь и подождать произвольное время без гарантий (месяц, два, как повезет, многие магазины вообще заказы не принимают на них). В магазинах в наличии из современных карт, по крайней мере в Польше, есть AMD 6800XT за 2 тысячи долларов. Еще месяц назад за эти деньги можно было взять из наличия в магазине 3090.
Кроме того, игровой ПК это не только карточка, это еще хотя бы 500 долларов на минимальные процессор+материнка+память, если уже есть дисплей, корпус, БП и прочее, чтобы эта 3060 полноценно работала.
Итого, по минимуму, если сильно поискать, прямо сейчас или консоль за 700 новая с гарантией завтра курьером, или карточка за 1300 у перекупов с аукциона с шансом проблем + 500 баксов за остальное новое из магазина, итого разница в 2.5 раза. Кстати, за 2200 можно взять ноут с 3060 от MSI, по крайней мере прямо сейчас он есть в наличии на Amazon DE.
Далеко не все готовы или ждать месяцами, или связываться с аукционами и перекупами и это на самом деле большая проблема. Купить Xbox сейчас проще и быстрее. По крайней мере в Польше. В Германии Xbox-ов тоже нет.
Рынок потребительских видеокарт для геймеров все еще достаточно крупный и прибыльный. При этом, есть не менее крупный и конкурентный рынок игровых приставок, где правит балом компания AMD, которая поставляет чипы для 2 из 3 крупнейших платформ, которые как раз обновились (есть еще Nintendo, но там совсем другая ситуация, а сами чипы старые, слабые и дешевые).
Мощность приставок последнего поколения примерно соответствует 3060, при этом сами приставки, по крайней мере Xbox Series S, есть в наличии и стоят в 4(!!) раза дешевле, чем просто 3060.
Я не в России, но в переводе на доллары прямо сейчас можно или купить Xbox с двумя играми или игрой + доп. контроллер за 700 долларов c доставкой завтра домой (что я сделал неделю назад), или 3060 за 800 в некоторых магазинах, где она иногда появляется в наличии с шансом ожидания от пары дней до пары месяцев.
Сейчас вот загуглил, вроде как есть в одном магазине 10 штук с поставкой 25 числа, но я почти уверен, что они все выкуплены уже и звонить бессмысленно. У перекупов 3060 в продаже нет, но есть 3060ti за 1300 долларов или 3070 за 1600.
Учитывая, что линейка игр для того же XBox весьма сильно повторяет линейку игр длы PC, а цены в на игры в steam и xbox store отличаются мало (а в Европе\США это так), то при сохранении ситуации, когда сборка игрового компьютера будет в 3-4 раза дороже покупки консоли той же мощности, это просто убьет рынок игровых PC, и когда бум майнинга пройдет, то продавать карты просто станет некому, у всех уже будут новые Xbox или PS5, поставки которых начинают налаживаться. И вот это уже прямая угроза будущему Nvidia.
На сайте что вы привели в роли подтверждения прямо написано обратное — https://searchads.apple.com/privacy/
Они не торгуют данными с девайсов и не используют их в рекламе. Да, я верю в написанное, потому что туда под лупой смотрит очень много людей в попытках доказать обратное, чтобы пойти с этим в суд и пошатать Apple.
1. Игровой проект чаще всего — гигантская монорепа, менеджить которую в гите крайне сложно.
2. Perforce из коробки хорошо умеет в бинари (да, есть Git LFS, но не так давно и не особо стабильно, когда тебе надо таскать и синкать гигабайты и терабайты бинарного контента), а игровой проект — это тонны бинарных данных, их на порядки больше по объему, чем непосредственно кода.
3. Возможность таскать проект к себе не целиком, что крайне актуально, когда его размер может быть в несколько терабайт. Partial checkout/commit и вот это все.
4. Система бранчей другая. Есть еще всякие штуковины типа «лока на директорию», аудит и подобное.
В общем — для определенных кейсов, в частности для геймдева, это удобная штука.
Офтопик конечно, но я тут проапгрейдился до 5950x со старенького Xeon и в общем-то сборка совершенно перестала напрягать. Всякая мелочевка собирается вообще мгновенно, apt индексы дольше пересчитывал, Firefox ~ за 9 минут от запуска emerge, а вот Chromium да, хром тот еще тормоз.
На счет готовности — ну очевидно я на нем не играю (в виртуалке играю, куда видюха проброшена), но вот в плане поработать все-таки удобнее, не смотря на WSL в винде. А мак просто выйдет безумно дорого в серьезной конфигурации. За коммерческий софт — да, пожалуй, но каждый выбирает инструмент под свои потребности:)
Я некоторое время назад поменял Fedora на Gentoo, потому что несколько устал бороться с дефолтными конфигами и страным поведением системы в моих кейсах, связанных в основном с виртуализацией, несколькими видео- и звуковыми картами (pulse почему-то крайней нестабильно работал и вел себя странно, причем апдейт версии в рамках релиза федоры не помогал, возможно что-то с конфигами дефолтными было не так...), использованием Enlightenment в роли WM и отсутствия необходимости в полном пакете софта из гнома или kde и т.д. Ubuntu как вариант не рассматривал, она норм конечно, но я боюсь еще одна починка поломавшегося об цикличесую зависимость apt меня просто добьет. Случается это конечно весьма не часто (пожалуй раза 3 всего было за те 14 лет, что я ей пользовался так или иначе), но сама возможность такой ситуации меня несколько нервирует. Я если что лучше ручками поправлю или соберу, чем буду бороться с dependency cycling или подобным.
Но в прод да, я бы пожалуй ее не потащил, слишком много гемороя и мало смысла. Да и в большинстве случаев там все равно все в контейнерах, эксплуатационные расходы не окупят всей суеты.
Вообще вся компания в первую очередь решает бизнесовые задачи, если это коммерческая компания, а не университет или RnD лаборатория, которая может себе позволить иногда заниматься инженерией ради инженерии в рамках исследований. Хотя их конечно потом все равно как-то коммерциализировать надо.
Нет никакого «бизнес решает бизнес», инженеры в коммерческой компании это не black box, в который с одной стороны грузят бабки тоннами, а с другой стороны он выдает идеальные инженерные продукты, которые берут какие-нибудь сейлзы и пытаются продать, это симбиоз специалистов, которые умеют делать много чего инженерного, но при этом не забывают, что их продукт придется продавать в каком-то виде.
Гугл при этом во многом похож именно на компанию, в которой engineering excellence (причем без customer experience) стоит во главе угла. Больших проблем это не создает потому, что есть стабильный поиск и относительно небольшая команда, которая занимается именно парой реклама+поиск и эта пара, как отличный печатный станок, приносит такое количество денег, которым можно закрыть любые коммерчески провальные эксперименты.
При этом, у гугла к сожалению за последнее время не получилось успешно запустить ни одного коммерческого продукта в новой для них нише и фейлились они не потому, что они технически плохо сделаны, а потому, что в них только technical excellence и есть, а вот про пользователя забыли. И кладбище закрытых продуктов продолжает шириться.
В целом ситуация то вполне объяснима — начиная именно с найма, они отбирают инженеров с хорошими фундаментальными знаниями, при этом не уделяя практически никакого внимания реальным навыкам решения реальных продуктовых проблем. Такие люди могут делать супер-крутые штуки, но им нужны не менее крутые визионеры и менторы уже над ними, которые будут задавать правильное направление и помогать правильно применять свои инженерные знания. Причем это должны быть весьма неординарные и сильные люди. А вот их уже нанять на несколько порядков сложнее. При том, что их нужно много, задача может стать крайне трудной, фактически близкой к невыполнимой.
Поэтому да, получается много сильных инженеров, которые делают технически крутые штуки, но при этом пользователи почему-то ими пользоваться не особо то хотят.
Пожалуй, из последнего в этом плане весьма показательна Stadia, которая фактически является иллюстрацией «как имея все технические компетенции, огромный бюджет и собственную общемировую маркетинговую машину провалить проект».
То есть начиная со следующего апрельского отбора, будут просто выдавать визы тем, кому предлагается максимальная зарплата, начиная с максимальной и по уменьшению, пока не закончится лимит виз или пока предлагаемая зарплата не станет ниже ~85К в год, что является нижним лимитом. Это очень сильно повышает шанс получения визы, если приглашает крупная компания, которая готова платить хорошие деньги. И машет ручкой галерам, которые выгребают львиную долю виз.
Всего виз в год — 65 тысяч.
При этом только крупные бодишопы типа Infosys, TATA и Deloitte, Accenture и прочие в сумме подавали под пол миллиона заявок, при этом предлагая среднюю зарплату, к примеру, у Infosys — 83к, у TATA — 70к, а они крупнейшие просители, почти 200 тысяч заявок, и нет ни одного «консалтинга», который бодишоп на самом деле, который, прося больше 10 тысяч виз предлагал бы более 92 тысяч в год в среднем.
Для сравнения, реальные среди реальных продуктовых компаний больше всего просят IBM India (35 тысяч заявок со средней 77к) и Microsoft (34 тысячи заявок со средней в 136к). За ними идет Google с 26 тысячами заявок и средней почти в 145к. Если посмотреть в детализации, то бОльшая часть предлагаемых зарплат ниже 200к. В общем, если не хочется лотереи, нужно пробиваться на позицию с компенсацией 200+, что почти гарантирует получение H1B.
Я вот тоже с гуглерами работал достаточно много, даже на гугл работал контрактором через третью фирму, но с возможностью посмотреть внутрь, доступами и т.д. и на собеседования туда ходил, и вот на этой серии «технических собеседований» был.
Впечатления средние. Безусловно там есть люди с руками и головой (кто-то же все это делает, там есть очень крутые штуки), там отличный HR департамент (внешний по крайней мере), в столовой в целом неплохо кормят, да.
Но компетенции и внутренняя структура большинства на типичном уровне крупной технологической компании. Добиваться решения месяцами — легко. Пойти по цепочке технической эскалации и обнаружить что там на самом деле 1. не знают, 2. не хотят знать — легко.
Короче обычная большая контора. Хорошо, если повезет и хватит скилов попасть в те проценты людей, которые действительно занимаются крутыми вещами. Но шанс, скажем так, весьма не велик.
Да, отбор там настроен на решение вот таких вот общих технических задачек и это очень чувствуется, когда человек в общем то решать задачки на алгоритмы и подобное умеет, а вот конкретную бизнес-задачу чет как-то не очень. Поэтому да, тебе с легкостью могут рассказать как обходить граф и какие мат. теории и приемы существуют на этот счет, но вот пойти и подебажить компонент или подумать над решением конкретной технической проблемы, с которой сталкиваются кастомеры — тут начинается что-то удивительное и люди как-то оперативненько сливаются, потому что там внезапно не только теория графов нужна, а надо, совершенно неожиданно, что-то руками делать, думать другими абстракциями и вообще вписывать продукт в бизнес-ожидания и работать на удовлетворение кастомера, а не собственного любопытства.
Это не значит, что там люди глупые (совершенно нет), или плохие (тоже нет), но сама система так построена, что люди, работающие в ней, создают весьма интересные технические решения, которые повернуты к кастомеру задней полусферой.
Ну это как очень неплохой Google Cloud, у которого нет кастомерской поддержки, куда можно хотя бы написать, так что если что-то пойдет не так, ну… ой. А там иногда идет что-то не так. Поэтому везде сквозит ощущение про «тут не для тебя все, а чтобы технически круто было».
Про интерфейсы я вообще молчу, оно подлагивает, местами крайне медленно работает и совершенно не отзывчивое даже на Ryzen 9 5950x, аппаратным ускорением отрисовки через GTX 1650 и полугигабитным интернет-каналом. Я хрен знает, как написать такой интерфейс, чтобы он ТАК себя вел. Или как придумать решение, когда у при удалении бакета в сторадже из UI он начинает удалять все объекты внутри бакета рекурсивно (что в целом правильно). Даже если их там миллион (а вот это уже не очень). По объкту на запрос (вообще что-то странное). Что ожидаемо подвешивает браузер, да. Вообще, я думаю у многих найдется история такого порядка про гугловые продукты.
Так что, я совершенно согласен и с 0xd34df00d, и с UnclShura. Рваться туда по сути смысла очень уж большого нет, в подавляющем большинстве случаев в компаниях F500 будет +- так же, даже с опционами. Но да, мерча из гугла не будет, хвастаться будет сложно:)
Зацепила меня эта фраза, решил поискать и… нашел такие!
Материнская плата Acer J3.
Карта с процессорами (по словам автора, как раз Socket 4):
Бэкплейн:
Все это на чипсетах Opti 82c696 и Opti 82c693 соответственно.
По словам автора поста на форуме: