Почему работать в консоли настолько приятно? Так задумано отцами-основателями Unix

Если не изменяет память, это и есть герой моего комментария. Увеличить нельзя, обработка нескольких файлов как-то через задницу. Не исключено, что не осилил. Или спутал.

Рейтинг лучших бесплатных программ для 3D-моделирования (для начинающих) на весну 2021 года

Смешались в кучу коги, люди… Так CAD'ы или 3d дизайн? Если это рейтинг, то порядок сортировки очень странный. В вопросе именно 3d дизайна (не CAD), у Blender среди других бесплатных конкурентов и близко нет.

Среди CAD выделил бы Fusion 360, который бесплатен для личного использования. По сравнению с FreeCAD просто божественен.

Почему работать в консоли настолько приятно? Так задумано отцами-основателями Unix

Использую консоль очень много и каждый день. Даже работу с файлами для около-программерских или около-системных задач я делаю через обычные cd/ls/cp/mv. И лично мне это даже быстрее, особенно, в с автокомплитом и историей (а в zsh можно писать cd prog/my<tab>и получить cd programming/myproject).

Гуевый проводник использую только для мультимедийных задач.

Почему работать в консоли настолько приятно? Так задумано отцами-основателями Unix

Программы с графическим интерфейсом разговаривают с нами практически на одном и том же языке понятий, действий, символов (привет, кнопка с дискетой!). Консольные программы — чуть ли не каждая имеет свой язык, причём основанный даже на разных принципах.

Я бы поспорил. Так же, как у GUI есть паттерны (кнопка дискеты, меню, чекбоксы, "кнопка гамбургер" итп), у консоли тоже есть свои паттерны:

• -h/--help, man xxx. Собственно, точка входа, если вы не знаете, как этим пользоваться. Есть почти везде
• длинные --long и короткие -s аргументы
• работа через stdin/stdout

Да, не везде это так (напр. не все принимают stdin), но и GUI не всегда красивый и понятный. Особенно, если его делал программист для себя/других программистов (а большинство консольных утилит — это вот такой опенсурс).

Ну и да, вы можете сказать, что этих общиъ паттернов мало, но и GUI программы не повторяют друг друга 1-в-1, а просто имеют общие паттерны, и в них все равно нужно разбираться, особенно, если функций там выше крыши.

Почему работать в консоли настолько приятно? Так задумано отцами-основателями Unix

Сложные пользовательские скрипты собирали и анализировали бы информацию с сотен сайтов и отображали бы ее в удобном для конкретного пользователя виде…

Но это же не замена консоли. Это вы уже какие-то бизнес-решения описываете, а не автоматизацию. Конечно, можно и на баше писать, но не думаю, что это распространенно и нормально. Предложенное вами вполне живет и нынче называется модно "no code"

Почему работать в консоли настолько приятно? Так задумано отцами-основателями Unix

Вы же сами сказали, для разных задач свои инструменты. Что-то быстрее сделать на баше.

Пример:
Вчера решил узнать, какие пакеты я себе ставил путем грепания лога pacman. Решил путем однострочника на баше с cat, grep и awk. На питоне было бы куда больше.

З.Ы.
Нет, я не решал проблему, которую сам себе создал, потому что линукс. На винде в списке установленных программ я бы так же увидел то, что я ставил сам, так и то, что поставили установщики. Штук 10-20 разных пакетов, установливаемые Visual Studio или Adobe тоже не очень удобно. Только, в отличие от pacman, там не понять, кто был поставлен явно, а кто — зависимость.

Почему работать в консоли настолько приятно? Так задумано отцами-основателями Unix

Тогда посоветуйте такой GUI к ffmpeg. Я не знаю, какая самая труЪ программа для конвертации видео, каждый раз страдаю: их выше крыши, они предоставляют различные ~ненужные~ функции, не предоставляют нужные, зачастую платные итп итд.

Недавно я искал конвертер, скачал какой-то из поисковой выдачи. Оказалось, уменьшить разрешение можно, а увеличить (растянув) нет. Выбрать всю папку можно, несколько файлов из папки нет.

Пришел к выводу, что быстрее было бы сдеалть с помощью ffmpeg (который, к к тому же, уже стоит или ставится за 15 секунд через apt/pacman/etc), чем перебирать GUI-шные проги и читать обзоры вида "Топ 10 бесплатных видеоконвертеров".

Печальная правда о пропуске копий в C++

И какие практические правила для эффективной передачи объектов?

• Возврат "тяжелого" объекта из функции.
  
  • Например, я хочу вернуть вектор, строку итп. Как лучше всего поступать? Насколько мне известно, основная рекомендация: возвращать по значению и положиться на RVO/NVRO. Может ли тут быть ситуация, когда это не сработает? Как можно подсказать компилятору?
• Перемещение (передача владения) в функцию
  
  • Привести к rvalue с помощью std::move?

А еще где-то неподалеку perfect forwarding...

Финские студенты планируют запустить деревянный спутник до конца этого года

Заголовок спойлера

Такие?

Или такие?

Во втором варианте вполне понятно, почему сила будет приложена к фиксированной точке на плече.

Финские студенты планируют запустить деревянный спутник до конца этого года

весы с гирями измеряют именно массу

Почему? Я бы сказал, что они измеряют момент mgl, где m — масса предмета, l — длинна плеча. Если длинна плеча чаша с предметом и с гирями отличается (напр., поместили их не ровно в центр), показания весов будет немного искажены.

Как не копировать код в Rust

А я же ссылку возвращаю. Или он из лайфтайма self выводит?

Как не копировать код в Rust

Вопрос 1

А как такая же проблема решается в Haskell, откуда подобная система во многом позаимствована? В некотором приближении, там существует те же "структуры" и тайпклассы (трейты).

