Я бы не слишком надеялся на Интел. Летом 2021 он выдал по ОЕМ-каналам неадекватный Iris Xe DG1 (совместим только с процессорами Intel, и то далеко не со всеми поколениями, ужасного качества драйвера, производительность на уровне мобильных аналогов), и у меня нет оснований надеяться, что Arc будет чем-то лучше, по крайней мере, на старте. Если рынок готов поглотить любое убожество, зачем стараться?
А ведь мы отлично живём без видеокарт! Я имею в виду тенденции в игровой индустрии. Дискретке в моём десктопе уже 5 лет от роду, причём это не хай энд, а так -- типичный середнячок. Но все современные AAA-игры работают без проблем. Видел на ютубе прохождение God of War на встройке Athlon 3000G. Понимаете, к чему я клоню? Если бы не дефицит чипов, нас уже развели бы на один-два бессмысленных апгрейда.
В статье описаны некоторые реальные проблемы фреймворка, но натяжек и вкусовщины в ней, наверное, больше. Я не хочу разбирать статью от начала до конца, скажу только за один пункт, на котором я уже привычно теряю терпение в последние годы.
Не конфигурируйте Django через переменные среды. Никогда. На это есть достаточно причин.
Django основан на WSGI, WSGI -- это расширение CGI, а в CGI env vars используются для связи с веб-сервером/прокси. Они уже заняты, и по стандарту, и исторически. Неужели надо придумывать ещё какие-то "де факто", чтобы использовать вещь не по назначению?
Переменные среды хранят текст. Для Perl или Bash в этом нет никакой проблемы, но для Python приходится писать парсер/валидатор, который будет дополнительным (и совершенно ненужным) источником ошибок и уязвимостей в вашем приложении.
Переменные среды -- это диагностическая информация, а многие инструменты имеют привычку показывать диагностику при сбоях. Таким образом утекло уже достаточно секретов.
Конфигурация -- это код. Любая достаточно сложная система конфигурирования однажды вырастает в динамический ЯП, иногда даже Тьюринг-полный. Зачем изобретать новый ЯП? Просто пишите конфигурацию на Python.
Как же тогда конфигурировать Django-приложение, если не через файлы среды? Ответ прост: конфигурируйте его через файлы конфигурации.
Если у вас один проект/сервер, храните *.py-файл с секретами вне репозитория, а при установке копируйте его на место (вручную или скриптом, например, Fabric хорош для создания маленьких деплой-скриптов) и импортируйте в основной файл конфигурации.
Если у вас большой проект, то те инструменты для CI/CD, которые вы уже используете, наверняка позволяют шаблонизировать файлы конфигурации. Храните секреты в файлах конфигурации CI/CD или в специальных хранилищах секретов, и внедряйте их через шаблоны в конфиги при деплое.
В багтрекере сквирела уже не первый год висит пара-тройка багов, подобных этому. Может, и именно этот. Приоритет у них ниже некуда, почти wontfix, потому что "сквирел не предназначен для выполнения недоверенного кода". И вообще, сквирел -- проект одного человека, да и тот кмк выгорел.
Для меня самым явным свидетельством развития технологии является её положение на рынке. Я не агитирую за убийство животных как неотъемлемую часть человеческой культуры. Я готов питаться любой вкусной, полноценной и доступной пищей, независимо от её происхождения.
Но давайте посмотрим на технологии, о которых вы говорите в своей статье, через потребительские характеристики соответствующих товаров.
Вкус. По вкусу "растительное мясо" даже не напоминает натуральное мясо, а напоминает скорее низкокачественные мясные продукты, в которые для удешевления добавляются растительные добавки. Что, в принципе, логично.
Диетические свойства. Растения не содержат некоторых витаминов и незаменимых аминокислот. Конечно, можно их добавить и в привычные растительные продукты, если "поиграть" с генами, но ГМО сейчас -- жупел, и на это никто из производителей не пойдёт. Использовать вещества животного, микробиологического или синтетического происхождения? Это скажется отрицательно на себестоимости.
А по себестоимости "растительное мясо" и так проигрывает натуральному.
То есть о превосходстве по сумме потребительских характеристик даже говорить не стоит. Значит, агитировать потребителя пока рано, надо серьёзно работать над технологиями.
К сожалению, тенденция, которую я вижу в вашей статье -- это стремление перекроить рынок, воспользовавшись идеологией вместо технологии. Наклеив "зелёный" ярлык и воспользовавшись эмоциональным давлением. Это грустно. И это так или иначе просматривается сейчас и по всем другим направлениям, которых вы коснулись: энергетика, транспорт и т. д.
Проблемы с логикой начинаются с посылки, что на климат вообще надо влиять явно. Это прямая дорога к гигантским рискам.
Я, возможно, чего-то не понимаю, но, если не управлять климатом осознанно, то к чему тогда вообще что-либо предпринимать? Будь что будет. Если со временем климат Земли изменится так, что выживание всего человечества или его части будет невозможно (потепление, опустынивание, потоп -- чем там ещё нам грозят экологи), то всё, что мы сможем сказать в таком случае -- "Я тут не причём, я даже мяса не ел". Ради этого сомнительного морального превосходства вы призываете к самоограничениям?
Не говоря уже о том, что мы с вами, видимо, по-разному понимаем риски. Риски высоки, когда вы не управляете ситуацией. Примерно как сейчас человек не управляет климатом на своей планете. Когда есть возможность управлять ситуацией, тогда риски снижаются. Вместо рисков приходят последствия осознанных действий.
Мы знаем, что в истории Земли (и даже в истории человечества), экологические катастрофы уже происходили, жизнь уже бывала на грани уничтожения, и неоднократно. Почему для вас так важно не решить проблему выживания человека принципиально и окончательно, а получить тридцать лет отсрочки, чтобы... Научиться в итоге ни на что не влиять? Как это смело и амбициозно!
Третий пункт лишён логики.
Это логика индустриального этапа развития человечества. Потребление стимулирует прогресс, потребительский аскетизм его замедляет. Это сейчас немодная тема, я понимаю, но приемлемых альтернатив я не вижу.
Я абсолютно согласен, что мы должны очень быстро развивать технологии
Как же мы их будем развивать при отсутствии спроса на них? Если административным путём, как в СССР, то нет, спасибо, я не хочу возвращаться в это общество.
Для меня сейчас очевидны и логичны следующие вещи:
Человечество не умеет на данном этапе развития осмысленно и направленно влиять на климат. Даже умозрительно.
Для управления климатом нужно, помимо прочих технологий, уметь получать на много порядков больше энергии, чем мы вырабатываем сейчас.
Любые ограничительные меры (в потреблении, торговле, передвижении) замедляют развитие энергетики и других технологий, критичных для управления климатом, тем самым увеличивая вероятность гибели человечества в экологической катастрофе (естественной или техногенной).
Насколько я понял из предыдущих видео Джеффа, основная проблема в том, что карта не инициализируется. На x86 инициализация видеокарт традиционно производится проприетарным кодом, который записан во флеш-память карты и запускается из BIOS/UEFI. RPi не имеет UEFI и не может запускать код для x86.
Интересно, какова вероятность такого сюжетного поворота, что опасность ковида-19 обусловлена в основном успехами человечества в борьбе с курением? Примерно как симптомы гонконгского гриппа оказались один в один с передозировкой аспирина...
Конфиги могут быть для пользователей. Они не обязательно должны быть знакомы с нюансами ваших языков программирования.
В простых конфигах нет никаких нюансов, кроме "имя = значение". Исключения, опять же, могут быть, вроде Forth с обратной польской нотацией, но в большинстве случаев для непрограммиста что присваивание в Python, что "ключ-значение" в ini-файле -- разницы нет.
Если же конфиг по ходу дела становится сложным, появляется шаблонизация, переменные, макросы и т. д., то "формат данных" превращается в доморощенный язык программирования. Скорее всего даже Тьюринг-полный, зато непопулярный, плохо документированный и глючный. Всё ещё не видите проблемы?
Ошибки в конфигурации должны обрабатываться иначе, нежели ошибки в программном коде.
И это в любом случае остаётся на совести программиста. Иначе пользователю без разницы, откуда вылез стек-трейс: из парсера формата данных или из самого интерпретатора.
В таком случае это скорее входные данные, чем код. Почему бы не использовать форматы, предназначенные для данных?
Разница между кодом и данными может казаться призрачной (Lisp!). Мне проще всего объяснить, почему конфигурация -- это код, а не данные, с помощью правила "ноль-один-бесконечность". Нам на практике интересен только ограниченнный набор "корректных" конфигураций, но при этом мы заинтересованы корректно обрабатывать бесконечное разнообразие данных.
Почему формат данных плохо подходит для кода, я, надеюсь, уже объяснил.
Для проектов на компилируемых языках конфигурация -- это код, выполнение которого отсрочено от времени компиляции до времени выполнения. В динамических языках компиляция не отделяется от выполнения, поэтому и нет нужды хранить конфигурацию в каком-то особом формате. Разве что за исключением совсем сложных случаев, вроде того же Vault. А всякие JSON, XML, YAML, ini, env и т. д. попадают в проекты на Python по недоразумению
Я бы не слишком надеялся на Интел. Летом 2021 он выдал по ОЕМ-каналам неадекватный Iris Xe DG1 (совместим только с процессорами Intel, и то далеко не со всеми поколениями, ужасного качества драйвера, производительность на уровне мобильных аналогов), и у меня нет оснований надеяться, что Arc будет чем-то лучше, по крайней мере, на старте. Если рынок готов поглотить любое убожество, зачем стараться?
А ведь мы отлично живём без видеокарт! Я имею в виду тенденции в игровой индустрии. Дискретке в моём десктопе уже 5 лет от роду, причём это не хай энд, а так -- типичный середнячок. Но все современные AAA-игры работают без проблем. Видел на ютубе прохождение God of War на встройке Athlon 3000G. Понимаете, к чему я клоню? Если бы не дефицит чипов, нас уже развели бы на один-два бессмысленных апгрейда.
Здорово. А форк публичный? Можно посмотреть?
А вы заметили, как любое описание софта без ссылки на исходники воспринимается как скам?
В статье описаны некоторые реальные проблемы фреймворка, но натяжек и вкусовщины в ней, наверное, больше. Я не хочу разбирать статью от начала до конца, скажу только за один пункт, на котором я уже привычно теряю терпение в последние годы.
Не конфигурируйте Django через переменные среды. Никогда. На это есть достаточно причин.
Django основан на WSGI, WSGI -- это расширение CGI, а в CGI env vars используются для связи с веб-сервером/прокси. Они уже заняты, и по стандарту, и исторически. Неужели надо придумывать ещё какие-то "де факто", чтобы использовать вещь не по назначению?
Переменные среды хранят текст. Для Perl или Bash в этом нет никакой проблемы, но для Python приходится писать парсер/валидатор, который будет дополнительным (и совершенно ненужным) источником ошибок и уязвимостей в вашем приложении.
Переменные среды -- это диагностическая информация, а многие инструменты имеют привычку показывать диагностику при сбоях. Таким образом утекло уже достаточно секретов.
Конфигурация -- это код. Любая достаточно сложная система конфигурирования однажды вырастает в динамический ЯП, иногда даже Тьюринг-полный. Зачем изобретать новый ЯП? Просто пишите конфигурацию на Python.
Как же тогда конфигурировать Django-приложение, если не через файлы среды? Ответ прост: конфигурируйте его через файлы конфигурации.
Если у вас один проект/сервер, храните *.py-файл с секретами вне репозитория, а при установке копируйте его на место (вручную или скриптом, например, Fabric хорош для создания маленьких деплой-скриптов) и импортируйте в основной файл конфигурации.
Если у вас большой проект, то те инструменты для CI/CD, которые вы уже используете, наверняка позволяют шаблонизировать файлы конфигурации. Храните секреты в файлах конфигурации CI/CD или в специальных хранилищах секретов, и внедряйте их через шаблоны в конфиги при деплое.
Самая важная концепция, которую я усвоил на примере этого поста -- gatekeeping. Своих различаем, чужих не пущаем.
DeaDBeeF
Дежавю. Вроде как пару дней назад видел эту статью.
В багтрекере сквирела уже не первый год висит пара-тройка багов, подобных этому. Может, и именно этот. Приоритет у них ниже некуда, почти wontfix, потому что "сквирел не предназначен для выполнения недоверенного кода". И вообще, сквирел -- проект одного человека, да и тот кмк выгорел.
https://neos.com/
Цукерберг опоздал, у нас уже есть Neos. Все фурфаги уже там.
Для меня самым явным свидетельством развития технологии является её положение на рынке. Я не агитирую за убийство животных как неотъемлемую часть человеческой культуры. Я готов питаться любой вкусной, полноценной и доступной пищей, независимо от её происхождения.
Но давайте посмотрим на технологии, о которых вы говорите в своей статье, через потребительские характеристики соответствующих товаров.
Вкус. По вкусу "растительное мясо" даже не напоминает натуральное мясо, а напоминает скорее низкокачественные мясные продукты, в которые для удешевления добавляются растительные добавки. Что, в принципе, логично.
Диетические свойства. Растения не содержат некоторых витаминов и незаменимых аминокислот. Конечно, можно их добавить и в привычные растительные продукты, если "поиграть" с генами, но ГМО сейчас -- жупел, и на это никто из производителей не пойдёт. Использовать вещества животного, микробиологического или синтетического происхождения? Это скажется отрицательно на себестоимости.
А по себестоимости "растительное мясо" и так проигрывает натуральному.
То есть о превосходстве по сумме потребительских характеристик даже говорить не стоит. Значит, агитировать потребителя пока рано, надо серьёзно работать над технологиями.
К сожалению, тенденция, которую я вижу в вашей статье -- это стремление перекроить рынок, воспользовавшись идеологией вместо технологии. Наклеив "зелёный" ярлык и воспользовавшись эмоциональным давлением. Это грустно. И это так или иначе просматривается сейчас и по всем другим направлениям, которых вы коснулись: энергетика, транспорт и т. д.
Я, возможно, чего-то не понимаю, но, если не управлять климатом осознанно, то к чему тогда вообще что-либо предпринимать? Будь что будет. Если со временем климат Земли изменится так, что выживание всего человечества или его части будет невозможно (потепление, опустынивание, потоп -- чем там ещё нам грозят экологи), то всё, что мы сможем сказать в таком случае -- "Я тут не причём, я даже мяса не ел". Ради этого сомнительного морального превосходства вы призываете к самоограничениям?
Не говоря уже о том, что мы с вами, видимо, по-разному понимаем риски. Риски высоки, когда вы не управляете ситуацией. Примерно как сейчас человек не управляет климатом на своей планете. Когда есть возможность управлять ситуацией, тогда риски снижаются. Вместо рисков приходят последствия осознанных действий.
Мы знаем, что в истории Земли (и даже в истории человечества), экологические катастрофы уже происходили, жизнь уже бывала на грани уничтожения, и неоднократно. Почему для вас так важно не решить проблему выживания человека принципиально и окончательно, а получить тридцать лет отсрочки, чтобы... Научиться в итоге ни на что не влиять? Как это смело и амбициозно!
Это логика индустриального этапа развития человечества. Потребление стимулирует прогресс, потребительский аскетизм его замедляет. Это сейчас немодная тема, я понимаю, но приемлемых альтернатив я не вижу.
Как же мы их будем развивать при отсутствии спроса на них? Если административным путём, как в СССР, то нет, спасибо, я не хочу возвращаться в это общество.
Для меня сейчас очевидны и логичны следующие вещи:
Человечество не умеет на данном этапе развития осмысленно и направленно влиять на климат. Даже умозрительно.
Для управления климатом нужно, помимо прочих технологий, уметь получать на много порядков больше энергии, чем мы вырабатываем сейчас.
Любые ограничительные меры (в потреблении, торговле, передвижении) замедляют развитие энергетики и других технологий, критичных для управления климатом, тем самым увеличивая вероятность гибели человечества в экологической катастрофе (естественной или техногенной).
Ого, информация из первоисточника! =)
Насколько я понял из предыдущих видео Джеффа, основная проблема в том, что карта не инициализируется. На x86 инициализация видеокарт традиционно производится проприетарным кодом, который записан во флеш-память карты и запускается из BIOS/UEFI. RPi не имеет UEFI и не может запускать код для x86.
Интересно, какова вероятность такого сюжетного поворота, что опасность ковида-19 обусловлена в основном успехами человечества в борьбе с курением? Примерно как симптомы гонконгского гриппа оказались один в один с передозировкой аспирина...
В простых конфигах нет никаких нюансов, кроме "имя = значение". Исключения, опять же, могут быть, вроде Forth с обратной польской нотацией, но в большинстве случаев для непрограммиста что присваивание в Python, что "ключ-значение" в ini-файле -- разницы нет.
Если же конфиг по ходу дела становится сложным, появляется шаблонизация, переменные, макросы и т. д., то "формат данных" превращается в доморощенный язык программирования. Скорее всего даже Тьюринг-полный, зато непопулярный, плохо документированный и глючный. Всё ещё не видите проблемы?
И это в любом случае остаётся на совести программиста. Иначе пользователю без разницы, откуда вылез стек-трейс: из парсера формата данных или из самого интерпретатора.
Разница между кодом и данными может казаться призрачной (Lisp!). Мне проще всего объяснить, почему конфигурация -- это код, а не данные, с помощью правила "ноль-один-бесконечность". Нам на практике интересен только ограниченнный набор "корректных" конфигураций, но при этом мы заинтересованы корректно обрабатывать бесконечное разнообразие данных.
Почему формат данных плохо подходит для кода, я, надеюсь, уже объяснил.
Для проектов на компилируемых языках конфигурация -- это код, выполнение которого отсрочено от времени компиляции до времени выполнения. В динамических языках компиляция не отделяется от выполнения, поэтому и нет нужды хранить конфигурацию в каком-то особом формате. Разве что за исключением совсем сложных случаев, вроде того же Vault. А всякие JSON, XML, YAML, ini, env и т. д. попадают в проекты на Python по недоразумению
Нет, но я знаю тех, кто занимается: https://twitter.com/Foone/status/1416085249784569857