![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Вибір Mikrotik колись був помилкою.
Jul. 1st, 2025 03:07 pmОдоробло дикої складності і непередбачуваності. Не хотілося це казати, але їм варто вчитися у китайців.
І да, якщо щось робите, робіть це через командний рядок.
Побачив ось
Jun. 23rd, 2025 01:56 pmтехніку, на якій вчився програмувати — Электроника МС-0511, у нас RT-11 там була, та ардуїна того часу — портфель з Микролаб КР580ИК80.
Мікролаб мені було цікавіше ковирять. Ще цікаво, 0511 була клоном PDP-11, на ній UNIX запускали?
ЗІ Ізвіняйте, за хабр.
Мікролаб мені було цікавіше ковирять. Ще цікаво, 0511 була клоном PDP-11, на ній UNIX запускали?
ЗІ Ізвіняйте, за хабр.
Війна та гріх
Jun. 19th, 2025 09:56 amТут отці спорять, чи ця війна нам за гріхи. Ось і мої п'ять копійок.Є три джерела зла: 1) власна вільна воля, що приводить до тяжких наслідків стосовно себе; 2) зла вільна воля інших людей і 3) вплив темних сил.
В нашому випадку варто розглянути власну вільну волю, яка діяла і діє на рівні суспільства ще з часів совєтів: це — тотальна корупція, аборти, тотальний блуд, несправедливість, відсутність милосердя, мояхатаскрайність. Це самий топ, який підточить будь-яке суспільство незалежно від релігійного сповідання. Ми самі запросили зло у нашу країну. А зло на те і зло, щоб двічі його не просити.
По-друге, є духовний світ, який діє за власними законами. У нашому випадку, ми є суспільством охрещених язичників або безбожників. Тобто, заповіт стосується і нас, але українське суспільство зухвало його порушує. Не нагадує ситуацію з євреями?
Ну і "хоч паржом" теж. Євреї Старого Заповіту теж хотіли дивного.
Тому ця ситуація, значною мірою, наслідок наших гріхів. Це можна порівняти з ослабленим шкідливими звичками організмом, який добиває хвороба, яка б до здорової людини не причепилася б або пройшла значно легше. Ця війна є насамперед проявом злої волі інших людей. Адже росія не полізла на здорову та сильну країну, наприклад Китай, вона полізла на ослаблену гріхами Україну.
ЗІ. Гріх на те і гріх, щоб з ним розібратись і не шкодити собі надалі, «… не хочу смерти грішника, але щоб грішник навернувся від путі свого і живий був.» (Єз. 33:11)
В нашому випадку варто розглянути власну вільну волю, яка діяла і діє на рівні суспільства ще з часів совєтів: це — тотальна корупція, аборти, тотальний блуд, несправедливість, відсутність милосердя, мояхатаскрайність. Це самий топ, який підточить будь-яке суспільство незалежно від релігійного сповідання. Ми самі запросили зло у нашу країну. А зло на те і зло, щоб двічі його не просити.
По-друге, є духовний світ, який діє за власними законами. У нашому випадку, ми є суспільством охрещених язичників або безбожників. Тобто, заповіт стосується і нас, але українське суспільство зухвало його порушує. Не нагадує ситуацію з євреями?
Ну і "хоч паржом" теж. Євреї Старого Заповіту теж хотіли дивного.
Тому ця ситуація, значною мірою, наслідок наших гріхів. Це можна порівняти з ослабленим шкідливими звичками організмом, який добиває хвороба, яка б до здорової людини не причепилася б або пройшла значно легше. Ця війна є насамперед проявом злої волі інших людей. Адже росія не полізла на здорову та сильну країну, наприклад Китай, вона полізла на ослаблену гріхами Україну.
ЗІ. Гріх на те і гріх, щоб з ним розібратись і не шкодити собі надалі, «… не хочу смерти грішника, але щоб грішник навернувся від путі свого і живий був.» (Єз. 33:11)
Де росте малина?
May. 26th, 2025 12:59 pmЯкось у мене виникла суперечка про нішу Raspberry Pi, точніше девайсів цього класу. Де надійність, сертифікованість та интерпрайз і де малини, ги-ги?
Малини скрізь: в космосі і в океані, в жарі та холоді. Працюють роками. Ще шахеди (або посилання на тєлєгу), інші шахеди).
Ніша — "для всякої ІоТ-ні, простеньких роботів, верстатів, кіосків і т.д., що йде відносно невеликими серіями", як і було сказано. Так що интерпрайз та military grade не цураються малинки. Отакої.
Малини скрізь: в космосі і в океані, в жарі та холоді. Працюють роками. Ще шахеди (або посилання на тєлєгу), інші шахеди).
Ніша — "для всякої ІоТ-ні, простеньких роботів, верстатів, кіосків і т.д., що йде відносно невеликими серіями", як і було сказано. Так що интерпрайз та military grade не цураються малинки. Отакої.
(no subject)
May. 23rd, 2025 03:16 pmНатрапив на дві статті, пов’язані з продуктивністю Raspberry Pi: одна — про бенчмарк SD-карт, інша — про використання NVMe SSD. Як на мене, сьогодні NVMe — це цікаве, але не практичне рішення для більшості задач.
Так, NVMe на порядок швидше й надійніше за SD-карту. Це звучить чудово, але має й зворотний бік. Ми цінуємо Raspberry Pi за вдале поєднання продуктивності, компактності, GPIO, ціни й — до появи Pi 5 — низького енергоспоживання та тепловиділення. Щоб ця комбінація працювала, потрібен компактний і дешевий накопичувач для завантаження системи та зберігання даних. І сьогодні цю роль найкраще виконують SD-карти або eMMC.
NVMe ж цю рівновагу порушує. По-перше, потрібен додатковий M.2 HAT — а це ще від чверті до третини вартості самої Raspberry. По-друге, NVMe гріється, причому поблизу основної плати. Отже, знадобиться більший корпус з активним охолодженням. Наприклад, ось кілька корпусів (раз, два) — зверніть увагу на їх габарити, систему охолодження й ціну.
Ще один важливий аспект — живлення. Сама-по-собі Raspberry Pi 5 при середньому навантаженні споживає трохи більше 1А, тому її можна живити від блока на 2А. І це важливо: для струмів до 2А легко знайти компактні перетворювачі (наприклад, HLK-5D1205), а от далі ціна й габарити живлення стрімко зростають, що ставить під сумнів доцільність використання Raspberry Pi 5 для вбудованих систем.
Але виробники RPi - молодці і от руки сверблять ганяти NVMe. Але якщо практичність і економічна доцільність важливіші за цікавість, що ми можемо зробити?
Як на мене, хороша SD-карта залишається оптимальним вибором: по-перше, найшвидші SD-карти мають швидкість, порівнянну зі старими жорсткими дисками. Особисто я задоволений SanDisk Extreme Pro — його достатньо для швидкого запуску системи й типових програм.
По-друге, якщо потрібно кілька гігабайтів для інтенсивного IO, можливо, краще виділити частину оперативної пам’яті під tmpfs. Ще один варіант — підключити NVMe через USB3-адаптер: у багатьох випадках це дає співставну з HAT’ом швидкість без зайвих витрат і ускладнень.
І, зрештою: якщо висока швидкість накопичувача є ключовою вимогою, варто подумати не про Raspberry Pi 5, а про потужнішу платформу — за потреби залишивши GPIO Raspberry Pi Pico чи іншому MCU.
А які ваші думки? Використовували NVMe на Raspberry, чи вам достатньо просто хорошого SD?
Так, NVMe на порядок швидше й надійніше за SD-карту. Це звучить чудово, але має й зворотний бік. Ми цінуємо Raspberry Pi за вдале поєднання продуктивності, компактності, GPIO, ціни й — до появи Pi 5 — низького енергоспоживання та тепловиділення. Щоб ця комбінація працювала, потрібен компактний і дешевий накопичувач для завантаження системи та зберігання даних. І сьогодні цю роль найкраще виконують SD-карти або eMMC.
NVMe ж цю рівновагу порушує. По-перше, потрібен додатковий M.2 HAT — а це ще від чверті до третини вартості самої Raspberry. По-друге, NVMe гріється, причому поблизу основної плати. Отже, знадобиться більший корпус з активним охолодженням. Наприклад, ось кілька корпусів (раз, два) — зверніть увагу на їх габарити, систему охолодження й ціну.
Ще один важливий аспект — живлення. Сама-по-собі Raspberry Pi 5 при середньому навантаженні споживає трохи більше 1А, тому її можна живити від блока на 2А. І це важливо: для струмів до 2А легко знайти компактні перетворювачі (наприклад, HLK-5D1205), а от далі ціна й габарити живлення стрімко зростають, що ставить під сумнів доцільність використання Raspberry Pi 5 для вбудованих систем.
Але виробники RPi - молодці і от руки сверблять ганяти NVMe. Але якщо практичність і економічна доцільність важливіші за цікавість, що ми можемо зробити?
Як на мене, хороша SD-карта залишається оптимальним вибором: по-перше, найшвидші SD-карти мають швидкість, порівнянну зі старими жорсткими дисками. Особисто я задоволений SanDisk Extreme Pro — його достатньо для швидкого запуску системи й типових програм.
По-друге, якщо потрібно кілька гігабайтів для інтенсивного IO, можливо, краще виділити частину оперативної пам’яті під tmpfs. Ще один варіант — підключити NVMe через USB3-адаптер: у багатьох випадках це дає співставну з HAT’ом швидкість без зайвих витрат і ускладнень.
І, зрештою: якщо висока швидкість накопичувача є ключовою вимогою, варто подумати не про Raspberry Pi 5, а про потужнішу платформу — за потреби залишивши GPIO Raspberry Pi Pico чи іншому MCU.
А які ваші думки? Використовували NVMe на Raspberry, чи вам достатньо просто хорошого SD?
Я часто використовую різні моделі Raspberry в роботі. Для багатьох задач чудовим вибором буде Raspberry Pi Zero2 — це мікрокомп’ютер розміром з половину кредитної картки. А ще я використовую Emacs. Це не просто текстовий редактор, а такий собі швейцарський ніж, який у поєднанні з практиками UNIX way надає просте та потужне середовище розробки. Тому я часто тримаю його на такого типу залізяках.
Втім, починаючи з Emacs 28, на RPi Zero2 почалися проблеми: Emacs починав страшенно гальмувати, вантажив CPU на 100% і, зрештою, наглухо підвішував пристрій. На старших моделях, а у мене RPi5, це теж відчутно, але не настільки.
Винуватцем виявився процес
Справа в тому, що ядро Emacs написане на C, а основна функціональність — на мові розширень Emacs Lisp. Так от, починаючи з версії 28, Emacs навчився компілювати lisp-код у нативний код. Щоб не витрачати час на компіляцію всього підряд, Emacs разово компіляє тільки те, що потрібно в даний момент, якщо не знаходить скомпільованих модулів. І цей процес якраз виконує цю компіляцію. У цей час у системі запущено два процеси: основний — emacs, у якому правиться код, і запущений ним процес компіляції.
Є два шляхи вирішення цієї проблеми:
1) Заборонити компіляцію в нативний код. Це робиться перед завантаженням основної конфігурації — у файлі ~/.emacs.d/early-init.el. Просто пропишіть у цьому файлі рядок:
і перезапустіть Emacs. Недолік цього методу в тому, що Emacs однаково компілює в байт-код — щоразу в процесі інтерпретації lisp-коду. І хоча процес компіляції в байт-код швидкий, продуктивність Emacs-а буде повільнішою, ніж у випадку з компіляцією в машинний код, що буде помітно на такій крихітці, як RPi Zero2. Тому я вирішив перейти до наступного пункту:
2) Дозволити Emacs-у скомпілювати все, що йому потрібно.
Я не знайшов нормального способу зробити це однією командою. Так, існує варіант з native-compile-async:
Його можна запустити для всіх каталогів у load-path. Але це рішення мені не подобається. По-перше, воно не завжди підхоплює все потрібне, а по-друге, і це найгірше — воно компілює мої власні правки, які я часто змінюю, і я не хочу, щоб виникли розбіжності між цими правками і скомпільованим кодом. Тому я вирішив дозволити Emacs-у зробити свою справу.
Але при компіляції org-mode, який часто потрібен, Zero2 намертво зависала. Це відбувається тому, що Zero2 оснащено лише 512 MB пам’яті і, за замовчанням, лише 200 MB свопа. Як тільки компіляція вижирає всю пам’ять — Zero2 висне. Тому збільшіть розмір свопа до 1024 MB (512 буде замало) і поступово запускайте режими, які часто використовуєте, паралельно відслідковуючи завантаження процесора.
Так, я спочатку відкрив код на C — Emacs почав компілювати все, що пов’язано з цим режимом, а я дочекався, поки процеси компіляції завершаться. Потім відкрив org-файл — дочекався завершення. Потім — magit, зайшов у менеджер пакетів, почекав, поки там усе скомпілюється, далі — js-mode, python і т. ін.
Ви можете знайти скомпільоване в ~/.emacs.d/eln-cache/emacs-version/. У мене скомпільованих файлів із розширенням .eln більше 300. Якщо ви оновите якийсь пакет — Emacs перекомпіляє сам пакет і нескомпільовані залежності. Якщо оновити сам Emacs — він перекомпіляє все під нову версію.
Чи варто морочитись з компіляцією? Як на мене — так. Скомпільована в нативний код версія працює відчутно швидше та плавніше. Підгальмовування залишаються, переважно при роботі з SD-картою.
Втім, починаючи з Emacs 28, на RPi Zero2 почалися проблеми: Emacs починав страшенно гальмувати, вантажив CPU на 100% і, зрештою, наглухо підвішував пристрій. На старших моделях, а у мене RPi5, це теж відчутно, але не настільки.
Винуватцем виявився процес
emacs -no-comp-spawn -Q --batch --eval '(setq w32-disable-abort-dialog t)' -l /tmp/emacs-async-comp-org.el
Справа в тому, що ядро Emacs написане на C, а основна функціональність — на мові розширень Emacs Lisp. Так от, починаючи з версії 28, Emacs навчився компілювати lisp-код у нативний код. Щоб не витрачати час на компіляцію всього підряд, Emacs разово компіляє тільки те, що потрібно в даний момент, якщо не знаходить скомпільованих модулів. І цей процес якраз виконує цю компіляцію. У цей час у системі запущено два процеси: основний — emacs, у якому правиться код, і запущений ним процес компіляції.
Є два шляхи вирішення цієї проблеми:
1) Заборонити компіляцію в нативний код. Це робиться перед завантаженням основної конфігурації — у файлі ~/.emacs.d/early-init.el. Просто пропишіть у цьому файлі рядок:
(setq native-comp-deferred-compilation nil) ;; Вимикає автоматичну компіляцію в нативний код
і перезапустіть Emacs. Недолік цього методу в тому, що Emacs однаково компілює в байт-код — щоразу в процесі інтерпретації lisp-коду. І хоча процес компіляції в байт-код швидкий, продуктивність Emacs-а буде повільнішою, ніж у випадку з компіляцією в машинний код, що буде помітно на такій крихітці, як RPi Zero2. Тому я вирішив перейти до наступного пункту:
2) Дозволити Emacs-у скомпілювати все, що йому потрібно.
Я не знайшов нормального способу зробити це однією командою. Так, існує варіант з native-compile-async:
(mapc (lambda (dir) (when (file-directory-p dir) (native-compile-async dir 'recursively))) load-path)
Його можна запустити для всіх каталогів у load-path. Але це рішення мені не подобається. По-перше, воно не завжди підхоплює все потрібне, а по-друге, і це найгірше — воно компілює мої власні правки, які я часто змінюю, і я не хочу, щоб виникли розбіжності між цими правками і скомпільованим кодом. Тому я вирішив дозволити Emacs-у зробити свою справу.
Але при компіляції org-mode, який часто потрібен, Zero2 намертво зависала. Це відбувається тому, що Zero2 оснащено лише 512 MB пам’яті і, за замовчанням, лише 200 MB свопа. Як тільки компіляція вижирає всю пам’ять — Zero2 висне. Тому збільшіть розмір свопа до 1024 MB (512 буде замало) і поступово запускайте режими, які часто використовуєте, паралельно відслідковуючи завантаження процесора.
Так, я спочатку відкрив код на C — Emacs почав компілювати все, що пов’язано з цим режимом, а я дочекався, поки процеси компіляції завершаться. Потім відкрив org-файл — дочекався завершення. Потім — magit, зайшов у менеджер пакетів, почекав, поки там усе скомпілюється, далі — js-mode, python і т. ін.
Ви можете знайти скомпільоване в ~/.emacs.d/eln-cache/emacs-version/. У мене скомпільованих файлів із розширенням .eln більше 300. Якщо ви оновите якийсь пакет — Emacs перекомпіляє сам пакет і нескомпільовані залежності. Якщо оновити сам Emacs — він перекомпіляє все під нову версію.
Чи варто морочитись з компіляцією? Як на мене — так. Скомпільована в нативний код версія працює відчутно швидше та плавніше. Підгальмовування залишаються, переважно при роботі з SD-картою.
(no subject)
Apr. 28th, 2025 09:18 pmРабин Моше Реувен Азман написав для Трампа справжній бойовий гімн у стилі старої рок-школи. Нажаль, на місці Трампа немає Рональда Рейгана чи Джона МакКейна.
Двадцяточку я поки зажав
Apr. 10th, 2025 08:06 pmЯ думаю, що це станеться через 3-6 місяців, — де штучний інтелект писатиме 90% коду. А через 12 місяців ми можемо жити у світі, де штучний інтелект писатиме майже весь код.
Коменти там прекрасні, якщо що. Наприклад:
Я до такого не довожу, бо спостереження приблизно такі ж.
Коменти там прекрасні, якщо що. Наприклад:
О! сейм щіт! сидів весь вечір і намагався таки якось доробити рефакторінг на 3.7 і в кінці тупо всяв усе і відкатив гітом.
От люди і готуються, на Форті Os пишуть. А може це і жарт. Але коли я сидів без світла, то теж про щось таке думав.
(no subject)
Apr. 4th, 2025 01:45 pmЯ дуже люблю цього американського художника, у його добрих картинах саме життя, радісне, сумне, барвисте, як ця "Юна леді з синяком".
Але у цієї картини є і продовження, коли юна леді стала місіс. Картина називається "Шлюбний консультант"
( Read more... )
Але у цієї картини є і продовження, коли юна леді стала місіс. Картина називається "Шлюбний консультант"
( Read more... )
Наткнувся ось на, якщо це правда, код перво-С, що написаний покійним вже Денісом Рітчі. І на що я там звернув увагу, так це на старий стиль визначення функцій, наприклад:
init(s, t) char s[]; { /*Some code here*/ }
і він мені видався більш вдалим за пізніший стиль:
int void init(char s[], int t){/*Some code here*/}
У старого стиля є два великих плюси:
- він займе менше місця для імен параметрів. Особливо коли читаєш clearAndLongParameterNames.
- все-таки ми орієнтуємось спочатку на імені, яке має відображати суть, а тип є технічною деталлю. І ідея розділення імені і типу мені сподобалася
У зв'язку з цим виникає питання до тих, хто стикався з цим: чому старий стиль відійшов? Бо поки я бачу, тільки те, щоб дізнатися тип параметра, потрібно перемістити погляд нижче, що може ускладнити швидке розуміння сигнатури функції.
Натомість у старому стилі був акцент на семантиці: спочатку видно імена параметрів, які повинні передавати суть того, що передається у функцію. Це дозволяє швидше зрозуміти призначення кожного аргументу, не відволікаючись на деталі типу.
А ще це зменшення візуального шуму: при наявності багатьох параметрів, вказівників або параметрів зі складними типами, оголошення типів в окремому блоці може візуально відокремити семантичну інформацію (імена) від технічної (типи), що потенційно полегшує сприйняття.
Власне, попрацював з Grok, Geminy та ChatGpt для генерації даних та коду. Найкраще показали себе Grok і, трохи гірше, ChatGpt. Geminy поки не дотягує. Поміч від них є, але потрібно ретельно переглядати результати, бо помиляється і серйозно, часто забуває контекст і може вставити артефакти чужого коду або нагенерувати ще тих данних. І, чим більше коду, тим гірше воно тримає контекст.
Користь від ШІ є, але я навіть не знаю, що простіше, чи пояснити йому задачу і перевірити за ним, чи зробити самому. Оттакої.
Користь від ШІ є, але я навіть не знаю, що простіше, чи пояснити йому задачу і перевірити за ним, чи зробити самому. Оттакої.
(no subject)
Feb. 28th, 2025 10:18 pmТрамп - нарцис, мародер і кидала. Один типаж з путіним та китайцем. Хто зна, як він себе повів би після підписання. І антиукраїнську політику вони декларували задовго до цієї зустрічі.
Якби підписав, обов'язки, яких так просто не позбавитись навіть при зміні трампа, були б на нас, а помочі, у кращому разі, нуль. А у тому, що трамп кине, не встигнуть ще чорнила висохти, я не сумніваюсь.
Якби підписав, обов'язки, яких так просто не позбавитись навіть при зміні трампа, були б на нас, а помочі, у кращому разі, нуль. А у тому, що трамп кине, не встигнуть ще чорнила висохти, я не сумніваюсь.
Поки що я активно експерементую з geminy та grok. Grok помітно краще розуміє і кодить, а geminy краще пояснює, кодить можна не витрачати часу. Втім, за grok-ом теж потрібен ретельний нагляд і постійні уточнення задачі. І помилки ШІ теж ловлю постійно. Власне, часто швидше самому написати, ніж пояснювати.
Втім, grok знайшов у мене досадну потенційну помилку — ділення на нуль. В моєму коді до цього не повинно було дійти, але задача може змінитись, попередній код переробитись, за ділення на нуль забудеться і тоді програма закрешиться.
Наразі ШІ, що я використовую не відміняє розуміння мови і задачі людиною.
Втім, grok знайшов у мене досадну потенційну помилку — ділення на нуль. В моєму коді до цього не повинно було дійти, але задача може змінитись, попередній код переробитись, за ділення на нуль забудеться і тоді програма закрешиться.
Наразі ШІ, що я використовую не відміняє розуміння мови і задачі людиною.
За останні 6 місяців прогресу не сталося ніякого (нажаль). Sonnet 3.5 все ще найкраща модель.
Я сьогодні весь день переписував весь згенерований код, поки не збагнув що якимось чином модель в Aider перемкнулася на Sonnet 3.7. Під вечір повернув 3.5.