С подачи знакомого заинтересовался вопросом коррозии алюминия при использовании литола. Предположил, что алюминий корродирует из-за реакции со щёлочью, использованной при производстве мыла (гидроксид лития скорее всего) при вымывании этой щёлочи из смазки водой и попадания этого раствора на незащищённый алюминий, либо от гидролиза самого мыла. Взял где-то миллилитр "Litol-24" от Dinara Oil, залил около 10мл тёплой воды из под крана, несколько минут поразмешивал шпателем, сунул туда понтовую pH-индикаторную полоску Macherey-Nagel pH-Fix 4.5-10.0 - показала pH 7.5. Решил что вероятно экстракция вышла так себе, ещё немного размешал литол в воде, поставил лохань на грелкостол 3D-принтера, выставил удержание температуры 100° на час, закрыл короб и дождался прогрева и охлаждения стола до <50°. После этих манипуляций сунутая в раствор полоска показала pH 8.5. Учитывая что в реальной эксплуатации смазки в велосипедах вода может настаиваться на литоле месяцами, решил что результат достаточно однозначно иллюстрирует вероятный механизм возникающей коррозии. Ещё нашёл другого чувака, который не поленился и проделал продолжительный эксперимент с алюминием с аналогичными выводами: http://egain.ru/Aktivnyiy_otdyh/Turizm/Veloturizm/Vasha_tehnika/Litol_i_alyuminiiy___okolo_nauchnyiy_eksperiment.html Мораль: не заливайте воду в алюминий с литолом, или ебашьте ЕЩЁ БОЛЬШЕ литола чтобы у побывавшей в контакте с литолом воды не было никаких шансов добраться до алюминия, или используйте смазки без мыльного загустителя по возможности (даже тот же косметический вазелин в определённых температурных условиях работает неплохо; расскажите мне про смазку с более широким диапазоном рабочих температур без мыла).

nice, Lenovo is releasing an ARM Thinkpad, T14s Gen 6, with a Snapdragon CPU

— Замечаем, что свободная память куда-то внезапно съёбывается. killall -STOP firefox-bin — Уходим с воркспейса с браузером. Память возвращается. Firefox всё ещё в T state. — Возвращаемся в предыдущий воркспейс. Память опять куда-то девается. — Дампим smaps_rollup всех процессов, сравниваем. Разница копеечная. Неважно, Rss, Pss, firefox-bin, Xorg, i3 — да вообще всех метрик и по всем процессам. — Дампим meminfo. Разница только в гигабайтищах, на которые похудели MemFree и MemAvailable. slabinfo и df -h /dev/shm на таком фоне даже нет смысла сравнивать (но всё равно сравниваем и не видим ничего интересного). Что, бля, происходит нахуй?!

git push на github.com перестал работать. Connection timeout. Пришлось использовать костыли ввиде ssh.github.com:443. Походу теле2 тестирует новый dpi :-/

Gorgasm ожили и внезапно годно! https://music.youtube.com/watch?v=Wj9_vBJv064

> Непопулярное мнение: JavaScript единственный язык, который сделал правильные числа. 64 бита, которые одновременно и целое до 53-х бит, и с плавающей точкой если больше. Ну просто подумайте: в какой жизненной ситуации вам нужны целые больше 53-х бит? Это 9*10^15, девять ебучих квадриллионов, девять тыщ триллионов то есть. Чтобы представлять что? Вокруг нас просто нет предметов в таком количестве (кроме размера node_modules). Девять тыщ терабайт, если в байтах. То есть 53 бита достаточно каждому. Даже в указателях только 48 используется (хаха, а вы что, думали 64? Щас). Ну а иметь один числовой тип вместо двух как будто тоже гениально? Все в выигрыше, никто не пострадал. Почему же тогда подход JS не нравится «настоящим программистам»? Да потому что все остальные наловчились в 64 бита рассовывать разное, нужно им это или не нужно. То есть по сути единственная причина, почему это неудобно, это другие языки, которые пришли раньше и у которых конвенция другая. Они может все 64 бита и не используют, но _потенциально_ могут, и в итоге приходится под них подстраиваться. А нужно наоборот, чтобы все подстраивались под JavaScript (который на самом деле IEEE 754 double-precision float, если вам так больше нравится). Но как же битовые операции, скажете вы? Как мне всякие там сдвиги считать? Ну чувак, битовые операции на числах это страшный хак, раз уж мы о типах заговорили. Они должны на байтах делаться, а не на числах. А всякие int64/uint64 это от лукавого. Должен быть только number64.

Интересный факт: в тестировалке webrtc в firefox кино с камеры показывают без задержек, а mpv av://v4l2:/dev/video0 - с задержкой где-то миллисекунд 400. Чтобы mpv не тормозил, надо ему сказать --cache-secs=0 --demuxer-readahead-secs=0 --untimed

> Умер создатель языка программирования Паскаль Никлаус Эмиль Вирт, ему было 89 лет Лауреат премии Тьюринга и пионер компьютерных наук скончался 1 января 2024 года.

