JIT даже во времена framework 2.0 не особо любили, поэтому сразу проходились ngen`ом. В виндах даже служба есть, оптимизация Net.
С тех пор появился компилятор Roslyn. Парой галочек в окне деплоя собирается нативный линуксовый бинарник под одну из поддерживаемых платформ.
А вообще на хабре были темы с экспериментами сбора под uefi, dos и Windows 3. Но это уже библиотеку надо отключать. Я сам под биос собирал что-то.
Вы просто сильно все путаете. Например рантайм с виртуальной машиной, которой net отродясь не являлся (исключая net Micro framework для микроконтроллеров)
Так ведь вы сами, вместе с командой и оцениваете задачи. Не менеджеры. И вы же принимаете участие в обсуждениях какие задачи брать в следующий спринт, а какие пока просто положить, оставить в product backlog
Идея спринтов чётко завязана на процессы CI/CD, на постоянную и регулярную доставку ценностей заказчику в краткие сроки для получения обратной связи и как следствие быстрой реакции если что-то идёт не так.
Релизов, мейлстоунов этот подход не отменяет.
Гибкости при принятии задач в работу тоже.
И кстати, в противовес мнению автора статьи, рефакторинг тоже не отменяет. А наоборот утверждает что 15-20% спринта, вынь да полож на техдолг.
Не панацея, не важно agile вообще или scrum в частности имеется ввиду. Гибкие методологии стоит применять только для решения определённых типов задач, а именно для таких, решения которых ещё не наработаны, отсутствуют Best practise, но в то же время это уже не хаос.
Если scrum применяется неверно или agile применяется там, где он не нужен, или даже вреден, это не проблемы методологии, принципов, фреймворков итд. Это проблемы именно применения, неправильного позиционирования себя, своих решений, своих задач.
Вы же отталкиваетесь от команд, организаций, а не от задач. И видите противоречия там где их нет.
Вот начиная с "прожарки", все видимые вами противоречия на самом деле не в самом agile, а в том что вы сами игнорируете границы его применимости.
В скрам-гайде есть про принцип сюхари. Автор находясь на этапе СЮ, ещё сам не разобравшись, не научившись правильно понимать scrum, позиционирует себя в РИ
Подходит agile\scrum команде или нет, определяется не командой, а теми задачами, которая эта команда решает. Не важно сверху внедряется scrum или нет, но если он в принципе должен работать для решаемых задач, но не работает, значит проблема, видимо, не в самом scrum, а в том, что команда как то не так его использует или под видом scrum практикует нечто другое. Так что если сверху для решения этой проблемы спускают не просто директивы, а скрам-мастеров и обязательные тренинги, это не противоречит agile.
Отсюда же растут ноги у другого вашего противоречия. Скрам-мастер это не человек, это роль. То что на первых этапах внедрения scrum это отдельный, часто сторонний человек, ничего не меняет и ничему не противоречит.
Waterflow это не ругательство, а подход к разработке для задач, решения которых хорошо известны.
К неожиданному финалу статьи про специальные крепления, я просто обязан оставить тут эту ссылку на видос, где геймер сделал из комнаты кокпит космического корабля
И было бы неплохо в какой-нибудь из статей описание нескольких тс технологических пресетов, на что из сотни параметров дисплея обращать внимание и их диапазоны, подбирая его по параметрам для конкретного применения как то: игры, фильмы, работа с текстом, работа с цветами.
Первый раз слышу о разочаровании и сам не припоминаю что бы так со мной было. Чаще всего наоборот, когда что то придумываешь, пишешь весь такой на подъёме, а утром думаешь, а нафига?
Или проекты начинают надоедать когда главные задачи решил, идея уже работает на практике, челленж можно сказать окончен, остаётся полировка, доводка. Но чтоб разочарование от того что что то не получается - никогда!
Видимо программисты МК не относятся к ленивым программистам. Вот почему бы один раз не сесть и не написать фреймворк на шарпе для описания, кодогенерации и сборки фирмвари из общих, протестированных компонент.
Организация в ядре одна и таже что у ipt, что у nft и, внезапно, у tcpdump. Это BPF. По крайней мере в актуальных линуксах. Все эти фильтры развивались командой netfilter и, со временем, сверху остались только бэкэнды к общей подсистеме ядра, для сохранения совместимости и User experience. Причём прошу не путать новый bpfilter с собственно подсистемой BPF. Это тоже бэкэнд. Вы его можете ставить или не ставить, а подсистема есть всегда.
Что касается вашего примера, то пакеты помечаются в принципе одинаково что в nft, что в ipt, видимо какая то минорная ошибка у вас была.
У меня наоборот возникли проблемы с nft, пока я не полез в код и не сравнил приоритеты хуков с их вики. Отписал, в вики поправили.
nftables это тоже netfilter, непонятно почему вы им отказываете в родстве. И все это под капотом работает через bpf, который можно конфигурировать напрямую. И да, есть списки и это не map.
PS У меня схожим образом давно работает домашний роутер, только список маленький и статический и рефрешится по крону.
Проблема не в рассчете координат по расстояниям, это прекрасно делает и та дремучая математика. Проблема в том что падение RSSI редко отражает реальное расстояние и сильно прыгает даже в статических условиях.
Как по вашему сейчас можно контролировать состояние сложной конструкции в виде моста? Так же развешиваются датчики, которые сигналят, если уходят от расчёта на несколько мм. Ну вот это из той же оперы.
5" дискеты DD на 720кб очень надёжные. Я совсем недавно, в пределах пары годков проверял несколько десятков из более чем сотни дискет, все без бэдов.
JIT даже во времена framework 2.0 не особо любили, поэтому сразу проходились ngen`ом. В виндах даже служба есть, оптимизация Net.
С тех пор появился компилятор Roslyn. Парой галочек в окне деплоя собирается нативный линуксовый бинарник под одну из поддерживаемых платформ.
А вообще на хабре были темы с экспериментами сбора под uefi, dos и Windows 3. Но это уже библиотеку надо отключать. Я сам под биос собирал что-то.
Вы просто сильно все путаете. Например рантайм с виртуальной машиной, которой net отродясь не являлся (исключая net Micro framework для микроконтроллеров)
.net в байткод? Ну сколько можно то в эти мифы верить.
Так ведь вы сами, вместе с командой и оцениваете задачи. Не менеджеры. И вы же принимаете участие в обсуждениях какие задачи брать в следующий спринт, а какие пока просто положить, оставить в product backlog
Идея спринтов чётко завязана на процессы CI/CD, на постоянную и регулярную доставку ценностей заказчику в краткие сроки для получения обратной связи и как следствие быстрой реакции если что-то идёт не так.
Релизов, мейлстоунов этот подход не отменяет.
Гибкости при принятии задач в работу тоже.
И кстати, в противовес мнению автора статьи, рефакторинг тоже не отменяет. А наоборот утверждает что 15-20% спринта, вынь да полож на техдолг.
Не панацея, не важно agile вообще или scrum в частности имеется ввиду. Гибкие методологии стоит применять только для решения определённых типов задач, а именно для таких, решения которых ещё не наработаны, отсутствуют Best practise, но в то же время это уже не хаос.
Если scrum применяется неверно или agile применяется там, где он не нужен, или даже вреден, это не проблемы методологии, принципов, фреймворков итд. Это проблемы именно применения, неправильного позиционирования себя, своих решений, своих задач.
Вы же отталкиваетесь от команд, организаций, а не от задач. И видите противоречия там где их нет.
Вот начиная с "прожарки", все видимые вами противоречия на самом деле не в самом agile, а в том что вы сами игнорируете границы его применимости.
PS я простой разработчик
Имхо вредная статья
В скрам-гайде есть про принцип сюхари. Автор находясь на этапе СЮ, ещё сам не разобравшись, не научившись правильно понимать scrum, позиционирует себя в РИ
Подходит agile\scrum команде или нет, определяется не командой, а теми задачами, которая эта команда решает. Не важно сверху внедряется scrum или нет, но если он в принципе должен работать для решаемых задач, но не работает, значит проблема, видимо, не в самом scrum, а в том, что команда как то не так его использует или под видом scrum практикует нечто другое. Так что если сверху для решения этой проблемы спускают не просто директивы, а скрам-мастеров и обязательные тренинги, это не противоречит agile.
Отсюда же растут ноги у другого вашего противоречия. Скрам-мастер это не человек, это роль. То что на первых этапах внедрения scrum это отдельный, часто сторонний человек, ничего не меняет и ничему не противоречит.
Waterflow это не ругательство, а подход к разработке для задач, решения которых хорошо известны.
Да я так целый день могу дрыгать. Главное что бы стул не скрипел :(
А вот кстати у вас же стоечные корпуса? 2U? Водянку для них нашли? Ну или как охлаждать собираетесь?
Прежде всего спасибо за столь обстоятельный труд.
К неожиданному финалу статьи про специальные крепления, я просто обязан оставить тут эту ссылку на видос, где геймер сделал из комнаты кокпит космического корабля
https://youtu.be/EfetLhpOvJw
И было бы неплохо в какой-нибудь из статей описание нескольких тс технологических пресетов, на что из сотни параметров дисплея обращать внимание и их диапазоны, подбирая его по параметрам для конкретного применения как то: игры, фильмы, работа с текстом, работа с цветами.
Первый раз слышу о разочаровании и сам не припоминаю что бы так со мной было. Чаще всего наоборот, когда что то придумываешь, пишешь весь такой на подъёме, а утром думаешь, а нафига?
Или проекты начинают надоедать когда главные задачи решил, идея уже работает на практике, челленж можно сказать окончен, остаётся полировка, доводка. Но чтоб разочарование от того что что то не получается - никогда!
Так ведь нужна ещё связь с внешним миром, желательно не проводная.
Пусть Мокси обратит свое внимание на блокчейн chia. Там фермер со 100 тэрами что-то вроде бомжа, а вся сеть 25ЭБ (экзобайт)
Ну если государство не желает системно подойти к этому вопросу, то видимо только так.
Видимо программисты МК не относятся к ленивым программистам. Вот почему бы один раз не сесть и не написать фреймворк на шарпе для описания, кодогенерации и сборки фирмвари из общих, протестированных компонент.
Организация в ядре одна и таже что у ipt, что у nft и, внезапно, у tcpdump. Это BPF. По крайней мере в актуальных линуксах. Все эти фильтры развивались командой netfilter и, со временем, сверху остались только бэкэнды к общей подсистеме ядра, для сохранения совместимости и User experience. Причём прошу не путать новый bpfilter с собственно подсистемой BPF. Это тоже бэкэнд. Вы его можете ставить или не ставить, а подсистема есть всегда.
Что касается вашего примера, то пакеты помечаются в принципе одинаково что в nft, что в ipt, видимо какая то минорная ошибка у вас была.
У меня наоборот возникли проблемы с nft, пока я не полез в код и не сравнил приоритеты хуков с их вики. Отписал, в вики поправили.
В nft есть трейсинг, удобно отлаживать правила.
nftables это тоже netfilter, непонятно почему вы им отказываете в родстве. И все это под капотом работает через bpf, который можно конфигурировать напрямую. И да, есть списки и это не map.
PS У меня схожим образом давно работает домашний роутер, только список маленький и статический и рефрешится по крону.
Проблема не в рассчете координат по расстояниям, это прекрасно делает и та дремучая математика. Проблема в том что падение RSSI редко отражает реальное расстояние и сильно прыгает даже в статических условиях.
Не понимаю ваш ржач, клоуны.
Как по вашему сейчас можно контролировать состояние сложной конструкции в виде моста? Так же развешиваются датчики, которые сигналят, если уходят от расчёта на несколько мм. Ну вот это из той же оперы.