Невероятная эффективность математики в естественных науках есть нечто граничащее с мистикой, ибо никакого рационального объяснения этому факту нет.
Очень схоластическое заявление. И безумно (или бездумно) категоричное.
На самом деле всё просто - математики приватизировали право на истину. А когда право принадлежит только им, то какая ещё наука может претендовать на истину?
Началось всё с философии. Потом её назвали физикой. Математика при этом была в стороне, ею треугольные поля (для земледелия) измеряли. Но постепенно произошло разделение. Философ изобрёл истину, например задавшись вопросом "что есть истина?". Далее философ применил ряд чисто технических (очень простых, доступных компьютеру) методов и получил рассуждения, в которых математик увидел формулы. И всё, теперь математик говорит - здесь есть формулы, значит это математика! И не стало у философии права на истину (или на вопросы о истине, в которых участвуют примитивные алгоритмы вывода).
Математики забрали под себя право на абстракцию и манипуляции с нею посредством простых преобразований. Но мир намного проще воспринимается именно через абстракции. Когда нам будут рассказывать про "вот этот камень сейчас полетит вот так, потом повернёт и в итоге упадёт на землю", мы понимаем, что такой рассказ есть наблюдения человека, незнакомого с законом всемирного тяготения. А теперь представим, что математики отобрали у нас абстракцию с названием "закон всемирного тяготения". Что получится? А получится простая вещь - математики будут бить себя пяткой в грудь и рассказывать про "невероятную, мистическую силу матетматики в естественных науках". А всё потому, что мы согласились отдать своё собственное изобретение в стан математиков (в том числе потому, что писать сухие формулы нам лень, пусть их сухари-математики пишут).
Как именно наш физический мир может быть математической структурой?
Забираем у физиков абстракцию и получаем "математическую" структуру. Куда проще-то?
Дает ли это утверждение какие-либо проверяемые предсказания?
Ну конечно даёт, закон всемирного тяготения ведь даёт предсказания. Точно так же и другие абстракции, которые у нас забрали, дают свои предсказания.
Latex не для тех, кто хочет освоить что-то за 30 минут. То есть автор не понимает, о чём он пишет.
Latex, это конвертор из данных о разметке документа в некий генерируемый внешний вид. Точно таким же конвертором является, например, ваш браузер, который точно так же конвертирует HTML-разметку в то, что вы видите. Но никто в здравом уме не пишет статьи про "освойте HTML" за 30 минут. Точнее, такие статьи изначально ориентированы на обман, ибо замануха.
Как и любой язык разметки, Latex, нужно учить. Нужно постоянно иметь по нему справочник под рукой. Нужно хорошо представлять связь между тэгами разметки и получающимся после конвертирования внешним видом. Ничего этого в статье нет. Есть лишь набор примеров, которые могут кого-то ввести в заблуждение на счёт быстроты освоения технологии.
Ну и если сравнить Latex с MS Word, то имеем:
Нет нужды учить язык.
Нет нужды учить связь между тэгами и внешним видом.
Нет нужды в справочниках.
То есть в ворде просто пишете свою формулу в редакторе формул и не вспоминаете ни о каких языках. Именно просто. А не как в латексе.
Вариант, указанный вами в начале статьи как предпочтительный, считаю приемлемым приближением направления, которое ещё лет 5 может давать полезные плоды.
Но язык должен быть Java, а не Java-Script. Как на сервере, так и на клиенте.
Поскольку бизнес и глубина познания есть принципиально антагонистические явления (бизнес хочет только готовое), найти нишу для расширения глубин познания непросто. Плюс стандартная ситуация дома - жена, дети, кредиты, и все оптом хотят много денег. Отсюда следует, что скорее всего и вам тоже не стоит думать о глубинах и выбирать путь в эту сторону. Но если вы (самоуверенно) относите себя к исчезающе малому меньшинству и считаете, что все условия для вас сложились благополучно, тогда дерзайте и ставьте цель на срок более 5-ти лет. Правда тогда вам стоит забыть о фреймворках и прочей стружке из под примитивного (и тупого) сверла. Вдали вас ждут модели, генераторы, автоматический вывод и прочая computer science. Хотя там вы встретитесь с ещё одной проблемой - как объяснить обезьяне, что нужно сделать, что бы ей стало хорошо. И здесь даже дело не в нахождении способа обучения, а в том, что обезьяна сама не знает, что такое "хорошо".
Если на создание валидатора у автора ушла неделя, а потом созданным пользовались разработчики в течении 10 месяцев, то отношение затрат на библиотечку к общему ресурсу времени проекта получается катастрофически низким, что-то вроде день-два на человеко-год, в зависимости от количества разработчиков.
Немного по другому - затраты в размере долей процента от общих некоторые (придумайте для них подходящее название) считают непозволительной роскошью. В результате весь проект годами несёт тяжкий груз бардака и массу неудобств, и всё из-за того, что эти "некоторые" считают, что лишние доли процентов затрат - это дорого!
Название для такого слабоумия придумано давно, это есть типичная экономия на спичках. Но как мы видим, данный вид слабоумия абсолютно неистребим и способен пережить все на свете фреймворки, методики и методологии разработки, а так же похоронить тысячи здравых начинаний из-за неизбежно вносимого в них вируса деменции, переводящего проект в стадию старческого маразма уже буквально на первом году жизни.
И каждый раз очередной молодой разработчик начинает понимать эти грабли только после нескольких подобных проектов. Это если вообще начинает. Ну и если всё же приблизится к пониманию, то выдаёт вот такие, как в статье, велосипеды, всего за неделю. Единственное, что удивляет - почему ему никто не настучал по рукам с криком "это дорого"? Видимо деменция сделала своё чёрное дело, атрофировала даже то, что уже и так было атрофировано, ну и возражать было "нечем". Как ни удивительно но только в таком случае можно ожидать прогресса. То есть: бардак = двигатель прогресса. А маразм - апостол его.
Собрать своё коробочное и гибкое - на грани подвига.
Так вы же лично сразу возмутитесь - я плачу только за нужный мне функционал, а коробочное решение мне не нужно! Вот и нет коробочного решения. Всё как вы хотите. А сделать так, как вы не хотите - на грани подвига, потому что это всё будет за счёт личного времени разработчика, вы ведь не оплатите то, что вам кажется ненужным.
даже к другим решениям присмотреться толком не могут
Ну здесь же опять вы мешаете. Вы опять скажете - мне нужно только то, что я сказал, ничего другого я знать не хочу (и оплачивать - тем более не хочу). А "присмотреться" ведь стоит денег. Вы не в курсе, сколько времени уходит на понимание нового фреймворка? А на освоение его на профессиональном уровне? Вот столько с вас попросят, если "присматриваться" будут за ваш счёт. И вы реально готовы столько отдать? Это, так сказать, вопрос-проверка. Если ответите "да" - вы скорее всего врёте. А если "нет" - вы обязаны изменить свой тон и пересмотреть отношение к затратам времени на разработку.
Например, были у меня отдельные приложения: мессенджер и вайтбоард. И решил я на днях добавить чат на вайтбоард. Всё про всё это заняло где-то пол часа.
За кадром осталось время, потраченное на архитектуру чата и второй приблуды. Они же ваши, правильно? Значит вы, можно предположить, потратили время на модуляризацию обоих поделок. Та же авторизация, я надеюсь в вашем франкенштейне она выполняется один раз, а не два? И сколько времени вы потратили на реализацию именно модульной настраиваемой авторизации, позволяющей одним конфигом прикрутить друг к другу ваши компоненты? А сколько времени вы потратили на понимание, что добавить/убавить для прикручивания компонентов? Это всё задачи, котроый вы решали на этапе, который скромно спрятали за рамками рассмотрения обсуждаемого вопроса. И теперь, забыв про все накладные расходы, громко заявляете про "пол часа на всё".
Даже ладно, пусть ваша оценка останется на вашей совести, но вот вам внезапно потребуется свести пользователя чата и второй приблуды - что делать? Базы данных разные? Или для чата вы вообще базу не использовали? Всё поди в файлик льёте, что бы быстрее разработать? И сколько теперь нужно времени на разработку парсера того файлика? И сколько ресурсов должен обеспечить заказчик для парсинга гигабайтного файла с чатами на всех пользователей каждый раз, когда нужно свести воедино пользователя чата и второй приблуды? А во второй приблуде тоже поди файлик вместо БД? Ну вот и посчитайте накладные расходы, которые вместо "пол часа" получатся.
И таких внезапных пожеланий заказчика, я вас уверяю, будет вагон. Посмотрим, как вы их за пол часа будете реализовывать.
>> В моем расчете нет никакого коэффициента использования.
Есть, и он занижен в 10 раз. Это к вопросу о вашей объективности, если что.
>> Бизнес это не человек, ему ничего не надо и он ничего не чувствует.
Ну ладно, если вам так понятнее, то пусть будут хозяева бизнеса. Но связь здесь неразрывная, жаль, что вы её не видите.
>> И пример закупок из практики - купить и вернуть полотенцесушитель за 20 тыр. - 50 писем поставщику и обратно
Смысл здесь такой - вы находитесь на самом дне бюрократического болота, которое из себя представляет ваша контора. Вы видите вокруг много развесистых деревьев (трудностей), но не видите леса (причины проблем). Ваш взгляд из глубины искажён непониманием общей картины. А картина всё та же - бизнесу это не надо. Далее вам нужно объяснять длинную цепочку причинно-следственных отношений, которые приводят к вашему положению, но это долго, поэтому кратко скажу - это называется кусочная автоматизация (погуглите на досуге). Следствием такого подхода является неизбежный бардак и соответсвующее ему болото, в которое вы и погрузились, и похоже других (нормальных) условий обитания не представляете (иначе не указывали бы на следствия бардака как на причину "выгодности" облаков). На самом деле в вашем положении находятся, скорее всего, большинство работников IT-сектора, то есть в большинстве контор царствует бардак той или иной степени тухлости. И когда везде бардак - давление среды становится недостаточным, что бы бизнес захотел что-то исправить. Ну и далее попробуйте довести короткую цепочку выводов до "бизнесу это не надо".
>> Для каждой задачи есть какой-то отдельный тул, который ее решает. Связывать и настраивать все это для совместной работы - фул тайм работа для нескольких, далеко не дешевых, человек.
Здесь опять не то. Опять взгляд из подземелья. Вы видели некую интеграцию в каком-то из вариантов "облака", но не видели аналога в своей конторе, поэтому вам кажется, что нигде в мире нет ничего лучше "облака". Но ситуация почти противоположная. Облака писали постоянно подглядывая решения у взрослых, то есть в норамльно работающих цепочках обработки данных. И эти цепочки не могли быть ни в каком другом месте, кроме обычных серверов. То есть всё давно и основательно придумано и реализовано, но конкретно вы просто не встречались на своём жизненном пути с нормально построенными системами. Здесь "нормально" следует понимать как "не хуже, чем в облаках". И к тому же у вас задачи довольно мелкого уровня (все эти RunDeck-и и ELK-и). Проблемы логирования должны решаться на этапе проектирования, но разумеется, в вашей конторе никто и никогда не занимался серьёзным проектированием, а потому никто эти небольшие проблемы не решил, всё свесили на вас, видимо разработчика одной из подсистем. И вы с энтузиазмом принялись строить свой велосипед, но поняли, что на его строительство нужно много времени, ну и от безысходности начали выть на луну (на облака), мол вот там всё есть, а здесь меня мучают логами. Но нет никаких причин для неповторения ситуации один в один в случае, если вы перейдёте в облака. Бардак достанет вас и там. Так что не надо возлагать необоснованные надежды на сырую и от того убогую технологию, и тем более, выдвигать ваш бардак в качестве аргумента "за облака", потому что это лишь аргумент в доказательство отсутсвия у вас опыта работы в условиях с существенно меньшим бардаком.
>> В облаке вы 350 дней в году используете 30 машин, а 15 дней в году 300. В своем дата центре вы 365 дней в году используете 300 машин на 1% в среднем.
Посчитайте снова. Ваш расчёт должен дать коэффициент использования 10%, а не 1%. И такая ошибка сильно повлияет на выбор технологии.
>> В большой организации вы можете ждать сервер по полгода и больше
Это тоже искажающее картину соображение. Если бизнесу что-то реально надо - они найдут сервера за один день (ну поусть неделю). А если не надо, то вы по сути выдаёте стремление к каким-то личным достижениям за истину. Ваши личные достижения на самом деле интересны только вам лично. И хорошо, если контора готова иплачивать ваши игры даже через пол-года после их начала. Но к выбору технологии удовлетворение ваших потребностей не относится, потому что это совсем другая область оптимизации с кардинально отличающимися целями.
>> А отдать лишнее железо производителю не получится
И это не проблема. Вспомним, как сбербанк нашёл мощности для тренировки сети GPT-3. Или вы думаете они все 100% этого железа купили под одну единственную задачу? Нет, они нашли способ утилизировать коэффициент простоя оборудования. То есть если бизнесу надо - всегда найдётся способ загрузить или ещё как-то окупить мощности.
>> Также IAM - то есть возможно управлять доступом
А что не так с доступом? Я не спец по деталям настройки толстых серверов, но я отлично знаю, как выделяют виртуальные сервера и как нарезают для них ограничения по ресурсам. Так же и вы - выделяйте виртуалку и нарезайте ресурсы кому нужно. А если проблема в бюрократии, то значит вы опять подменяете реальные проблемы бизнеса своим представлением о них. Бюрократия всегда там, где бизнесу что-то не надо. Хотя вам может показаться, что ваше решение принесёт миллионы и т.д., но это всего лишь мираж. Для этого вы должны стать руководителем, тогда ваши идеи прорастут, даже если они ошибочные. А пока бизнесом рулят другие - прорастают их идеи, даже если они ошибочные. И вам не стоит убиваться по их проблемам, особенно если это следствие принятия ими ошибочных решений.
>> А сейчас думаю над обратной миграцией, потому что подрос и хочется IAM, ECS, Secrets Manager, Systems Manager и RDS. Делать все это руками на своем железе очень долго и дорого.
Я вам не подскажу конкретные инструменты такого плана, но я очень сильно сомневаюсь в том, что их нет для обычных серверов, но есть исключительно для облаков. Обычные сервера развивались многие десятки лет, а облака всего где-то десяток. Скорее всего вы просто не в курсе существующих решений, ну а реклама вам подсказывает - в облаках всё есть! Или вы познакомились с облачным решением и увидели там какие-то инструменты, которые никогда не использовали с обычными серверами, потому что обчные сервера админят обычные админы, а не вы. А теперь, не зная про инструменты для обычных серверов и обладая только лишь представлением об облаках, вы делаете неверный вывод.
В целом я соглашусь, что если сами хозяева облачных решений сильно захотят, то они для каких-то нишевых решений обеспечат реальные преимущества. Но пока хозяева не хотят. Их бизнесу это не надо. Они приняли вот такое решение. И судя по тому, что постоянно находятся желающие им заплатить, возможно это решение вполне правильное для сложившейся ситуации. А вы же пытаетесь доказать, что на самом-то деле хозяева не бизнес ведут, а благотворительностью занимаются, раздавая всем лучшие в мире технологии. Раздают, да ещё и бесплатно, только некачественные решения. Бесплатно заманивают и обещают обещать. Обычный бизнес, ничего личного.
Железо берут с запасом. Разве вы про это не знали?
Расчитывать строго на среднесуточную нагрузку и выбирать железо ровно по этой планке - очевидный признак идиота. Поэтому выбирают что-то более производительное, например раз в 10. Экономически это очень дёшево, поскольку железо окупится примерно за месяц на одной только рекламе, была бы нагрузка (посетители).
Второй момент - архитектура и реализация должны обеспечивать близкую к линейной деградацию времени отклика при перегрузке.
Если два обозначенных критерия выполнены, то при выбросах до 10 раз деградации не произойдёт. А при выбросах более 10 раз начнёт копиться долг, под который требуется память. Памяти на один запрос обычно требуется немного, поэтому узким местом при нагрузке *10max память станет лишь при большой длительности пика. Но "длительный пик" даст существенный прирост средней нагрузки, а потому такие варианты мы не рассматриваем, поскольку они предполагают нашу ошибку в расчёте средней нагрузки (что маловероятно в давно работающей среде, ну либо результат экспериментов всё тех же идиотов).
>> Это единственный кейс где serverless рулит, если система под него заточена.
Если вы готовы потратить большой бюджет на адаптацию ко всем косякам "облаков", тогда, возможно, вы как-то сумеете реализовать предложенный вариант масштабирования.
Но есть ещё традиционный подход. С ним не нужно тратить большие деньги на адаптацию. Хотя да, масштабироваться без заметных для пользователя тормозов сразу в сто раз будет непросто. Если бюджет ограничен и железом проблему не закидать, то в традиционном решении пользователь будет ждать, например, 10 секунд вместо одной. Опасно ли это для бизнеса? Скорее всего нет, поскольку это пиковая нагрузка, она затрагивает малую часть пользователей, остальные её не заметят, или заметят один раз из нескольких десятков посещений сервиса.
Но тут важнее другое - если у вас денег на железо нет, то значит и на облака у вас денег гарантированно нет. И характер этих денег отличается. Железо - одноразовые капитальные вложения, которые можно частично вернуть посредством продажи. Вложения же в адаптацию к убогости облачных решений являются постоянными. Облачные вендоры постоянно что-то меняют, а нормальных инструментов для анализа не предоставляют, поэтому выход один - постоянно держать дорогую команду ради этой самой адаптации. Такой вариант, очевидно, ни разу не подходит для экономии.
Но если с точки зрения экономии нет выгоды, то где же тогда она есть?
В целом вопрос сводится к оценке вложений в железо против оценки вложений в постоянную адаптацию. На мой взгляд выбор здесь очевиден. Хотя на взгляд бюрократа из толстой конторы, выделяющего деньги на вечно неэффективные проекты, особой разницы нет, оплачивать ли ими адаптацию как к косякам облачных сервисов, так и к косякам управления в большой конторе, или оплачивать ими одни только косяки управления в большой конторе, потому что последние стоят на порядок больше, чем косяки облачных решений.
То есть облака - для богатых и ленивых. Для тех, кто деньги всё же считает, облака в принципе не подходят. Никак. Никогда. Ни при каких условиях (кроме перехода на модель "богатый и ленивый").
Очередная реклама "облаков". Ну и навязывание новых смыслов старым терминам, заодно.
Бессерверным что-то бывает только тогда, когда сервера нет. А когда он есть, но называют его маркетинговым словечком "облако", то это опять всё тот же безумный маркетинг.
>> Такой подход позволяет более точно рассчитать экономику проекта в условиях невозможности спрогнозировать масштабы.
А вот это есть просто наглая ложь. Но, как всегда, слово "ложь" проплатившая рекламу контора возмущённо заменит на "маркетинг". Только замена слов на смысл не влияет. Прогнозировать что-то в ужасно глючных и практически неконтролируемых разработчиком решениях невозможно по определению. Ошибки и отсутствие возможности понять, где нам опять насчитали лишние десятки тысяч долларов - вот реальность "облаков". И как в таких условиях "точно рассчитать экономику проекта"?
>> Снимается боль бизнеса — оплата мощностей за время простоя.
А это откуда выросло? Во время простоя сервер БД потребляет, например, 100 ватт. За сутки - 2400 ватт. Один киловатт-час стоит 6 рублей. То есть в сутки имеем 14.4 рублей. В месяц не более 450 рублей. Да, это адская боль бизнеса!
>> Аргумент по части NoSQL такой, что бессерверные приложения по большей части в стартапах, когда нет истории, нет понимания будущей модели данных, прогнозов трафика.
А это очень правильное замечание - когда нет понимания (модели данных, прогнозов трафика и т.д.), тогда выбирают "сердцем", то есть покупаются на убогую рекламу "облаков".
>> Компания Pokémon Company первоначально выбрала NoSQL и столкнулась со сложностью поддержки бесперебойной работы узлов. Выбор SQL-решения позволил сократить узлы с 300 до 30 и свести к нулю время простоя и снижения производительности.
А это уже, видимо, что бы развеселить читателей. Компания покемонов решила "делать бизнес". Ничего не понимая, выбрали "облака". В результате получили 300 попгуаев нагрузки. Потом пришёл кто-то немного слышавший про нормальную разработку и в результате нагрузка уменьшена до 30 попугаев. Браво, в рекламе "облаков для дураков" такой пример очень выигрывает! Приходите, делаете адски тормозящий продукт на "облаке", а потом, возможно, вы даже найдёте способ сократить нагрузку на "облако" не менее чем в 10 раз. Но ради чего это всё? И это уже вопрос к недуракам. Ради больших затрат на разработку того, что будет в 10 раз медленнее, чем в случае выбора более проверенного временем решения? А есть ведь ещё одно проверенное временем решение - вообще отказаться от облаков, а не просто поменять NoSQL на SQL.
>> Компилятор при всех своих гигабайтах и десятках ядер не может ни при каких условиях узнать во многих случаях, куда пойдет ветвление
Это ваш единственный аргумент? Пробегитесь по комментариям, там уже дали на него ответ. Хотя ответ любому разбирающемуся в матчасти и так понятен.
Что такое предсказание ветвлений? Направления два - исполнение сразу по двум ветвям и сбор статистики. Эти функции в обычных процесорах реализованы в железе. Для VLIW ровно эти же функции ничто не мешает реализовать в виде наполнения пустующих слотов в потоке инструкций. То есть в обоих случаях предсказание будет. А если оба случая эквивалентны по имеющейся информации, но один из случаев всё же более качественно оптимизирован за счёт привлечения полноценного компилятора, то кто же выиграет? И вот таких элементарных вещей вы не понимаете?
Автор смешал тёплое с мягким. Он объявил бесперспективной конкретную разработку, а в реальности оспаривает лишь технологию, задействованную в данной разработке.
Эльбрус, как конкретная разработка, бесперспективен в рамках системы, в котрой ему приходится существовать. А технология, объявленная автором плохой, вполне может выиграть конкурентную борьбу даже в рамках существующей системы.
Далее рассмотрим конкретнее некорректность претензий автора именно к технологии VLIW.
Проблема в том, что своя архитектура означает портирование всего стэка софта, необходимого пользователям
Разумеется, это не так. Портированию подлежит лишь то, что скомпилировано под конкретную архитектуру. Но мир развивается, и равитие несёт нам свободу от монополий. Есть всем известные примеры языков, компилируемых в байт-код или же в оптимальный машинный код, но на этапе исполнения. Если автор обратит внимание на эти всем известные подходы, то "проблема" с портированием моментально испарится. Останется только осилить базовые библиотеки на компилируеммом в байт-код языке, что бы не плакать о "невозможности портировать" что-то чужое.
Да, к сожалению мы не можем делать аналог x86.
Не "мы не можем", а система, которая ограничивает нас всех, не способна ни на что большее, нежели набор завиральных обещаний о великих победах в будущем.
VLIW-архитектура принципиально уступает по производительности современным RISC/CISC процессорам
Абсолютно необоснованное заявление. Сравнение может проводиться (если сторона обвинения VLIW вообще этим озадачивалась, в чём я сомневаюсь) только с одной известной приличной попыткой - Itanium. Всё остальное - либо теоретизирование без денег, либо вот Эльбрус, который рождён в условиях всем известных ужасных ограничений. И вот на основании стравнения с явно ограниченными вариантами, делается далеко идущий вывод.
Пришедший указатель или сложная работа с памятью - и вы не можете спланировать Load выше операции Store (и наоборот)
Здесь всё зависит от объёма памяти и количества вычислений на этапе компиляции. У процессора, который в железе реализует то же самое, и памяти и вычислений на порядки меньше. Но автор настаивает на своём, забывая об очевидных возражениях.
Но при компиляции без профиля установить какие циклы горячие невозможно.
Опять же здесь стоит напомнить о технологиии, которая существует уже лет 25. Называется она "just in time" компиляция. И профиль там, безусловно, есть. А вот значимость, придаваемая автором данной проблеме, явно завышена. В целом статья демонстрирует именно произвольно надёрганный набор из ряда типичных возражений сторонников традиционного подхода, но ни в коем случае не демонстрирует системность подхода и уж тем более, какие-то расчётные или статистические выкладки.
В то же время классические RISC/CISC архитектуры с OoO автоматически оптимизируют и конвейеризируют любой исполняемый код.
А здесь вообще декларируется наличие магии внутри традиционных решений. То есть всю логику, которая зашита в железе, противники VLIW считают в принципе недоступной для реализации в альтернативных решениях. Как может быть недоступно то, что доступно процессору с его крошечными мозгами, полноценному компилятору с его доступом к гигабайтам памяти и десятку ядер при компиляции? Только за счёт магии. Но здесь главное - верить, ну и излагать мксимально безапелляционно.
Если в данном цикле вызов функции get_int_val по какой-то причине не заинлайнится компилятором, то для RISC/CISC архитектуры с OoO итерация цикла будет занимать ~1 такт, не отличаясь принципиально от случая, если инлайн сработал.
Если что-то не заинлайнено компилятором, то это что-то, по мнению автора, автоматически заинлайнится процессором. А теперь вспомним про различие в количестве доступной памяти и вычислительных циклов между полноценным компилятороми и ограниченным в этом всём процессором. Вопрос - кто сможет оптимизировать лучше?
В то же время на Эльбрусе одна итерация данного цикла будет занимать порядка 17 тактов.
Ну это же классическая манипуляция с указанием на худший вариант против лучшего. Автор берёт VLIW и предполагает, что он совсем тупой и ничего не умеет. Потом он берёт обычный процессор и предполагает, что он умеет абсолютно всё. А затем автор сравнивает два таких варианта. И, о чудо, внезапно побеждает именно идея автора о превосходсьтве "белой расы".
В целом статья пустая. Нет ни статистики, ни расчётов, хотя есть много необоснованных зявлений и натянутых предположений.
Для нормальной работы качественных разработчиков нужна соответствующая среда. Поэтому качественные разработчики либо её находят (что редкость), либо тихо вымирают (встречается чаще).
Достаточно посмотреть массовые вакансии - требуются исключительно узкие навыки. Поэтому качественный разработчик вынужден по быстрому осваивать очередне модное веяние и далее ковырять оное в обычной и убогой, с точки зрения качества, конторе.
Хотя скорость освоения моды у таких разработчиков сильно выше остальных. Так же помогает психологическая готовность к изучению нового (это просто, потому что принципы там обычно детские, максимально адаптированные под массовых кодеров). Это всё даёт возможность оперативно менять работу при необходимости.
Но в целом ниша кодеров на порядки толще. Как и во всём остальном - китай доказал, что некачественные, но дешёвые, вещи, вполне конкурентоспособны.
Какой подход в итоге победит? Ответ - победят роботы.
С «Наукой» российский сегмент сможет работать ещё 10 и более лет, и делать это эффективнее, с научной точки зрения.
Как российский сегмент вообще может работать, хоть с модулем, хоть без модуля, если он из-за усталостного разрушения трещит и рвётся по швам? Какие 10 лет? Откуда такие сказки?
И в чём будет выражено повышение научной эффективности? В постоянном устранении массы больших и малых проблем с новым модулем? Плюс всеми любимый поиск трещин и прочие увлекательные заняти по ремонту запчастей типа "сделаноунас".
Фактически статья свелась к и без неё понятному указанию на убогость нашего "космоса" (точнее того, что от него осталось), плюс к столь же очевидному указанию на неизменно лживые заявления роскосмоса. Я, конечно, за правду, за критику паразитов в высоких креслах, но хоть чего-нибудь бы про науку, про технологии, про то же IT. Но нет, всё, что можно вытянуть из рассейского космоса - лишь очередное доказательство его убогости.
ЗЫ. И очень в тему здесь убогость нового редактора сообщений хабра. Он примерно как роскосмос - даже что-то умеет, но никогда не сделает это правильно и удобно. Потому что природа у этих двух субъектов общая, видимо.
Вы свои предложения выше перечитайте. Там вы указываете на важность доверия к инструменту. И вот предлагаете нанять стороннюю контору, которая будет весело и со свистом сливать все данные, до которых дотянется.
Про авааз. Я не знаю, на сколько вы близко с ними общались, но я вот не поленился и посмотрел их отчёты. На самом деле немного времени нужно, всё до боли очевидно, но детали вы и сами найдёте, если не являетесь верующим в розовых пони.
Такие фонды выполняют грязные дела для их создателей. Когда у кого-то много денег, и он хочет чего-нибудь запрещенного в его стране регистрации, он создаёт вот такие фонды, ну и рассказывает вам про 42 миллиона участников. Реальных дел (для прикрытия) они делают на сумму, меньшую чем 4% от поступлений, и все дела из серии "марш за права живонтных", то есть абсолютно бессмысленные, только ради замыливания ваших мозгов. А на сайте они пишут про "победы" - оказывается это они "победили" и теперь все зелёные технологии по их инициативе внедряются. Ну да ладно, если вы им уже перевели денег, то только злость на меня в вас разжигаю, поэтому не буду продолжать.
Если говорить коротко - никаких 210 миллионов участников у вашей идеи не будет. А миллионы евро для тех, кто может себе позволить привлекать такие массы, это какие-то копейки, о которых они никогда думать не будут.
И, до кучи, вся эта электронная байда, за которую спекулянты пока ещё дают денег, по своей ужасна, безумна и т.д. и т.п. Ваша поддержка грязи типа авазов - ещё ужаснее. А ещё подумайте - кому вы хотите помочь? Ответ - только себе. Вам нравится обсуждать вашу идею, а помощь кому-то здесь даже рядом не стояла. Вы, по сути, продаёте свою идею очередным спекулянтам и прочим буржуям, у которых есть деньги, но у которых кончились идеи по охмырению граждан. Правда вы такой не один, вас таких миллионы, поэтому от вашего личного вклада люди пострадают не очень сильно. Но может всё-таки хоть немножко задумаетесь.
Сколько стоит создать криптомайнер? А потом к нему прикрутить чат. А потом к нему прикрутить...
Получившуюся сумму нужно вычесть из того, что получится намайнить.
Я вам простую вещь скажу, только вы не обижайтесь.
Это дорого (с).
Окупаемость будет лишь на проектах, где за год можно намайнить тысяч 20-30 вечнозелёных. Делим на три копейки (цента) с носа. Получаем 3 миллиона участников за год по три цента каждый. И где вы видели такие организации? В смысле не спонсируемые бизнесом или государством, разумеется. На всю рассею имеем одного Навального с каким-то потенциалом, но и он не осилит 3 миллиона. Никак. Никогда.
В математике алгебра (как и другие формальные теории) используется очень широко, поэтому она даётся на начальном этапе университетской подготовки математиков. Если этот этап пропущен - получается как раз ваше положение.
Просто вот такая там база. Она могла бы быть другой, но с этим вопросом к нынешним математиками не стоит подходить, потому что они давно привыкли жить именно с этой базой. Точнее - привыкли с самых ранних этапов обучения в универе. И переучиваться на что-то другое ради вашего удобства для них несколько напрягающая задача.
Хотя если не сводить всё к полям, кольцам и прочим решёткам, то в некоторых местах математика и для самих математиков стала бы проще. Но реформу в математики в современном обществе начинать не стоит, уж точно. Потому что общество не готово, а если оно "не тянет", то сами математики без живительного пинка никогда за такую задачу не возьмутся.
Если делить работников по аналогии с системой образования в СССР, то большинство одноэсников были бы обычными выпускниками ПТУ. Программисты - это выпускники техникумов, отличаются от ПТУ-шиков более широким взглядом на свою сферу деятельности.
Но для устранения дисбаланса в сторону ПТУ-шников нужны выпускники университетов. А большинство программистов, это именно техникум, даже не заштатный уездный ВУЗ. Некоторые всё же дорастают до уровня именно заштатного и именно уездного института, но таких мало. Очень мало.
И почти никто не дорастает до университета. Потому что спроса нет. То есть засилье ПТУ-шников бизнес вполне устраивает. Но если посмотреть с точки зрения максимизации пользы для всего общества, то станет очевидно, что ПТУ-шников можно сократить на порядки. В результате не только их зарплаты пойдут в плюс, но и масса косвенных затрат почти всех бизнесов будет уменьшена очень серьёзно. И эта масса намного больше, чем зарплаты ПТУ-шников. Но если вспомним, что 1С не является исключением, и во всех других областях всё обстоит точно так же, то можно легко представить порядок косвенных затрат.
Правда есть минус (временный). Все те, кто сегодня занимается лечением бардака, который настрадали стада ПТУ-шников, вынуждены будут искать работу. И там уже нужно будет думать, а к этому привыкшие гуглить бойцы с бардаком непривычны. Но это не беда. Они же привыкли подчиняться, значит тупо будут выполнять все указания по переучиванию и включению мозгов. Останется лишь сделать систему обучения, которая всех привыкших к полной покорности приведёт к свету. Правда опять есть одно "но". Большой бизнес в результате сильно (реально сильно) пострадает. Покорные овцы начнут пробовать думать. Да, это будет удар...
Вот так, просто нормальная система образования, и никаких вам ПТУ-шников, пишущих говнокод. Но "это дорого" (с).
Ваш подход предлагает "некое" решение, но не показывает сравнения такого решения с оптимальным. Почему пользователь обязан верить вашим словам про оптимальность? Просто потому, что "вроде как оно попхоже на правду"?
Нормальное исследование обязательно включает задачу нахождения области применимости разработанной технологии. А применимость сразу выводит на очень простую оценку результата - есть выгода или нет. Ваша же теория ничем подобным похвастаться не может. А всё потому, что нет обоснованного сравнения с аналогами и с идеалом. Хотя для очередного бумажного накачивания каких-нибудь безумных рейтингов, наверно статья подходит.
В прогрессивных кругах при взгляде на людей, выступающих против вакцинации, принято задумчиво хмурится и пожимать плечами
Вот так незамысловато авто задаёт тон дальнейшему повествованию. Ну а дети, читающие про "прогрессивные круги" и "задумчиво" что-то там пожимающих, разумеется, впадают в панику - а меня-то тоже могут не посчитать прогрессивным!!! И на меня задумчиво посмотрят и что-то пожмут! А-а-а-а, боюсь!
Дети, не бойтесь, этот дядя только делает вид, что он умный. На самом деле он такой же как и вы, но немного познакомился с так называемыми "манипулятивными техниками". Это такие техники, которые применяют на детях. Потому что на взрослых их применть бесполезно. А дети, благодаря своему детскому восприятию мира и себя в мире, не способны противостоять таким примитивным и шаблонным техникам. Ну что с них взять - они же дети.
Но с другой стороны, дети, помните - так вас могут завести в тёмный переулок и изнасиловать мозг. Это больно. Но не сразу, а потом, когда вы станете взрослыми. Вот тогда становится очень неприятно за все те ваши собственные действия, которые вы согласились сделать, получив от подобного автору дяди дозу насилия прямо в детский и пока ещё беззащитный мозг.
Итак, ваш мозг насилуют. И мне жаль, дети, что я не могу вас вылечить быстро. Но я знаю одно волшебное снадобье, которое очень тернирует мозг и делает его бессмысленной целью для маньяков-манипуляторов. Это средство называется "много думать". Или просто - Многодум. Давайте я покажу вам, маленькие дети, как это средство работает.
Допстим, дети, вам злые маньяки рассказывают о старшной престрашной комнате, в страшном престрашном доме, в страшном престрашном городе, в страшной престрашной стране. Представили? Вам ведь уже страшно? Нет? Ну тогда представьте, что это рассказываю не я, а очень важный дядя в телевизоре. Представили? И допустим, дядю зовут так - президент. Теперь страшно?
Ну вот, когда вы всерьёз испугались, дети, вам должно стать ещё страшнее! Потому что президент говорит - мы все умрём! Вы уже упали со стула? Нет? Тогда срочно спрячьтесь под стол! Потому что злые маньяки-манипуляторы давно выяснили, что во время землятрясения под столом безопаснее всего! И дядя-президент о том же вам говорит.
А теперь лекарство.
Дети, сначала нужно просто понять - что вам сказали. Потом нужно подумать, а правильно ли вы поняли, что вам сказали. Потом нужно найти доказательства того, что вам сказали. Да дети, взрослые дяди могут врать. Поэтому если вы найдёте доказательства, тогда переходите к сдледующему пункту рецепта выздоровления. А если не найдёте - срочно бегите от таких дядь и тёть, потому что они - злобные маньяки-манипуляторы.
Разберём маленький пример.
Вам сказали, что мы все умрём. Вам стало страшно. Вы надели намордник и презервативы на пальцы (умные учёные говорят, что это помогает от всего). Но теперь настал черёд принять лекарство. Оно не страшное, по началу немного напрягает, а потом начинает нравиться. Итак - подумайте, а есть ли доказательства того, что мы все умрём? И оказывается, что из доказательств только слова неких надевших белые халаты лиц неопознанной национальности (они ведь в намордниках, как их распознать). И с другой стороны, у вас есть мощный инструмент, котороый называется "статистика". Да, вы ещё маленькие и никогда не слышали про такие инструменты, но когда-то же надо начинать, правильно? Вот и начните сейчас - скачайте статистику по смертности с тех сайтов, которым можно доверять. Как выбрать вызывающие доверие сайты? Ну это не сложно - нужно подумать, а почему я им должен доверять? А потом найти доказательства, что им действительно можно доверять. И всё, после этого, глядя на статистику, вы легко поймёте, что никто нигде не собирается умирать, что злые дяди маняки и манипуляторы вас просто обманывают, что им верить нельзя, а вся шумиха вокруг "мы все умрём" поднялась из-за таких же как вы детей, которые ещё не научились пользоваться таким простым инструментом, как статистика. А всё потому, что они не пили на ночь нашего волшебного лекарства для их крошечного и недоразвитого мозга.
Вот так дети, развивайте мозг и не верьте злобным маньякам-манипуляторам, даже если их зовут как-ниубдь страшно, например - президент. Ведь вы уже почти взрослые! Такие почти взрослые дети уже ничего не должны бояться!
Очень схоластическое заявление. И безумно (или бездумно) категоричное.
На самом деле всё просто - математики приватизировали право на истину. А когда право принадлежит только им, то какая ещё наука может претендовать на истину?
Началось всё с философии. Потом её назвали физикой. Математика при этом была в стороне, ею треугольные поля (для земледелия) измеряли. Но постепенно произошло разделение. Философ изобрёл истину, например задавшись вопросом "что есть истина?". Далее философ применил ряд чисто технических (очень простых, доступных компьютеру) методов и получил рассуждения, в которых математик увидел формулы. И всё, теперь математик говорит - здесь есть формулы, значит это математика! И не стало у философии права на истину (или на вопросы о истине, в которых участвуют примитивные алгоритмы вывода).
Математики забрали под себя право на абстракцию и манипуляции с нею посредством простых преобразований. Но мир намного проще воспринимается именно через абстракции. Когда нам будут рассказывать про "вот этот камень сейчас полетит вот так, потом повернёт и в итоге упадёт на землю", мы понимаем, что такой рассказ есть наблюдения человека, незнакомого с законом всемирного тяготения. А теперь представим, что математики отобрали у нас абстракцию с названием "закон всемирного тяготения". Что получится? А получится простая вещь - математики будут бить себя пяткой в грудь и рассказывать про "невероятную, мистическую силу матетматики в естественных науках". А всё потому, что мы согласились отдать своё собственное изобретение в стан математиков (в том числе потому, что писать сухие формулы нам лень, пусть их сухари-математики пишут).
Забираем у физиков абстракцию и получаем "математическую" структуру. Куда проще-то?
Ну конечно даёт, закон всемирного тяготения ведь даёт предсказания. Точно так же и другие абстракции, которые у нас забрали, дают свои предсказания.
Latex не для тех, кто хочет освоить что-то за 30 минут. То есть автор не понимает, о чём он пишет.
Latex, это конвертор из данных о разметке документа в некий генерируемый внешний вид. Точно таким же конвертором является, например, ваш браузер, который точно так же конвертирует HTML-разметку в то, что вы видите. Но никто в здравом уме не пишет статьи про "освойте HTML" за 30 минут. Точнее, такие статьи изначально ориентированы на обман, ибо замануха.
Как и любой язык разметки, Latex, нужно учить. Нужно постоянно иметь по нему справочник под рукой. Нужно хорошо представлять связь между тэгами разметки и получающимся после конвертирования внешним видом. Ничего этого в статье нет. Есть лишь набор примеров, которые могут кого-то ввести в заблуждение на счёт быстроты освоения технологии.
Ну и если сравнить Latex с MS Word, то имеем:
Нет нужды учить язык.
Нет нужды учить связь между тэгами и внешним видом.
Нет нужды в справочниках.
То есть в ворде просто пишете свою формулу в редакторе формул и не вспоминаете ни о каких языках. Именно просто. А не как в латексе.
Велосипеды строить нужно.
Вариант, указанный вами в начале статьи как предпочтительный, считаю приемлемым приближением направления, которое ещё лет 5 может давать полезные плоды.
Но язык должен быть Java, а не Java-Script. Как на сервере, так и на клиенте.
Поскольку бизнес и глубина познания есть принципиально антагонистические явления (бизнес хочет только готовое), найти нишу для расширения глубин познания непросто. Плюс стандартная ситуация дома - жена, дети, кредиты, и все оптом хотят много денег. Отсюда следует, что скорее всего и вам тоже не стоит думать о глубинах и выбирать путь в эту сторону. Но если вы (самоуверенно) относите себя к исчезающе малому меньшинству и считаете, что все условия для вас сложились благополучно, тогда дерзайте и ставьте цель на срок более 5-ти лет. Правда тогда вам стоит забыть о фреймворках и прочей стружке из под примитивного (и тупого) сверла. Вдали вас ждут модели, генераторы, автоматический вывод и прочая computer science. Хотя там вы встретитесь с ещё одной проблемой - как объяснить обезьяне, что нужно сделать, что бы ей стало хорошо. И здесь даже дело не в нахождении способа обучения, а в том, что обезьяна сама не знает, что такое "хорошо".
Так сказать, детям на заметку:
Если на создание валидатора у автора ушла неделя, а потом созданным пользовались разработчики в течении 10 месяцев, то отношение затрат на библиотечку к общему ресурсу времени проекта получается катастрофически низким, что-то вроде день-два на человеко-год, в зависимости от количества разработчиков.
Немного по другому - затраты в размере долей процента от общих некоторые (придумайте для них подходящее название) считают непозволительной роскошью. В результате весь проект годами несёт тяжкий груз бардака и массу неудобств, и всё из-за того, что эти "некоторые" считают, что лишние доли процентов затрат - это дорого!
Название для такого слабоумия придумано давно, это есть типичная экономия на спичках. Но как мы видим, данный вид слабоумия абсолютно неистребим и способен пережить все на свете фреймворки, методики и методологии разработки, а так же похоронить тысячи здравых начинаний из-за неизбежно вносимого в них вируса деменции, переводящего проект в стадию старческого маразма уже буквально на первом году жизни.
И каждый раз очередной молодой разработчик начинает понимать эти грабли только после нескольких подобных проектов. Это если вообще начинает. Ну и если всё же приблизится к пониманию, то выдаёт вот такие, как в статье, велосипеды, всего за неделю. Единственное, что удивляет - почему ему никто не настучал по рукам с криком "это дорого"? Видимо деменция сделала своё чёрное дело, атрофировала даже то, что уже и так было атрофировано, ну и возражать было "нечем". Как ни удивительно но только в таком случае можно ожидать прогресса. То есть: бардак = двигатель прогресса. А маразм - апостол его.
Так вы же лично сразу возмутитесь - я плачу только за нужный мне функционал, а коробочное решение мне не нужно! Вот и нет коробочного решения. Всё как вы хотите. А сделать так, как вы не хотите - на грани подвига, потому что это всё будет за счёт личного времени разработчика, вы ведь не оплатите то, что вам кажется ненужным.
Ну здесь же опять вы мешаете. Вы опять скажете - мне нужно только то, что я сказал, ничего другого я знать не хочу (и оплачивать - тем более не хочу). А "присмотреться" ведь стоит денег. Вы не в курсе, сколько времени уходит на понимание нового фреймворка? А на освоение его на профессиональном уровне? Вот столько с вас попросят, если "присматриваться" будут за ваш счёт. И вы реально готовы столько отдать? Это, так сказать, вопрос-проверка. Если ответите "да" - вы скорее всего врёте. А если "нет" - вы обязаны изменить свой тон и пересмотреть отношение к затратам времени на разработку.
За кадром осталось время, потраченное на архитектуру чата и второй приблуды. Они же ваши, правильно? Значит вы, можно предположить, потратили время на модуляризацию обоих поделок. Та же авторизация, я надеюсь в вашем франкенштейне она выполняется один раз, а не два? И сколько времени вы потратили на реализацию именно модульной настраиваемой авторизации, позволяющей одним конфигом прикрутить друг к другу ваши компоненты? А сколько времени вы потратили на понимание, что добавить/убавить для прикручивания компонентов? Это всё задачи, котроый вы решали на этапе, который скромно спрятали за рамками рассмотрения обсуждаемого вопроса. И теперь, забыв про все накладные расходы, громко заявляете про "пол часа на всё".
Даже ладно, пусть ваша оценка останется на вашей совести, но вот вам внезапно потребуется свести пользователя чата и второй приблуды - что делать? Базы данных разные? Или для чата вы вообще базу не использовали? Всё поди в файлик льёте, что бы быстрее разработать? И сколько теперь нужно времени на разработку парсера того файлика? И сколько ресурсов должен обеспечить заказчик для парсинга гигабайтного файла с чатами на всех пользователей каждый раз, когда нужно свести воедино пользователя чата и второй приблуды? А во второй приблуде тоже поди файлик вместо БД? Ну вот и посчитайте накладные расходы, которые вместо "пол часа" получатся.
И таких внезапных пожеланий заказчика, я вас уверяю, будет вагон. Посмотрим, как вы их за пол часа будете реализовывать.
>> В моем расчете нет никакого коэффициента использования.
Есть, и он занижен в 10 раз. Это к вопросу о вашей объективности, если что.
>> Бизнес это не человек, ему ничего не надо и он ничего не чувствует.
Ну ладно, если вам так понятнее, то пусть будут хозяева бизнеса. Но связь здесь неразрывная, жаль, что вы её не видите.
>> И пример закупок из практики - купить и вернуть полотенцесушитель за 20 тыр. - 50 писем поставщику и обратно
Смысл здесь такой - вы находитесь на самом дне бюрократического болота, которое из себя представляет ваша контора. Вы видите вокруг много развесистых деревьев (трудностей), но не видите леса (причины проблем). Ваш взгляд из глубины искажён непониманием общей картины. А картина всё та же - бизнесу это не надо. Далее вам нужно объяснять длинную цепочку причинно-следственных отношений, которые приводят к вашему положению, но это долго, поэтому кратко скажу - это называется кусочная автоматизация (погуглите на досуге). Следствием такого подхода является неизбежный бардак и соответсвующее ему болото, в которое вы и погрузились, и похоже других (нормальных) условий обитания не представляете (иначе не указывали бы на следствия бардака как на причину "выгодности" облаков). На самом деле в вашем положении находятся, скорее всего, большинство работников IT-сектора, то есть в большинстве контор царствует бардак той или иной степени тухлости. И когда везде бардак - давление среды становится недостаточным, что бы бизнес захотел что-то исправить. Ну и далее попробуйте довести короткую цепочку выводов до "бизнесу это не надо".
>> Для каждой задачи есть какой-то отдельный тул, который ее решает. Связывать и настраивать все это для совместной работы - фул тайм работа для нескольких, далеко не дешевых, человек.
Здесь опять не то. Опять взгляд из подземелья. Вы видели некую интеграцию в каком-то из вариантов "облака", но не видели аналога в своей конторе, поэтому вам кажется, что нигде в мире нет ничего лучше "облака". Но ситуация почти противоположная. Облака писали постоянно подглядывая решения у взрослых, то есть в норамльно работающих цепочках обработки данных. И эти цепочки не могли быть ни в каком другом месте, кроме обычных серверов. То есть всё давно и основательно придумано и реализовано, но конкретно вы просто не встречались на своём жизненном пути с нормально построенными системами. Здесь "нормально" следует понимать как "не хуже, чем в облаках". И к тому же у вас задачи довольно мелкого уровня (все эти RunDeck-и и ELK-и). Проблемы логирования должны решаться на этапе проектирования, но разумеется, в вашей конторе никто и никогда не занимался серьёзным проектированием, а потому никто эти небольшие проблемы не решил, всё свесили на вас, видимо разработчика одной из подсистем. И вы с энтузиазмом принялись строить свой велосипед, но поняли, что на его строительство нужно много времени, ну и от безысходности начали выть на луну (на облака), мол вот там всё есть, а здесь меня мучают логами. Но нет никаких причин для неповторения ситуации один в один в случае, если вы перейдёте в облака. Бардак достанет вас и там. Так что не надо возлагать необоснованные надежды на сырую и от того убогую технологию, и тем более, выдвигать ваш бардак в качестве аргумента "за облака", потому что это лишь аргумент в доказательство отсутсвия у вас опыта работы в условиях с существенно меньшим бардаком.
>> В облаке вы 350 дней в году используете 30 машин, а 15 дней в году 300. В своем дата центре вы 365 дней в году используете 300 машин на 1% в среднем.
Посчитайте снова. Ваш расчёт должен дать коэффициент использования 10%, а не 1%. И такая ошибка сильно повлияет на выбор технологии.
>> В большой организации вы можете ждать сервер по полгода и больше
Это тоже искажающее картину соображение. Если бизнесу что-то реально надо - они найдут сервера за один день (ну поусть неделю). А если не надо, то вы по сути выдаёте стремление к каким-то личным достижениям за истину. Ваши личные достижения на самом деле интересны только вам лично. И хорошо, если контора готова иплачивать ваши игры даже через пол-года после их начала. Но к выбору технологии удовлетворение ваших потребностей не относится, потому что это совсем другая область оптимизации с кардинально отличающимися целями.
>> А отдать лишнее железо производителю не получится
И это не проблема. Вспомним, как сбербанк нашёл мощности для тренировки сети GPT-3. Или вы думаете они все 100% этого железа купили под одну единственную задачу? Нет, они нашли способ утилизировать коэффициент простоя оборудования. То есть если бизнесу надо - всегда найдётся способ загрузить или ещё как-то окупить мощности.
>> Также IAM - то есть возможно управлять доступом
А что не так с доступом? Я не спец по деталям настройки толстых серверов, но я отлично знаю, как выделяют виртуальные сервера и как нарезают для них ограничения по ресурсам. Так же и вы - выделяйте виртуалку и нарезайте ресурсы кому нужно. А если проблема в бюрократии, то значит вы опять подменяете реальные проблемы бизнеса своим представлением о них. Бюрократия всегда там, где бизнесу что-то не надо. Хотя вам может показаться, что ваше решение принесёт миллионы и т.д., но это всего лишь мираж. Для этого вы должны стать руководителем, тогда ваши идеи прорастут, даже если они ошибочные. А пока бизнесом рулят другие - прорастают их идеи, даже если они ошибочные. И вам не стоит убиваться по их проблемам, особенно если это следствие принятия ими ошибочных решений.
>> А сейчас думаю над обратной миграцией, потому что подрос и хочется IAM, ECS, Secrets Manager, Systems Manager и RDS. Делать все это руками на своем железе очень долго и дорого.
Я вам не подскажу конкретные инструменты такого плана, но я очень сильно сомневаюсь в том, что их нет для обычных серверов, но есть исключительно для облаков. Обычные сервера развивались многие десятки лет, а облака всего где-то десяток. Скорее всего вы просто не в курсе существующих решений, ну а реклама вам подсказывает - в облаках всё есть! Или вы познакомились с облачным решением и увидели там какие-то инструменты, которые никогда не использовали с обычными серверами, потому что обчные сервера админят обычные админы, а не вы. А теперь, не зная про инструменты для обычных серверов и обладая только лишь представлением об облаках, вы делаете неверный вывод.
В целом я соглашусь, что если сами хозяева облачных решений сильно захотят, то они для каких-то нишевых решений обеспечат реальные преимущества. Но пока хозяева не хотят. Их бизнесу это не надо. Они приняли вот такое решение. И судя по тому, что постоянно находятся желающие им заплатить, возможно это решение вполне правильное для сложившейся ситуации. А вы же пытаетесь доказать, что на самом-то деле хозяева не бизнес ведут, а благотворительностью занимаются, раздавая всем лучшие в мире технологии. Раздают, да ещё и бесплатно, только некачественные решения. Бесплатно заманивают и обещают обещать. Обычный бизнес, ничего личного.
Железо берут с запасом. Разве вы про это не знали?
Расчитывать строго на среднесуточную нагрузку и выбирать железо ровно по этой планке - очевидный признак идиота. Поэтому выбирают что-то более производительное, например раз в 10. Экономически это очень дёшево, поскольку железо окупится примерно за месяц на одной только рекламе, была бы нагрузка (посетители).
Второй момент - архитектура и реализация должны обеспечивать близкую к линейной деградацию времени отклика при перегрузке.
Если два обозначенных критерия выполнены, то при выбросах до 10 раз деградации не произойдёт. А при выбросах более 10 раз начнёт копиться долг, под который требуется память. Памяти на один запрос обычно требуется немного, поэтому узким местом при нагрузке *10max память станет лишь при большой длительности пика. Но "длительный пик" даст существенный прирост средней нагрузки, а потому такие варианты мы не рассматриваем, поскольку они предполагают нашу ошибку в расчёте средней нагрузки (что маловероятно в давно работающей среде, ну либо результат экспериментов всё тех же идиотов).
>> Это единственный кейс где serverless рулит, если система под него заточена.
Если вы готовы потратить большой бюджет на адаптацию ко всем косякам "облаков", тогда, возможно, вы как-то сумеете реализовать предложенный вариант масштабирования.
Но есть ещё традиционный подход. С ним не нужно тратить большие деньги на адаптацию. Хотя да, масштабироваться без заметных для пользователя тормозов сразу в сто раз будет непросто. Если бюджет ограничен и железом проблему не закидать, то в традиционном решении пользователь будет ждать, например, 10 секунд вместо одной. Опасно ли это для бизнеса? Скорее всего нет, поскольку это пиковая нагрузка, она затрагивает малую часть пользователей, остальные её не заметят, или заметят один раз из нескольких десятков посещений сервиса.
Но тут важнее другое - если у вас денег на железо нет, то значит и на облака у вас денег гарантированно нет. И характер этих денег отличается. Железо - одноразовые капитальные вложения, которые можно частично вернуть посредством продажи. Вложения же в адаптацию к убогости облачных решений являются постоянными. Облачные вендоры постоянно что-то меняют, а нормальных инструментов для анализа не предоставляют, поэтому выход один - постоянно держать дорогую команду ради этой самой адаптации. Такой вариант, очевидно, ни разу не подходит для экономии.
Но если с точки зрения экономии нет выгоды, то где же тогда она есть?
В целом вопрос сводится к оценке вложений в железо против оценки вложений в постоянную адаптацию. На мой взгляд выбор здесь очевиден. Хотя на взгляд бюрократа из толстой конторы, выделяющего деньги на вечно неэффективные проекты, особой разницы нет, оплачивать ли ими адаптацию как к косякам облачных сервисов, так и к косякам управления в большой конторе, или оплачивать ими одни только косяки управления в большой конторе, потому что последние стоят на порядок больше, чем косяки облачных решений.
То есть облака - для богатых и ленивых. Для тех, кто деньги всё же считает, облака в принципе не подходят. Никак. Никогда. Ни при каких условиях (кроме перехода на модель "богатый и ленивый").
Очередная реклама "облаков". Ну и навязывание новых смыслов старым терминам, заодно.
Бессерверным что-то бывает только тогда, когда сервера нет. А когда он есть, но называют его маркетинговым словечком "облако", то это опять всё тот же безумный маркетинг.
>> Такой подход позволяет более точно рассчитать экономику проекта в условиях невозможности спрогнозировать масштабы.
А вот это есть просто наглая ложь. Но, как всегда, слово "ложь" проплатившая рекламу контора возмущённо заменит на "маркетинг". Только замена слов на смысл не влияет. Прогнозировать что-то в ужасно глючных и практически неконтролируемых разработчиком решениях невозможно по определению. Ошибки и отсутствие возможности понять, где нам опять насчитали лишние десятки тысяч долларов - вот реальность "облаков". И как в таких условиях "точно рассчитать экономику проекта"?
>> Снимается боль бизнеса — оплата мощностей за время простоя.
А это откуда выросло? Во время простоя сервер БД потребляет, например, 100 ватт. За сутки - 2400 ватт. Один киловатт-час стоит 6 рублей. То есть в сутки имеем 14.4 рублей. В месяц не более 450 рублей. Да, это адская боль бизнеса!
>> Аргумент по части NoSQL такой, что бессерверные приложения по большей части в стартапах, когда нет истории, нет понимания будущей модели данных, прогнозов трафика.
А это очень правильное замечание - когда нет понимания (модели данных, прогнозов трафика и т.д.), тогда выбирают "сердцем", то есть покупаются на убогую рекламу "облаков".
>> Компания Pokémon Company первоначально выбрала NoSQL и столкнулась со сложностью поддержки бесперебойной работы узлов. Выбор SQL-решения позволил сократить узлы с 300 до 30 и свести к нулю время простоя и снижения производительности.
А это уже, видимо, что бы развеселить читателей. Компания покемонов решила "делать бизнес". Ничего не понимая, выбрали "облака". В результате получили 300 попгуаев нагрузки. Потом пришёл кто-то немного слышавший про нормальную разработку и в результате нагрузка уменьшена до 30 попугаев. Браво, в рекламе "облаков для дураков" такой пример очень выигрывает! Приходите, делаете адски тормозящий продукт на "облаке", а потом, возможно, вы даже найдёте способ сократить нагрузку на "облако" не менее чем в 10 раз. Но ради чего это всё? И это уже вопрос к недуракам. Ради больших затрат на разработку того, что будет в 10 раз медленнее, чем в случае выбора более проверенного временем решения? А есть ведь ещё одно проверенное временем решение - вообще отказаться от облаков, а не просто поменять NoSQL на SQL.
>> Компилятор при всех своих гигабайтах и десятках ядер не может ни при каких условиях узнать во многих случаях, куда пойдет ветвление
Это ваш единственный аргумент? Пробегитесь по комментариям, там уже дали на него ответ. Хотя ответ любому разбирающемуся в матчасти и так понятен.
Что такое предсказание ветвлений? Направления два - исполнение сразу по двум ветвям и сбор статистики. Эти функции в обычных процесорах реализованы в железе. Для VLIW ровно эти же функции ничто не мешает реализовать в виде наполнения пустующих слотов в потоке инструкций. То есть в обоих случаях предсказание будет. А если оба случая эквивалентны по имеющейся информации, но один из случаев всё же более качественно оптимизирован за счёт привлечения полноценного компилятора, то кто же выиграет? И вот таких элементарных вещей вы не понимаете?
Автор смешал тёплое с мягким. Он объявил бесперспективной конкретную разработку, а в реальности оспаривает лишь технологию, задействованную в данной разработке.
Эльбрус, как конкретная разработка, бесперспективен в рамках системы, в котрой ему приходится существовать. А технология, объявленная автором плохой, вполне может выиграть конкурентную борьбу даже в рамках существующей системы.
Далее рассмотрим конкретнее некорректность претензий автора именно к технологии VLIW.
Разумеется, это не так. Портированию подлежит лишь то, что скомпилировано под конкретную архитектуру. Но мир развивается, и равитие несёт нам свободу от монополий. Есть всем известные примеры языков, компилируемых в байт-код или же в оптимальный машинный код, но на этапе исполнения. Если автор обратит внимание на эти всем известные подходы, то "проблема" с портированием моментально испарится. Останется только осилить базовые библиотеки на компилируеммом в байт-код языке, что бы не плакать о "невозможности портировать" что-то чужое.
Не "мы не можем", а система, которая ограничивает нас всех, не способна ни на что большее, нежели набор завиральных обещаний о великих победах в будущем.
Абсолютно необоснованное заявление. Сравнение может проводиться (если сторона обвинения VLIW вообще этим озадачивалась, в чём я сомневаюсь) только с одной известной приличной попыткой - Itanium. Всё остальное - либо теоретизирование без денег, либо вот Эльбрус, который рождён в условиях всем известных ужасных ограничений. И вот на основании стравнения с явно ограниченными вариантами, делается далеко идущий вывод.
Здесь всё зависит от объёма памяти и количества вычислений на этапе компиляции. У процессора, который в железе реализует то же самое, и памяти и вычислений на порядки меньше. Но автор настаивает на своём, забывая об очевидных возражениях.
Опять же здесь стоит напомнить о технологиии, которая существует уже лет 25. Называется она "just in time" компиляция. И профиль там, безусловно, есть. А вот значимость, придаваемая автором данной проблеме, явно завышена. В целом статья демонстрирует именно произвольно надёрганный набор из ряда типичных возражений сторонников традиционного подхода, но ни в коем случае не демонстрирует системность подхода и уж тем более, какие-то расчётные или статистические выкладки.
А здесь вообще декларируется наличие магии внутри традиционных решений. То есть всю логику, которая зашита в железе, противники VLIW считают в принципе недоступной для реализации в альтернативных решениях. Как может быть недоступно то, что доступно процессору с его крошечными мозгами, полноценному компилятору с его доступом к гигабайтам памяти и десятку ядер при компиляции? Только за счёт магии. Но здесь главное - верить, ну и излагать мксимально безапелляционно.
Если что-то не заинлайнено компилятором, то это что-то, по мнению автора, автоматически заинлайнится процессором. А теперь вспомним про различие в количестве доступной памяти и вычислительных циклов между полноценным компилятороми и ограниченным в этом всём процессором. Вопрос - кто сможет оптимизировать лучше?
Ну это же классическая манипуляция с указанием на худший вариант против лучшего. Автор берёт VLIW и предполагает, что он совсем тупой и ничего не умеет. Потом он берёт обычный процессор и предполагает, что он умеет абсолютно всё. А затем автор сравнивает два таких варианта. И, о чудо, внезапно побеждает именно идея автора о превосходсьтве "белой расы".
В целом статья пустая. Нет ни статистики, ни расчётов, хотя есть много необоснованных зявлений и натянутых предположений.
Для нормальной работы качественных разработчиков нужна соответствующая среда. Поэтому качественные разработчики либо её находят (что редкость), либо тихо вымирают (встречается чаще).
Достаточно посмотреть массовые вакансии - требуются исключительно узкие навыки. Поэтому качественный разработчик вынужден по быстрому осваивать очередне модное веяние и далее ковырять оное в обычной и убогой, с точки зрения качества, конторе.
Хотя скорость освоения моды у таких разработчиков сильно выше остальных. Так же помогает психологическая готовность к изучению нового (это просто, потому что принципы там обычно детские, максимально адаптированные под массовых кодеров). Это всё даёт возможность оперативно менять работу при необходимости.
Но в целом ниша кодеров на порядки толще. Как и во всём остальном - китай доказал, что некачественные, но дешёвые, вещи, вполне конкурентоспособны.
Какой подход в итоге победит? Ответ - победят роботы.
Как российский сегмент вообще может работать, хоть с модулем, хоть без модуля, если он из-за усталостного разрушения трещит и рвётся по швам? Какие 10 лет? Откуда такие сказки?
И в чём будет выражено повышение научной эффективности? В постоянном устранении массы больших и малых проблем с новым модулем? Плюс всеми любимый поиск трещин и прочие увлекательные заняти по ремонту запчастей типа "сделаноунас".
Фактически статья свелась к и без неё понятному указанию на убогость нашего "космоса" (точнее того, что от него осталось), плюс к столь же очевидному указанию на неизменно лживые заявления роскосмоса. Я, конечно, за правду, за критику паразитов в высоких креслах, но хоть чего-нибудь бы про науку, про технологии, про то же IT. Но нет, всё, что можно вытянуть из рассейского космоса - лишь очередное доказательство его убогости.
ЗЫ. И очень в тему здесь убогость нового редактора сообщений хабра. Он примерно как роскосмос - даже что-то умеет, но никогда не сделает это правильно и удобно. Потому что природа у этих двух субъектов общая, видимо.
Вы свои предложения выше перечитайте. Там вы указываете на важность доверия к инструменту. И вот предлагаете нанять стороннюю контору, которая будет весело и со свистом сливать все данные, до которых дотянется.
Про авааз. Я не знаю, на сколько вы близко с ними общались, но я вот не поленился и посмотрел их отчёты. На самом деле немного времени нужно, всё до боли очевидно, но детали вы и сами найдёте, если не являетесь верующим в розовых пони.
Такие фонды выполняют грязные дела для их создателей. Когда у кого-то много денег, и он хочет чего-нибудь запрещенного в его стране регистрации, он создаёт вот такие фонды, ну и рассказывает вам про 42 миллиона участников. Реальных дел (для прикрытия) они делают на сумму, меньшую чем 4% от поступлений, и все дела из серии "марш за права живонтных", то есть абсолютно бессмысленные, только ради замыливания ваших мозгов. А на сайте они пишут про "победы" - оказывается это они "победили" и теперь все зелёные технологии по их инициативе внедряются. Ну да ладно, если вы им уже перевели денег, то только злость на меня в вас разжигаю, поэтому не буду продолжать.
Если говорить коротко - никаких 210 миллионов участников у вашей идеи не будет. А миллионы евро для тех, кто может себе позволить привлекать такие массы, это какие-то копейки, о которых они никогда думать не будут.
И, до кучи, вся эта электронная байда, за которую спекулянты пока ещё дают денег, по своей ужасна, безумна и т.д. и т.п. Ваша поддержка грязи типа авазов - ещё ужаснее. А ещё подумайте - кому вы хотите помочь? Ответ - только себе. Вам нравится обсуждать вашу идею, а помощь кому-то здесь даже рядом не стояла. Вы, по сути, продаёте свою идею очередным спекулянтам и прочим буржуям, у которых есть деньги, но у которых кончились идеи по охмырению граждан. Правда вы такой не один, вас таких миллионы, поэтому от вашего личного вклада люди пострадают не очень сильно. Но может всё-таки хоть немножко задумаетесь.
О себестоимости.
Сколько стоит создать криптомайнер? А потом к нему прикрутить чат. А потом к нему прикрутить...
Получившуюся сумму нужно вычесть из того, что получится намайнить.
Я вам простую вещь скажу, только вы не обижайтесь.
Это дорого (с).
Окупаемость будет лишь на проектах, где за год можно намайнить тысяч 20-30 вечнозелёных. Делим на три копейки (цента) с носа. Получаем 3 миллиона участников за год по три цента каждый. И где вы видели такие организации? В смысле не спонсируемые бизнесом или государством, разумеется. На всю рассею имеем одного Навального с каким-то потенциалом, но и он не осилит 3 миллиона. Никак. Никогда.
Даже незнаю, где бы нишу для вашей идеи найти.
В математике алгебра (как и другие формальные теории) используется очень широко, поэтому она даётся на начальном этапе университетской подготовки математиков. Если этот этап пропущен - получается как раз ваше положение.
Просто вот такая там база. Она могла бы быть другой, но с этим вопросом к нынешним математиками не стоит подходить, потому что они давно привыкли жить именно с этой базой. Точнее - привыкли с самых ранних этапов обучения в универе. И переучиваться на что-то другое ради вашего удобства для них несколько напрягающая задача.
Хотя если не сводить всё к полям, кольцам и прочим решёткам, то в некоторых местах математика и для самих математиков стала бы проще. Но реформу в математики в современном обществе начинать не стоит, уж точно. Потому что общество не готово, а если оно "не тянет", то сами математики без живительного пинка никогда за такую задачу не возьмутся.
Если делить работников по аналогии с системой образования в СССР, то большинство одноэсников были бы обычными выпускниками ПТУ. Программисты - это выпускники техникумов, отличаются от ПТУ-шиков более широким взглядом на свою сферу деятельности.
Но для устранения дисбаланса в сторону ПТУ-шников нужны выпускники университетов. А большинство программистов, это именно техникум, даже не заштатный уездный ВУЗ. Некоторые всё же дорастают до уровня именно заштатного и именно уездного института, но таких мало. Очень мало.
И почти никто не дорастает до университета. Потому что спроса нет. То есть засилье ПТУ-шников бизнес вполне устраивает. Но если посмотреть с точки зрения максимизации пользы для всего общества, то станет очевидно, что ПТУ-шников можно сократить на порядки. В результате не только их зарплаты пойдут в плюс, но и масса косвенных затрат почти всех бизнесов будет уменьшена очень серьёзно. И эта масса намного больше, чем зарплаты ПТУ-шников. Но если вспомним, что 1С не является исключением, и во всех других областях всё обстоит точно так же, то можно легко представить порядок косвенных затрат.
Правда есть минус (временный). Все те, кто сегодня занимается лечением бардака, который настрадали стада ПТУ-шников, вынуждены будут искать работу. И там уже нужно будет думать, а к этому привыкшие гуглить бойцы с бардаком непривычны. Но это не беда. Они же привыкли подчиняться, значит тупо будут выполнять все указания по переучиванию и включению мозгов. Останется лишь сделать систему обучения, которая всех привыкших к полной покорности приведёт к свету. Правда опять есть одно "но". Большой бизнес в результате сильно (реально сильно) пострадает. Покорные овцы начнут пробовать думать. Да, это будет удар...
Вот так, просто нормальная система образования, и никаких вам ПТУ-шников, пишущих говнокод. Но "это дорого" (с).
Ваш подход предлагает "некое" решение, но не показывает сравнения такого решения с оптимальным. Почему пользователь обязан верить вашим словам про оптимальность? Просто потому, что "вроде как оно попхоже на правду"?
Нормальное исследование обязательно включает задачу нахождения области применимости разработанной технологии. А применимость сразу выводит на очень простую оценку результата - есть выгода или нет. Ваша же теория ничем подобным похвастаться не может. А всё потому, что нет обоснованного сравнения с аналогами и с идеалом. Хотя для очередного бумажного накачивания каких-нибудь безумных рейтингов, наверно статья подходит.
Вот так незамысловато авто задаёт тон дальнейшему повествованию. Ну а дети, читающие про "прогрессивные круги" и "задумчиво" что-то там пожимающих, разумеется, впадают в панику - а меня-то тоже могут не посчитать прогрессивным!!! И на меня задумчиво посмотрят и что-то пожмут! А-а-а-а, боюсь!
Дети, не бойтесь, этот дядя только делает вид, что он умный. На самом деле он такой же как и вы, но немного познакомился с так называемыми "манипулятивными техниками". Это такие техники, которые применяют на детях. Потому что на взрослых их применть бесполезно. А дети, благодаря своему детскому восприятию мира и себя в мире, не способны противостоять таким примитивным и шаблонным техникам. Ну что с них взять - они же дети.
Но с другой стороны, дети, помните - так вас могут завести в тёмный переулок и изнасиловать мозг. Это больно. Но не сразу, а потом, когда вы станете взрослыми. Вот тогда становится очень неприятно за все те ваши собственные действия, которые вы согласились сделать, получив от подобного автору дяди дозу насилия прямо в детский и пока ещё беззащитный мозг.
Итак, ваш мозг насилуют. И мне жаль, дети, что я не могу вас вылечить быстро. Но я знаю одно волшебное снадобье, которое очень тернирует мозг и делает его бессмысленной целью для маньяков-манипуляторов. Это средство называется "много думать". Или просто - Многодум. Давайте я покажу вам, маленькие дети, как это средство работает.
Допстим, дети, вам злые маньяки рассказывают о старшной престрашной комнате, в страшном престрашном доме, в страшном престрашном городе, в страшной престрашной стране. Представили? Вам ведь уже страшно? Нет? Ну тогда представьте, что это рассказываю не я, а очень важный дядя в телевизоре. Представили? И допустим, дядю зовут так - президент. Теперь страшно?
Ну вот, когда вы всерьёз испугались, дети, вам должно стать ещё страшнее! Потому что президент говорит - мы все умрём! Вы уже упали со стула? Нет? Тогда срочно спрячьтесь под стол! Потому что злые маньяки-манипуляторы давно выяснили, что во время землятрясения под столом безопаснее всего! И дядя-президент о том же вам говорит.
А теперь лекарство.
Дети, сначала нужно просто понять - что вам сказали. Потом нужно подумать, а правильно ли вы поняли, что вам сказали. Потом нужно найти доказательства того, что вам сказали. Да дети, взрослые дяди могут врать. Поэтому если вы найдёте доказательства, тогда переходите к сдледующему пункту рецепта выздоровления. А если не найдёте - срочно бегите от таких дядь и тёть, потому что они - злобные маньяки-манипуляторы.
Разберём маленький пример.
Вам сказали, что мы все умрём. Вам стало страшно. Вы надели намордник и презервативы на пальцы (умные учёные говорят, что это помогает от всего). Но теперь настал черёд принять лекарство. Оно не страшное, по началу немного напрягает, а потом начинает нравиться. Итак - подумайте, а есть ли доказательства того, что мы все умрём? И оказывается, что из доказательств только слова неких надевших белые халаты лиц неопознанной национальности (они ведь в намордниках, как их распознать). И с другой стороны, у вас есть мощный инструмент, котороый называется "статистика". Да, вы ещё маленькие и никогда не слышали про такие инструменты, но когда-то же надо начинать, правильно? Вот и начните сейчас - скачайте статистику по смертности с тех сайтов, которым можно доверять. Как выбрать вызывающие доверие сайты? Ну это не сложно - нужно подумать, а почему я им должен доверять? А потом найти доказательства, что им действительно можно доверять. И всё, после этого, глядя на статистику, вы легко поймёте, что никто нигде не собирается умирать, что злые дяди маняки и манипуляторы вас просто обманывают, что им верить нельзя, а вся шумиха вокруг "мы все умрём" поднялась из-за таких же как вы детей, которые ещё не научились пользоваться таким простым инструментом, как статистика. А всё потому, что они не пили на ночь нашего волшебного лекарства для их крошечного и недоразвитого мозга.
Вот так дети, развивайте мозг и не верьте злобным маньякам-манипуляторам, даже если их зовут как-ниубдь страшно, например - президент. Ведь вы уже почти взрослые! Такие почти взрослые дети уже ничего не должны бояться!