Вопрос 2

А действительно нужно наследование структур? Вообще, наследование различных игровых сущностей — во многом хрестоматийный пример к "composition over inhertiance", а в геймдев архитектуре получил широкое распространение паттерн Entity Component System.

Почему бы не сделать с композицией, примерно так:

struct CharacterProps{
    phys_resist: f32,
    mag_resist: f32,
    hp: f32,
    dmg: f32
}

trait Character {
    fn props<'a>(&self) -> &'a CharacterProps;
    fn props<'a>(&mut self) ->&'a mut CharacterProps;
    fn make_hurt(&mut self, dmg: Damage) { /* ... */ }
}

struct Player {
    props: CharacterProps, 
    // other player-related fields
}
impl Character for Player {
    fn props<'a>(&self) -> &'a CharacterProps { &self.props }
    fn props<'a>(&mut self) ->&'a mut CharacterProps {&mut self.props }
}

struct EnemyWarrior {
    props: CharacterProps, 
    // other enemy-related fields
}
impl Character for EnemyWarrior {
    fn props<'a>(&self) -> &'a CharacterProps { &self.props }
    fn props<'a>(&mut self) ->&'a mut CharacterProps {&mut self.props }
}

Да, осталась копипаста для получения props, но ее куда меньше и без хаков.

Примечания:

• я мог ошибиться с лайфтаймами, да и с синтаксисом
• я не уверен, как лучше, имплементировать Character для Player и EnemyWarrior или вообще можно будет просто имплементировать расчет урона только для CharacterProps и тогда вообще не нужен этот геттер. Но использовать такую структуру будет менее удобно. Наверное.

Если же говорить об имплементации ECS, то там, скорее, будут не жестко заданные поля соответствующих типов, а вектор различных компонентов (положение, рендер, персонаж итп). Не уверен, как это имплементировать в Rust. Возможно, Vec<Box<dyn Component>>

Мозг, смысл и конец света

Чем тот же GPT-3 не китайская комната?

Мозг, смысл и конец света

Оффтоп: есть работы по аппроксимации физической симуляции нейронными сетями с целью увеличения производительности.

Совместная игра в Factorio — лучшее собеседование для программистов, что мы проводили

Начиная с какого-то уровня хардкорности технической игры, я задумываюсь: а может, стоит пойти занятся реальными технологиями? В общем, проще постаивть Quartus :)

Совместная игра в Factorio — лучшее собеседование для программистов, что мы проводили

Когда-то играл в Space Engineers и без поллитры интернетов (в частности, youtube-канала, упомянутого в вашем комментарии) я так и не понял, как там делать нормальный скриптинг дальше примитивной событийно-ориентированной системы. Автоматизированное управление предполагаает цикл обратной связи, который "из коробки" в Space Engineers не реализуется. Насколько я помню, там предлагается использовать таймер с нулевой задержкой, который триггерит компьютер, который триггерит таймер. На мой взгляд, это хак. А как там делается какое-то навдеение (т.е. получение координат какого-либо объекта) я не помню. Не удивлюсь, если опять хак.

Как наши побили рекорд Intel: за кулисами масштабного шоу дронов

Если не секрет, какой аккумулятор на дронах? Логично предположить, что для такой массовости, дрон должен быть как можно дешевле и проще в изготовлении. Вы говорите, что большую часть энергии, потребляют светодиоды, и при этом время полета составляет 15 минут.

Мой э… недо-фристайл квад с аккумулятором 1100 mAh способен летать минут 10, при этом его максимальная скорость не сильно выше, где-то 25-30 м/с (ну это уже прям "в пол").

Как мы верифицированный полетный контроллер для квадрокоптера написали. На Ada

Как я понял из статьи, SPARK позволяет больше инвариантов обеспечить. Например, в Rust нет возможности ограничения и compile-time проверки допустимых значений, compile-time проверки выхода за границы массива итп.

Как мы верифицированный полетный контроллер для квадрокоптера написали. На Ada

Внешний цикл это цикл опроса периферии (CMD task на рисунке) в ожидании команд с радиопередатчика. Если команды нет, он передает признаки «сохраняем высоту, держим горизонт». Если команда с пульта есть, передаем ее — целевой угол наклона, целевую мощность на пропеллеры. Частота внешнего цикла 20 Гц.
Внутренний цикл — цикл опроса гиро-акселерометра и распределения мощности на двигатели. Цикл оборудован 3 PID-регуляторами, и математикой Махони для расчета текущего положения по сигналам с гироскопов.

Я уверен, что, раз вы смотрели исходники xxxflight'ов, то вы это и без меня знаете, ну да ладно. Насколько мне известно, в xxxflight'ах стабилизация осуществляется по угловой скорости (acro/air режим), а режим удержания горизонта прикручен уже поверх. Возможно, ваше решение лучше для стабилизации в горизонт.

Так как у нас нет ни баровысотомера, и другого способа измерить высоту, то для грубого удержания высоты используем интеграцию вертикальной скорости.

Интересно. Я когда-то (лет 6 назад, когда еще был MultiWii) хотел что-то такое сделать, но так и не сделал. На бумаге гладко, но я предполагаю очень большие накопленные ошибки из-за шумов акселерометра и погрешностей определения ориентации. Можете сказать пару слов об этой фиче?

В 2020 году инвестиции в ИИ в России снизились на четверть

Иными словами, какой смысл торчать на локальных местечковых форумах и блогах, когда тебе доступны англоязычные ресурсы, на которых пишут и отвечают на вопросы специалисты со всего мира.

Какие есть англоязычные аналоги хабра со специалистами со всего мира? Medium только на ум приходит, но там не такие активные комментаторы (нар хабре иногда комментарии лучше поста). Да и мусорных статей там, кажется, больше.