KiCad 5.1.5

В Buster почти завезли свежий KiCad. Почти — потому что из-за глючного dwz(1) он не собирается в buster'овом окружении; видимо это и держит мейнтейнеров — все остальное уже спортировано. Но можно собрать самому, указав при сборке DEB_BUILD_OPTIONS=nostrip (не надо задумываться причём тут "strip", это особая дебхелперовая магия). Билд при этом несколько распухнет. Ну или в теории можно всосать свежий dwz/unstable (не пробовал). А! Еще понадобится glm/unstable, но там без проблем. Далее как обычно: apt-get source, dch --bpo, dch --local ~local, sbuild или dpkg-buildpackage (предпочитаю первый).

Получаем тонны багфиксов, новых фич вроде бы нет. Замечу что по-моему это вообще первый релиз из ветки 5.1, которым можно пользоваться не ловя ежеминутно ассерты.

This entry was originally posted at https://ex0-planet.dreamwidth.org/87962.html. Please comment there using OpenID.

The Devil and the Almighty Blues

Класс, пацаны ваще ребята.

Стилистически — Джим Моррисон с Пинк Флойдом поют нам блюз с того света :-)

Но чернуха, в плохом настроении лучше не слушать.



This entry was originally posted at https://ex0-planet.dreamwidth.org/87562.html. Please comment there using OpenID.

... ought to be enough, 30 лет спустя


The technology has some limitations — RISC is not appropriate for all computing applications, and the software for such machines is still being developed. But for a number of work-station makers, the quick speed fix promised by RISC has proved to be an irresistible attraction.


Отсюда

This entry was originally posted at https://ex0-planet.dreamwidth.org/87215.html. Please comment there using OpenID.

ретро-прозрение

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

И вот, читаю я про эти ваши "Эволюшены", "Нексты" и прочие "Веги" и как-то так внезапно понимаю, что самое важное в ретрокомпьютинге — уметь вовремя остановиться...

This entry was originally posted at https://ex0-planet.dreamwidth.org/86894.html. Please comment there using OpenID.

music for programming

Внезапне обнаружил что кодинг очень неплохо заходит под саундтрек из TA: Kingdoms



Там на канале еще есть.

Кстати, это тот же самый Джереми Соул, который делал музыку к Icewind Dale, Morrowind, Skyrim, Neverwinter Nights, Unreal 2 (как ни странно!) и еще куче других игр.

This entry was originally posted at https://ex0-planet.dreamwidth.org/86700.html. Please comment there using OpenID.

Ужосы городка

Ну что, кому-то не нравился немецкий Schneider и ABB? Дораха? Воротили нос от китайских IEK и TDM Electric — качество, видите ли, не то?

Вот вам тогда электроавтоматика от лучших производителей из ДНР (ага, именно оттуда)! Скоро на всех прилавках.

https://mysku.ru/blog/russia-stores/76283.html


PS. Как ЭТО попало на российские прилавки спрашивать, видимо, бессмысленно. Но наводит на кое-какие размышления.

This entry was originally posted at https://ex0-planet.dreamwidth.org/86318.html. Please comment there using OpenID.

@#$%!!!

2019, а питон все еще интегрируется с пакетными менеджерами примерно никак.

Ненавижу stdeb, ненавижу самого питона, ненавижу его яйца, ненавижу подход "сначала ввяжемся, потом будем разбираться как это работает". Ненавижу всех. А особенно, особенно неестественный интеллект, работающий по принципу "файл указан, но не нашёлся? Игнорируем, в ходе деплоймента поймаем проблему". "В воздухе точно не останемся", sooqa.

ps. Нет, pypi не предлагать. Это еще больший кал.

pps. И pypi2deb тоже ненавижу.

ppps. Отдельный луч поноса авторам, лепящим в корне какой-нибудь manage.sh или build.sh, без которого стандартным образом ничего не работает.

This entry was originally posted at https://ex0-planet.dreamwidth.org/86116.html. Please comment there using OpenID.

TDD: Trauma Driven Design

... Или Tool Driven Design, кому как больше нравится...

Как-то вдруг внезапно осознал, что всё что стоит за концепцией, например, "инкапсуляции" (как это понимается обычно в современном ООП) — всего лишь чья-то боль по поводу невозможности быстро найти и заменить все вхождения паттерна А на паттерн Б.

Ну, то есть, натурально, какой-нибудь восемьдесят восьмой год, сидит бородач в свитере перед монитором и кодовой базой в 100K-200K SLOC и понимает, что вместо "foo->bar = 640" надо бы писать какое-нибудь "updateGeometry(&foo, 640, 480)". И с инструментарием уровня турбо си восемьдесят восьмого года это — ЖОПА. Ну, каждый кто с подобным встречался поймёт. Все мы знаем, что прижилось решение просто запретить программерам писать "foo->bar = 640".

И вот сейчас в исторической перспективе становится понятно, что возникшую проблему можно было решить миллионом разных способов. Во всяком там энтерпрайзе куда более злобные изменения прокатывают под названием "рефакторинга", а возникающая при этом боль сглаживается контролем версий, разными там автотестами, итд итп. Чего в восемьдесят восьмом году просто не было, или было в рудиментарном виде. И если бы что-то из этого успело чуть пораньше, то никакой "парадигмы" ООП могло бы и не быть, а просто была бы рекомендация уровня best practices делать всё на ADT. А если не догадались сразу — ну чтож, бывает, линтер со статическим анализатором в помощь.

Интересно, сколько там, внизу, еще живет поспешных, неуклюжих, ad hoc решений заматеревших со временем в "концепции"?

This entry was originally posted at https://ex0-planet.dreamwidth.org/85982.html. Please comment there using OpenID.