> Мне не надо ничего дописывать, мне надо чтобы когда я переношу функцию из файла «a» в файл «b», во всем местах программы где эта функция используется, «from a import function» изменилось на «from b import function». Я же вроде не многого прошу? Про подобные элементарные вещи в 2024м году стыдно говорить вообще, но почему-то хваленый имакс этого не умеет. > > Я не пишу на питоне, поэтому не скажу. В C/C++ проектах eglot автоматически #include’ы дописывает. > Вот так и рождается миф о могучем GNU Emacs. Сколько есть роликов на ютубе рекламирующих силу и мощь имакса, это всегда какой-то флуд про орг-мод (да нахер он мне не нужон ваш орг-мод), какие-то рассказы про «перешёл на имакс и не жалею», какие-то хелло-ворды в качестве примера, а когда дело доходит до конкретики - ну… я сам этим не пользуюсь, ну… попробуй другой плагин, ну… это юникс-вей ты просто не понимаешь. Да не хочу я понимать, я хочу чтобы программа работала из коробки и помогала мне автоматизировать рутину. Я не хочу ковыряться в лиспе, не хочу знать что там под капотом есть какой-то eglot, я не хочу компилировать Emacs из исходников, чтобы активировать поддержку treesitter, я знать не хочу что такое treesitter, это не нужно мне чтобы писать программы в рамках моих компетенций. И более всего я не хочу ничем из всего этого набора веселых равлечений для кружка «собери себе ИДЕ из говна и палок» заниматься потому, что даже после всех ковыряний, настроек и допилок оно не работает, как надо. Ты удаляешь файл в одном плагине, но он продолжает отображаться в другом, потому что они никак не синхронизируются, ты не можешь приметить цветовую схему для всей программы, потому все плагины индивидуально настраиваются, ты устанавливаешь плагин и видишь краказябры, потому что какого-то шрифта в системе не хватает - и прочее и прочее. Потом ты окрываешь Idea, видишь там, например, предиктивный автокомплит, который ты раньше даже не замечал, потому что… а в смысле, а чо такова? и понимаешь, что две недели на настройку Emacs ты потратил абсолютно впустую. https://www.linux.org.ru/forum/development/17471550?cid=17472261 И вообще весь тред про ужасное качество инструментов под линукс. Особенно в "stable" (r) (tm) Debian

Освоил методику измерения предела прочности на растяжения тридепечатных материалов с помощью рук, ног, цифрового безмена и двух отвёрток. Получил какие-то такие цифры: * ABS крашенный от Shapata - 31,5МПа * SBS Glass прозрачный от FDPlast - 11,5МПа * Нейлон газонокосилочный сухой - 67МПа * PETG прозрачный от FDPlast - 46МПа В качестве тестируемой модели использовал tensile_strength_2mmsq_breaker.stl из https://www.thingiverse.com/thing:1730653/files Также заметил, что экструдированный в воздух PETG хорошо работает как оптоволокно.

Кстати вчера обнаружил гитхаб как шелл/ftp Берём любой адрес с гитхаба только меняем tree на trunk и svn ls урл и svn extract урл Очень удобно Осталась микро шелл сделать с cd, pushd/popd

Долго анализировали какой разрядности линукс лучше поставить на нетбуки 2010х годов. Особенно с распаянной ОЗУ в 1 или 2 гб. Итого x64 выйгрывает на синтетике (ffmpeg, 7z b) на 10-15%. glmark2 даёт одинаковые результаты. НО mpv без vdpau/vaapi работает куда бодрее (720р на x64 грузит тестовый проц на 60% когда на i686 под 100% и кадры пропускаются). Жор 300мб на x64 против 212мб на i686. Веб браузер qute browser тоже работает сильно бодрее. Во первых я так понял qt6-webengine для i686 больше невозможен. А qt5-webengine работает совсем грустно. Даже на большой статической странице(любые онлайн доки) лаги при скроллинге. По жору тоже x64 300 мб у qt6 против 200мб i686 qt5 на тестовой странице. Итого выбираем x64 ради скорости и комфортной работы но открываем одновременно меньше приложений. В будущем посмотрим как это всё зависит от версии ядра. В этот раз все тестировали на 6.1.55 (вроде lts).

Самая популярная причина смерти в развитых странах на сегодняшний день - недостаточность кровоснабжения миокарда. То есть чтобы человеку выжить, ему даже не нужно добывать сраный двухваттный насос вместо потраченного, достаточно хуйни которая сможет периодически сжимать существующий мешок с клапанами. Однако же ни сраный двухваттный насос, ни хуйни в массовом доступе нет, только аппараты искусственного кровообращения в больницах в виде увесистой тележки и стоящие безумные деньги, да полтора стартапа с имплантируемыми девайсами по 200k USD за штучку, которые предлагается менять на аллотранспланты как только так сразу. Больше семидесяти лет назад сердце человека было впервые успешно заменено на несколько цилиндриков с двумя клапанами и медицинскими напалечниками в качестве поршней, собранные на автомобильном заводе; сегодня воз примерно там же остаётся, будучи недоступным простому человеку несмотря на всю свою простоту и потенциальную технологичность. Люди предпочитают обречь себя/своих пациентов на скорую смерть от совершенно закономерных иммунологических проблем после пересадки сердца из свежего трупа, либо просто умирают от отсутствия подходящих насосов под рукой у медперсонала. Как мы дошли до жизни такой? Где свернули не туда?

Русские хакеры заподозревали линоду и хуецнер в огранизации MitM на жаббер.ру: http://notes.valdikss.org.ru/jabber.ru-mitm/

сдался костылям и задал Xft.dpi прикол: тулкиты ведут себя по-разному если его нет (одни используют нативный dpi, другие считают что у тебя 96dpi), но одинаково если есть