> Потому что у вас по всей видимости были нужные связи и возможности
> чтобы их достать.Я шарился по краунфандингам, нашел интересного, посчитал что мне надо, через энное время получил. Из "связей" - почта да банк.
> У меня например первые солнечные панели появились двадцать лет назад,
Искренне ненавижу это, оперирую исключительно general markets. Но даже в РФ бывали знатные DEAL. Никогда не видели STM32 за 0.8 бакса (доллар в районе двадцатки)? Или шикарные полевики от IR/Infineon за центы? А так можно было. Взял мелким оптом, надолго хватило. И даже ща бывают прикольные вещи. Вон чид продает RISCV МКшки за копейки, поприкольнее маусера и фарнела предложение так то, даже штучно цена норм.
> Причем выгодно для обеих сторон.
Я за сравнимые суммы ARMv7 уже тогда набрал себе. На этом armhf работает, хотя еще до малин появилось.
> одноплатниками и робототехникой именно благодаря появлению _доступных_ и неплохо
> документированных "малинок".
Броадком приперся на поляну которую создали и развили не они. И через агрессивный пиар слил отсталый лежак. Упаси меня от таких благодетелей.
> Так это _ваш_ код. А если используете не ваш - что,предлагается заниматься
> ловлей багов,возникших из-за переноса на другую разрядность?
Предпочитаю не использовать багованый кривой код в общем случае: я не помойка.
> достаточно объемным,а также и сложным для понимания по причине личных предпочтений тех
> кто его писал. Вон тот же ardupilot как пример.
Ну вот с ним сильно не экспериментировал. Но при наличии таких свойств кода я бы посчитал бы что у меня проблема. Вендорлоки должны умереть.
> Возможно это связано с какими-то психологическими особенностями. Например временем реакции
> (своей,а не компа имеется в виду). Или чем-то еще.
Это свзяно с тем что я люблю качественные девайсы, софт и первоклассный UX. Опенсорс не повод отказывать себе в хорошем, Linux так может. Просто поднабив опыта на ARM я посчитал что могу и получише дистромайнтайнеров сконфигурять, оказалось не так страшно, а заодно теперь все как нравится - мне.
И ключ подписи модулей лично мой, с форсом подписей. Это теперь МОИ системы. Мои системы служат - мне. Я решаю что льзя и кому. Так прикольнее.
> видимо потому что не игроман.
Ну я как бы иногда не прочь и в Xonotic кому-то хедшот с разворота навесить из nex (штука типа рэйлгана в кваке). Там больше скилл и тактика роялит. Но дерганая работа системы приведет к мазне.
> среды" типа KDE и пользуюсь простым IceWM.
Я пока XFCE пользуюсь, но вероятно на LXQT уйду, гномеры утомили метаниями и тормозами тулкита, особенно в терминалке бесит. А может и что более кастомное.
> Кривость или не кривость опять же зависит не от самого Device Tree,а
> от того, насколько правильно его написали под конкретное железо.
В случае официальной поддержки майнлайном DTS прям в майнлайне, он сильно кривой не может быть. ACPI до этого как пехом до пекина. И патчи там слать вендору не получится.
> Например в китайских планшетах это условие не всегда выполняется.
Тем не менее, я могу легко перекроить DVFS в DTS, так как надо в этой задаче, с этими возможностями TDP. Не могу сказать то же самое про ACPI.
> Вообще-то средства для пересборки таблиц ACPI есть нативные в Дебиане.
> На ноутбуках ими не раз пользовался, ремонтируя то что недописали производители.
А всяко DTS/DTB мне больше понравился. Намного менее проблемная технология имхо и с ядром хорошо интегрируется, а не на правах второго сорта как ACPI. Меня такая "поддержка" системы фирмварой за...ла, не хочу видеть ЭТО в моих системах. И ME/PSP они могут себе оставить.
> даже не столько на сам x86,сколько на архитектуру типичного ibm-совместимого компа где
> он стоит.
Я пришел в опенсорс чтобы отделаться от вендорлоков. Поэтому я кроссплатформенный. И умею решать свои проблемы. Я не позволю хламу диктовать мне выбор платформы, хоть как.
> Но пока что заменить особо и нечем. Причем я не о производительности
> говорю - она уже давно избыточна для большинства решаемых задач,а именно
> об архитектурных особенностях.
Мне не требуются архитектурные особенности x86. Особенно ME/PSP, проприетарные фирмвари и проч. Меня на x86 ничто не держит, а свои проблемы я как правило могу решить.
> новый комп с каким-нибудь новым процом,и это не будет отягощено грузом тридцатилетней
> совместимости.
Для себя я наметил цели и задачи и буду просто следовать по этому пути. Для меня это важный аспект и я не потерплю вендорлок.
> это была плата с процом TI OMAP. Не доехало.
Ну вот омапы я покупать не пробовал. Европейцы или китайцы прекрасно присылали. В т.ч. и амеровские btw.
> распространенное железо выгоднее - оно особо никого уже не заинтересует "по дороге".
Мои одноплатники никого не интересовали, ибо меня интересовали "доступные железки" а не "top notch" и я фандил проекты с ними. Они и стоили как малина примерно - но ARMv7, уже тогда.
> Я же сказал - МОЖЕТ БЫТЬ будут разбираться. Если повезет.
Я был в корпах фортуны 500 и видел как это работает. Так и полюбил опенсорс ;)
> К нам их лицензии вообще отношения не имеют
Я не вы.
> А оно становится. Потому что или бери то что есть и пытайся
> собрать - что проще всего сделать на примерно той же конфигруации
> на которой оно писалось, или пиши сам полностью с нуля. Что
> за разумное время может оказаться неподъемно в одно лицо.
Мир неиделаен. Поэтому я стараюсь маневрировать минимизируя свои траблы не в ущерб long term goals. Проблемный код без сожалений заменяется, если не получается, фиксится. Или находятся иные решения. Если есть желание - есть 1000 возможностей. Желание не видеть вокруг себя вендолоки и помойку в софте у меня есть.
> Тот,кто писал код - может быть например хорошим математиком. Но посредственным программистом.
За это я их не люблю. Пару раз я таки рефакторил вот что-то наподобие, да. В любом случае я не потерплю вендорлоки и мусорный код.
> человек мог разбираться во всём что к ней относится. Поневоле приходится
> использовать и чужой код тоже.
Я не спорю, однако предпочитаю решать проблемы качеств и вендорлока, агрессивно маневрируя если необходимо.
> написано. Иначе легко можно получить неправильное поведение софта в каких-нибудь граничных
> случаях (как раз с представлением чисел и связанных).
А можно и связанных - истребитель крутившийся кверху пузом из-за integer overflow таки намекает, если это не байка. Да и ариан5 помнится на безопасной аде - откушал этсамого.
> Мне далеко до вашей квалификации,поэтому без VMLAB в программировании AVR я как без рук.
Не очень понимаю что там можно симулировать. Чисто математические алго - я вообще на хосте отлаживаю. Хорошая причина делать код - портабельным. И таки да, uint32_t и в африке unit32_t. Он остается собой и на AVR, и на ARM и на x86-64. У него нет причин развалиться.
Поэтому при прочих равных код >= C99 получает в моих глазах ломовое преимущество. Это один из критериев выбора кода и принятия решений.
> Ту периферию что внутри контроллера AVR (таймеры,порты) - VMLAB симулирует хорошо.
Ну, блин, а зачем мне это без внешнего обвеса и его поведения? Скажем если взять ADC то ряд грабель и свойств можно только в реальной железке узнать. Не, симуль врядли покажет что частый перезаряд входа ADC садит источник сигнала в ряде случаев. Он также не покажет качество разводки моей печатки и как с ним жить.
Внешние чипы и проч - тоже если и будут то врядли сильно реалистично. А симуляция сугубо core и самой детерминированой периферии? Ну, круто, но у меня с ними проблем и так не было, я обычно понимаю что у меня система делает.
На самом деле тому способствует еще "быстрый trace flow". Типа дебажных printf но по возможности асинхронно и в 3Mbps FTDI, чтоб не якорило времянки. Так получилось даже очень странную эмпирику затестить где я сперва не знал как вообще - хорошо.
> Немало ошибок в использовании всего этого так отловил.
Я в целом практикую test driven подход: написав сегмент кода я делаю валидацию что он работает так как я себе представлял. А собрав это все я смотрю общий flow и ключевые параметры и проверяю что они - такие как я себе представлял. Если это не так, я делаю супердебаг билд показывающий от и до что там творится - и почему так.
Я так даже весьма забавные вещи ловил. Скажем забыл прескалер ADC перещелкнуть и он фигачил на скорости выше номинала. Не то чтобы это совсем не работает, но отсчеты - пляшут. Привычка не доверять себе и тестик визуализирующий что и как это поймали в два счета. Попробуйте так с симулятором.
> и ошибок в симуляции больше или просто странного поведения,о котором если
> не знаешь то оно становится неприятной неожиданностью.
Ну вот поэтому я предпочитаю сделать железку и посмотреть в интерьере как это работает, какие margins и ключевые параметры, etc.
> хороший _визуальный_ симулятор (как VMLAB) - любители более охотно использовали бы
> STM32 потому что оно содержит всё-таки достаточно полноценный arm-процессор,
С другой стороны, мне меньше конкурентов. Да и для полного использования фич надо все же понимать что делаешь. Особенно если параллельно DMA пускать и проч.
> на котором значительно меньше заморочек с математикой.
Лично я ненавижу константы и математику в авр-ах, это боль.
> глазами видеть что внутри STM32 происходит (по типу того же VMLAB)
> но нет хороших описаний как это сделать поэтому простой народ не знает.
Я просто разок забутявил STM32 сам, с ноля. С тех пор я его знаю как свой дом.
> У меня просто нет таких операций,даже разовых, которые способны сожрать четыре гига памяти.
А у меня могут и найтись, пожалуй, иной раз.
> ни один процесс не мог выжрать всю память и поставить систему колом
> настолько что даже в шелл не зайти чтобы корректно его прибить.
В моем случае система настроена так что в этом случае потупит секунд 5 и прибьется OOM killer'ом. И вся проблема. Шансов что процесс вот именно тонкую грань между тупняком и OOM нащупает мало, и даже так с zram вместо свопа система 100% юзабельна, просто работает в 2-3 раза медленнее из-за тасовки страниц.
> Возможно это наследие моей работы с низкоуровневым программированием в DOS,где любая
> ошибка означала мёртвый повис и перезагрузку через reset.
А я умею пользоваться фичами многозадачки. И кроме всего прочего обычно заранее есть пару шеллов где я могу пристрелить проблемный процесс.
> Соглашусь что работа с файлами гигантских размеров актуальна для тех кто
> профессионально занимается монтажем звука или видео. Но я этим не занимаюсь поэтому
Да не только. Например какая-нибудь аналитика - кучи каких-нить отсчетов или там чего еще. Да, io error при этом конечно не того но для разового счета оно мне - сами понимаете.
> у меня на компе просто неоткуда взяться файлам в четыре и больше гигов размером.
А у меня один только unpacked файл видео есть на 6 гигз. Юзается для "честного" теста кодеков на нежатом контенте например.
> Вообще-то Альт мог бы и поменьше инсталлятор сделать типа дебиановского netinstall.
> Потому что перекачать три гига сюда через интернет по радио было долго и не просто.
Я альтом не пользуюсь поэтому ничего на этот счет не скажу. А для скачки жирных файлов предпочитаю торент, потому что там integrity check поблочный, если чексум не сойдется, только рушеный блок перекачается.
> Возможно вы правы. Я сам не пробовал - просто потому что довольно
> давно уже своп просто не требуется,ни настоящий ни виртуальный.
Это такой очень условный своп - выгружает холодные страницы в RAM же, но в сжатом виде. Больше места под дисковый буфер и программы/виртуалки/etc. А если что декомпресс RAM -> RAM быстро.
> Вот только я заметил,что уже десятка полтора лет как скорость решения прикладных
> задач ограничивается быстродействием не процессора,а моих мозгов.
ИМХО сильно зависит от. Скажем пожать мувик тяжелым кодеком за разумное время требует мощный проц. А зачем жать? Камеры гаджетов очень рыхлый поток генерят, если фичой пользоваться терабайты сожраного места начинают задалбывать. Можно раз в 5 сжать и не заметить разницу на глаз, если кодек современный взять с норм настройками (AV1/H.265/etc).
> Копаться в мегабайтах кода и разбираться что там к чему - быстрее не получается.
Но ребилд допустим линукскернела - ресурсоемкая штука.
> Питон - слишком новая вещь, его даже сейчас еще не всегда в институтах изучают.
В западных уже полно. Ну и лезут хомяки с ЭТИМ. Давая языку заслуженную репутацию.
> Я кстати когда впервые столкнулся с Питоном - очень неприятно удивили значащие
> пробелы в исходние.
Там вообще весь яп - фигак, фигак, как-то работает. Типизации нет, синтаксис корежат, на обработку ошибок прогеры класть хотели, статического анализа нет - так что упадет оно прям в рантайме. Да с таким стектрейсом что кодер и после поллитры не поймет что там. Ну проекты на этом и живут - год два зачастую. Потом задор что-то иссякает. Тем более что еще вот синтаксис в очередной раз зачем-то сменили - так что переписывать опять.
> Не ставить барахло можно когда выбор есть что ставить.
> А он в узкоспецифичных задачах есть не всегда.
Возможно. Но это какие-то совсем уж узкоспециализированные видимо.
> же не о профессиональных программистах говорил,а о любителях. Ну вот как
> раньше были "радиолюбители" так теперь появилось немало и программистов-любителей.
Радиолюбители как и программисты тоже разные бывают. Некоторые двигают прогресс вперед, создают новые комм протоколы и алго, умеют железки на уровне проектировать. А некоторым вообще не понятно зачем столько бандвиза подарили без всякой пользы. Чтоб они пару раз в день по архаичному радио трындели, занимая на это весь диапазон? Очполезное использование бандвиза.
