Забавно, что автор приводит в пример только переменные и аргументы, но мы все забываем про поля объектов, с которыми я больше всего стрелял в ногу в нетипизироваными языками.
Можно допустить банальную опечатку и вместо user.lastName = 'John' написать user.lstName = 'John' и в итоге у нас в объекта будет два поля, одно с опечаткой и второе без.
Статический бы язык отловил это на этапе компиляции.
Вторая проблема с полями это их переименование. При необходимости переименовать функцию или поле, при использовпнии статики ide имеет достаточно информации, чтобы заменить по всему коду. В динамике же у меня был конкретный слкчай с pycharm, где переименование автоматическое заменило только в 2х местах, а использований было 5.
Благо с переименованием локальных переменных и в динамических языках ide справляется.
Но с полями приходится делать поиск по тексту во всех файлах проекта и вручную делать замену.
Допустим есть два класса:
Image и Person у которых есть поле name.
Поступила бизнес задача добавить человеку firstName и lastName.
Добавляем ласт нейм и просто нейм переименовываем в firstName.
Типизированые языки позволят автоматически это сделать.
В динамически типизированых же придется следить, чтобы случайно не переименовалось использование поля у Image.
Это очень ужасная вещь, так как оно генерирует иннер класс, который к тому-же захватывает в себя локальные переменные. Это даже может привести к утечкам памяти.
Да оно понятно. Просто вопрос "зачем нужен докер" страннопрозвучал, если веб 80% задач неткора. Можно и без докера. :-)
Хотя мне не нравится деплоить без него, надо расшариваться с system.d и деплоить через ansible, а это лень.
А почему Core, а не фреймворк?
P.S. в UWP же изначально кор был?
вот только секьюр бут уже не работает, после такого.
Вот была бы возможность кастомные ключи добавлять.
Можно по интересоваться, под что разрабатываете на неткоре?
Под IIS? или если под юникс, то как запускаете сервера?
Не думаю что много кто на неткоре делает CLI утилиты или UI на Avalonia.
все намного проще. В зашифрованом виде пароли на HDD, а в чипе только ключ шифрования.
ARM double endian, зависит от флагов компиляции по сути.
При чем сjвременній iOS little endian — пруф, вот PowerPC был Big-endian
Android is always little-endian.
Прикольная статейка, но практическая польза не очень большая, уже давно все 64 битное, а тут 32 битный код :(
Про то что можно выковырять список загруженых длл через fs не знал. Похоже что рандомизация адресов превратилась в тыкву
Забавно, что автор приводит в пример только переменные и аргументы, но мы все забываем про поля объектов, с которыми я больше всего стрелял в ногу в нетипизироваными языками.
Можно допустить банальную опечатку и вместо
user.lastName = 'John'написатьuser.lstName = 'John'и в итоге у нас в объекта будет два поля, одно с опечаткой и второе без.Статический бы язык отловил это на этапе компиляции.
Вторая проблема с полями это их переименование. При необходимости переименовать функцию или поле, при использовпнии статики ide имеет достаточно информации, чтобы заменить по всему коду. В динамике же у меня был конкретный слкчай с pycharm, где переименование автоматическое заменило только в 2х местах, а использований было 5.
Благо с переименованием локальных переменных и в динамических языках ide справляется.
Но с полями приходится делать поиск по тексту во всех файлах проекта и вручную делать замену.
Допустим есть два класса:
Image и Person у которых есть поле name.
Поступила бизнес задача добавить человеку firstName и lastName.
Добавляем ласт нейм и просто нейм переименовываем в firstName.
Типизированые языки позволят автоматически это сделать.
В динамически типизированых же придется следить, чтобы случайно не переименовалось использование поля у Image.
А в статье написано, что ядро само себя переводит в зашищенный режим.
Перевод в 32-битный режим будет описан в следующей статье?
Жесть, я думал, что GRUB уже в рельном режиме гурзит ядро.