/Простите, мне некуда это написать, я кроме ЛОРа и еще одного форума нигде не сижу/

Начало игры…

Создаю идеологию из смеси трансгуманизма, ритуализма и кровоедства. Сюжетка – вампирская. На экране выбора пешек сразу прокает сетап: Вампирша 22-х биологических лет возраста и 1941 хронологических. С перком на усердие и огоньками на горном деле, растениеводстве, медицине, общении и умственном труде. А также её дочка 18 лет – трансгуманист, кровожадная, бегун, с огоньками на ближний бой, горное дело и ремесло, да при этом еще и беременная! Сразу жму начать игру, чтобы случайно не рерольнуть такой крутой сетап – у нас тут сразу со старта намечается династия!

Первая осень…

К колонии присоединяется молодая девушка с огоньками в строительстве, искусстве, медицине и умственном труде. Всё бы ничего, вот только она словила комбо перков на дизмораль: завистливость, пессимист, непонятный творец. Оставляю её, хорошие руки и мозги в колонии нужны. Настолько нужны, что у меня нет времени держать её на перевоспитании для смены идеологии. Благо, она частично совместима с моей – в составе есть трансгуманизм и верховенство человека. (И за следующий год времени на перевоспитание так и не найдётся.)

Чуть позже в аварийной капсуле падает её мать. Она боец широкого профиля, крутой медик и строитель. Но снова перки подвели: подавленность и биоконсерватор. А у нас тут планы на тотальную конверсию человеков во всякое.

Решаю вылечить, и если она уйдёт – то выгоню следом и дочь. Но она присоединяется, не успев толком даже полежать в больничке.

Подумываю обеих выгнать позже, когда найду пешек с перками получше. Но тут обнаруживаю, что у этой космической беженки указан бывший муж… тот же чел, что и бывший муж моей вампирши. Что ж. Видимо, Ренди посылает мне знаки. Посмотрим, как с этими двумя игра пойдёт.

Вторая зимовка…

В начале зимы высаживается спящий кластер механоидов с регулятором климата на -10 градусов. Таймер сработает 12-го или 13-го декавраля, перед самым концом зимы. То есть вместо весны меня ждёт вторая зима, а вместо лета – робкая весна и сразу следом снова зима. К такому моя колония не готова, и запасов еды на бесконечную зиму у меня нет.

Корректор климата надо обязательно уничтожить за оставшиеся 2 недели, но у меня нет ни арты, ни дымовых завес для борьбы с туррелями, и даже не открыты нужные технологии. У меня вообще в этом прохождении с наукой не задалось, не смотря на то, что в колонии со старта два хороших исследователя. Но исследовать им некогда. У меня еще даже геотермалка не открыта.

Кластер высадился даже без купольной защиты – мне бы хоть один миномёт и запас боеприпасов.

Решаю смотаться по ближайшим соседям в надежде найти дымовые гранатомёты. Нигде их нет! Делать нечего, покупаю хотя бы автомат отличного качества и некоторое количество брони.

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

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

Зима подходит к концу, а я осознаю, что запасы риса тают слишком быстро – ведь я планировал тихо пересидеть зиму на базе, занимаясь исследованиями, а не носиться по всем окресностям, тратя рис на прокорм животных в пути.

Но вот откладывать дальше некуда – надо хотя бы поставить ёлочку ребятам, а на утро после праздника помолиться и идти в лобовой штурм без дымовой защиты. Какие еще есть варианты? Бросить базу и уйти строить новую, пока еще есть еда. Или тупо пересиживать на месте до лета, экономя жратву и охотясь на диких животных. А там попытаться снова купить дымовухи. Мне не нравится этот вариант, ведь тогда есть риск свариться как лягушка на медленном огне, только вместо огня – холод. Малодушно бросать базу без боя – не нравится еще больше.

Два моих вампира лежат в торпоре, придётся отмечать НГ без них. Ладно, пока все в добром здравии ставим ёлоч… Бзззз! Один чел после похода словил нервный срыв, вернувшись домой холодный и голодный.

Ладно, значит ты не празднуешь, без тебя ставим ёлоч… Бзззз! «Рейд мусорщиков десантируется на вашу базу!»

А ведь.. два моих вампира лежат в торпоре? Чёрт побери! А они двоё сражаются за шестерых.

Мусорщики десантируются прямо на точку, где неприкаянно ходит психанувший колонист. Мне остаётся только беспомощно наблюдать за ним, пока остальные пешки готовятся к обороне. Бесконечно долгие секунды, пока откроются десантные капсулы… Колонист сразу же получает по щщам стальной дубиной и падает – без сознания, но живой. Фух!

Оказывается, за те несколько мгновений, когда сначала видишь тени от садящихся капсул, а потом и сами капсулы, можно о столь многом успеть подумать. И том, что пусть с Маннингом остальные члены колонии не всегда находили общий язык, но все ценили его отличные навыки стрельбы и непререкаемую приверженность нашему учению. Когда-то в самом начале он сам пришел и попросился в колонию как верный последователь нашего дела. А также и о том, что вместе с Маннингом сейчас под десантирующимися капсулами окажется одна из лучших винтовок, и бой придётся принимать не только за минусом трёх бойцов, но и без самого качественного оружия.

Да в рейде-то еще и любовник девчонки, которая сидит у меня в плену. Снова шутки от Ренди.

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

Остатки рейда бегут. Поля с рисом горят. Два колониста лежат без сознания. База усыпана трупами мусорщиков. Тушу поля, выдыхаю…

А где это любовник… надо посмотреть статы девчонки. Ага, вот он лежит остывает. Не ушел. Еще тридцатника нет, а уже с циррозом печени был. Девчонку не жалко, она ведь тоже не просто так в камере у меня оказалась.

(В этом месте я вспоминаю, как я полгодом ранее пожалел иттакина - вылечил и отпустил. А через неделю он пришел снова в составе другого рейда. Там в землю и лёг.)

Даю полсуток двум раненым немного оклематься, и надо таки поставить ёлочку. Один вампир выходит из спячки. Приходит оптовый торговец, продаю всё ненужное и скупаю мясо. Еда это жизнь! Я бы продал вообще всё, что есть на базе в обмен на большой-большой запас сухих пайков, но у него их нет. И дымового гранатомёта нет.

Ставлю ёлочку. Колонисты собираются на праздник. Проходит несколько секунд:

Бзззз! «Рейд импидов направляется к вашей базе! Враг нападает немедленно!»

Бзззз! «Начинаются сильные заморозки!»

Сразу подряд.

А в составе рейда сын того импида, который у меня сидит в плену уже больше года и служит донором крови вампирам. Отца пришел спасать?

Ладно, какие-то вшивые импиды с луками, всего несколько человек. У меня тут еще и торговец со своей охраной тусит. После мусорщиков под гоу-соком, которые десантировались прямо на голову, импиды это вообще не противник.

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

Среди оставшихся лежать четверо еще живы. С двух снять одежду и оставить истекать кровью в снегу. Третий – тот самый сын, пришедший спасать отца. Захватить и посадить в ту же камеру. Там вы всю свою жизнь и проведёте. Четвёртая… 33 года, «девочка из племени», «беспечный стрелок», «оптимист»… похоже, так бедна, что даже снять с неё нечего. Одета в какие-то лохмотья. Оптимистка, блин… Посреди этого симулятора преступлений против человечности у меня вдруг почему-то дрогнула рука оставить её в снегу. Если выживешь после потери крови и не умрёшь от инфекции, то отпущу.

Бип! «Караван торговцев уходит из-за опасных погодных условий». А почему, снаружи же было -6… в смысле -29? Какой-то лаг в UI, это в холодильнике у меня должно показывать -29…. ЧО РЕАЛЬНО МИНУС ДВАДЦАТЬ ДЕВЯТЬ??? Я смотрю на уведомления, и до меня начинает доходить. Пока я разбирался с импидами, произошло не одно, а два события: три часа назад – начались природные сильные заморозки; час назад – активация искуственной погоды у мехов.

Появляется мстительная мысль, что дед, добежавший до края карты, далеко не убежит. С ранениями и в лёгкой одежде он не сможет выйти за радиус действия контроллёра погоды.

Следом приходит мысль, что и я не смогу. У колонистов не хватает тёплой одежды, я не одевал всех подряд с рассчётом на морозы под -30, поскольку в этих широтах зима не суровая. Излишки вещей и шерсти я просто продавал, а самые недавнюю партию как раз обменял на серебро и автомат отличного качества. Но из серебра не сшить пуховик…

Все посадки мгновенно вымерзают. С грядок пропадает будущая еда, а еда – это жизнь… Правда, есть еще животные в загоне, но насколько их хватит?

Сама база тоже не приспособлена к таким морозам. Правда у меня есть награбленные обогреватели, даже крафтить не придётся. Но нет запаса по мощности, и не везде есть сеть. Срочно отправить часть колонистов ставить пару дополнительных дровяных генераторов и тянуть провода, а другую – пополнять запасы дров?

И снова тот же вопрос, что и ранее, но теперь в острой форме: всё бросить и уходить? отсиживаться на базе, стараясь пережить самый холод? атаковать мехов немедленно?

Тем временем температура в части помещений падает ниже нуля.

Я рассматриваю местность вокруг мехов и нахожу предполагаемое направление атаки, с которого смогу разрушить металлическое заграждение и достреливать до контроллёра погоды, а сам буду находиться вне зоны прострела турелей за горным массивом. Но чтобы туда добраться, нужно сделать большой крюк. Вроде, есть план. Сначала спуллить мехов и уничтожить подвижную силу противника. Затем сделать большую петлю по карте, обходя зоны прострела турелей и горы, чтобы несколько бойцов с винтовками могли дотянуться до контроллёра. Оставив небоеспособных присматривать за пленными, готовлюсь к бою.

Бззз! «Приближаются шамблеры!» …вообще не до вас, ребята зомби… вы там замёрзните как-нибудь в снегах без моего участия, ладно? Еще не хватает классического в такой ситуации «Енот сходит с ума!». Да, Ренди?

Бой проходит относительно удачно. Подвижные дроны уничтожены, двое бойцов – ранены. Тяжело ранена та самая космическая беженка, которую когда-то я хотел выгнать. А сейчас она мой лучший стрелок.

Перед второй фазой боя нужна передышка.

А в это время на базе… у части пленных уже развиваются обморожения. В одной из камер температура упала до -12. В спальне, где весь пол был засажен розами вместо твёрдого настила – вымерли розы. Колонисты тоже плохо переносят холод. Кто был легко одет, к концу боя получили существенную гипотермию. Срочно надо разводить костры, оказывать помощь пленным, думать, как кого переодеть, спасать замерзающих животных в загоне, а все уже на грани нервного срыва и валятся с ног. Одна только дочка главы поселения не унывает и пашет как трактор. Перк кровожадность – сила. После участия в двух мясорубках с кучей убитных врагов, у ней такой запас хорошего настроения, что ничто не может его перебить. А если еще закинуться бодрином, то можно пахать всю ночь и всё утро, пока остальные уже почти сходят с ума.

/здесь пока моё прохождение останавливается/

Пишу сейчас очередной sh-скрипт с кучей вызовов awk, grep и sed. В связи с чем задумался об альтернативах. Попытался сформировать список черт, которые делают sh до сих пор актуальным инструментом:

• Возможность легко и просто скомпилировать под любой утюг.
• Отсутствие развесистой библиотеки, которую интерпретатор таскает с собой, а также как следствие — нет слома совместимости между версиями библиотеки.
• Минимальное время инициализации интерпретатора.
• Малое потребление памяти.
• Простой параллелизм через fork.
• Возможность удобно и просто вызывать внешние команды и пайплайны команд.
• Возможность прозрачно миксовать внешние команды и собственные функции. (В sh мы делаем command1 | command2, и это работает одинаково, независимо от того, являются ли эти команды собственными функциями или внешними командами.)

Если обобщить, то главным отличием sh от ЯП типа perl, ruby, python и т.п. является композиция программы как совокупности исполняемых модулей, запускаемых как отдельные процессы, в противовес композиции библиотечных модулей, слинкованных в единый процесс.

Главным минусом sh является то, что в нём не развиты средства работы с какими-либо структурами данных, кроме строк. Да и для самих строк средства не развиты.

То есть потециальная альтернатива sh должна обладать всем перечнем указанных черт, но дополнительно иметь развитые средства работы со структурами данных такими как списки, хэш-массивы и т.д.

Откопал ссылку на такую штуку в Арчевики. Простая программа, реализующая для man pages в терминале то, что еще 35 лет назад было в справочных системах под DOS-ом, + большее.

• Страницы оглавлений, отображающие все маны, установленные в системе, сгруппированные по категориям
• Интерактивный инкрементальный apropos и whatis (search as you type)
• Инкрементальный поиск по странице
• Активные гиперссылки на другие маны
• Активные гиперссылки на http(s) и email адреса.

Навигация вверх-вниз по странице сделана максимально удобным образом:

• Если в направлении листания на экране есть следующая ссылка, фокус переходит к ней.
• Если в направлении листания на экране следующей ссылки не видно, текст сдвигается на 1 строку.

Программа реализована на Си с минимумом зависимостей.

Зависимости в собранном виде и размер:

vadim@aquila:~$ ldd /usr/bin/qman
	linux-vdso.so.1 (0x00007dbe6007f000)
	libncursesw.so.6 => /usr/lib/libncursesw.so.6 (0x00007dbe5ffa3000)
	libinih.so.0 => /usr/lib/libinih.so.0 (0x00007dbe5ff9e000)
	libc.so.6 => /usr/lib/libc.so.6 (0x00007dbe5fdb2000)
	/lib64/ld-linux-x86-64.so.2 => /usr/lib64/ld-linux-x86-64.so.2 (0x00007dbe60081000)
vadim@aquila:~$ ls -lh /usr/bin/qman
-rwxr-xr-x 1 root root 116K мая 29 11:43 /usr/bin/qman

Сорцы и скриншоты тут: https://github.com/plp13/qman

Какие вообще есть решения для этого? Чтобы безмышевозанья.

Иными словами, как программно получить данные из экранного буфера?

Извиняйте, просто навеяло ночью.

Вот пример:

https://web.archive.org/web/20240128100538/https://en.wikipedia.org/wiki/Zero_Install

По меньшей мере с 2005-го года, то есть почти 20 лет лежала статья, никому не мешала. Содержала ссылки на другие похожие решения и технологии.

В январе 2024-го явился вахтёр и статью удалил как «незначимую».

В чем смысл такой энциклопедии, не очень понятно. Что «Волга впадает в Каспийское море» Гугл и так подскажет, без энциклопедии.

Щас еще осталось поисковые системы полностью на ИИ заменить, и в инете вообще ничего невозможно будет найти ни по какой теме.

Данная тема создана по следам этого: 750 мб занятой оперативы на старте дистрибутива с XFCE - это норма?

Люди так удивляются, что 4 ГБ – это мало для работы, будто то ли на на дворе 2005, то ли Linux может магически превратить 4 ГБ в 16, и еще пару ядер накинуть на сдачу.

Но тем не менее, вопрос, сколько ест максимально голая система – интересный. У меня Арч, и я решил посмотреть, что у меня с потреблением памяти. А тему эту я решил создать, чтобы ссылаться на неё при необходимости.

Вот картина потребления оперативной памяти без логина в графический сеанс:

https://ibb.co/BNrCWMk

Я отключил все службы, которые нужны лично мне, такие как docker, оставил только системные штуки. Видно, что запущен systemd с базовыми сервисами, NetworkManager, а также lightdm с графическим сеансом, через который отображается окно ввода логина-пароля. Не запущены также штуки, которые часто суют в дистрибутивы по дефолту – cups, wsdd и т.п. (У меня их на этой машине и нет.)

Опускать потребление ниже этой базовой линии возможно только если отказываться от systemd, а также накладывать на систему какие-нибудь кастомные патчи. Это уже получится не линукс мейнстримного вида образца 2024-го года, а специализированная сборка.

А вот после входа в графический сеанс пользователя:

https://ibb.co/m5WCWvP

Опять-таки, я закрыл все штуки, которые лично мне нужны, такие как syncthing или автозапускаемый сеанс в terminator.

Если вместо графической оболочки из нескольких отдельных программ использовать компактный WM типа icewm, то можно подсократить эти числа, чтобы они были ближе к числам на 1-м скриншоте. Но не вижу в этом большого смысла.

Короче говоря, если сравнивать с виндами, то Linux в 2024-м может базово потреблять ОЗУ где-то на уровне Vista. Всё в ваших руках: хотите потребление как у Висты и запуск на старом лаптопе – это возможно, хотите ни в чём себе не отказывать на системе с 64 гигами – это тоже возможно.

На практике после входа в графический сеанс, автозапуска всех нужных служб и приложений и открытия тестового редактора с кучей вкладок потребление памяти у меня составляет 800-900 МБ.

В теме Это правда, что большинство пользовательских программ в linux больше грузят процессор, чем их альтернативы в windows? увидел сообщение от amd_amd:

CPU: Intel Pentium 4 3.20GHz (2) @ 3.200GHz

И ответ на него от haydudogni:

Энергопотребление (TDP): 82 Watt

у меня 8 и это APU

Сначала хотел ответить, что нельзя напрямую сравнивать эти процессоры по TDP, потому что между ними технологическая пропасть, и Pentium 4 невероятно устаревший со своим техпроцессом и особенностями архитектуры.

Но затем в связи с этим вспомнил недавнее видео с обзором ноута на процессоре N100, и что я как раз хотел создать тему для его обсуждения.

Не знаю, насколько слаб старый APU от AMD у ТСа в той теме, но новые процессоры, которые Intel пропихивает в бюджетный сегмент, тоже не радуют:

https://www.youtube.com/watch?v=pCkM8yRQoMs

Если кратко:

В чисто вычислительных тестах показывает производительность на уровне мобильных Core i3 11-го поколения, что весьма неплохо.

В то же время, в ряде тестов проваливается практически до уровня Core 2 Duo. (o_O)

Основная проблема этого SoC — невероятно задушенная пропускная способность ОЗУ. Это становится особенно критично на фоне того, что встроенный GPU критично чувствителен к скорости работы памяти.

Как результат, ноутбук 2024-го года не в состоянии вытянуть Fallout New Vegas и Skyrim. Производительности системы хватает, чтобы воспроизводить ролики с ютуба. Обзорщик явным образом этого не сказал, но к слову «хватает» определённо просится добавка «впритык».

Вот такие неоднозначные решения делает Intel, лишь бы только не конкурировать с собственными полноценными процессорами.

Пример задачи:

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

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

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

Легко сообразить, что данная задача решаема на статически типизированном языке. (С разным уровнем костыльности-некостыльности, в зависимости от того, что это за язык.) И нерешаема на динамически типизированном языке.

Усложненный вариант задачи.

В программе имеются мьютексы m1, m2… mN.

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

Как известно, задачи межпоточного взаимодействия являются наиболее сложными для создания корректных алгоритмов, их проверки и отладки.

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

Вышел первый публичный релиз нового композитного менеджера для X11 на основе исходного кода классического xcompmgr.

CPU usages by compositor:

Compositor      move    resize  scroll
fastcompmgr     6.7%    4.4%    1.5%
xcompmgr        7.8%    4.9%    1.6%
compton         26.4%   6.8%    17.1%
picom           29.3%   8.1%    23.1%

Подробности:

• https://github.com/tycho-kirchner/fastcompmgr

Выглядит как сборка пакетов здорового человека:

https://github.com/pacstall/pacstall-programs/blob/master/packages/emacs/emacs.pacscript

Правда вебня свёрстана через одно место. Еще поменьше всплывающее окно нельзя было сделать? https://ibb.co/RDDYVvq

Называется, сам не знаю, чего хочу.

Что-то среднее между ming mapping и программой для составления презентаций из слайдов. Чтобы на слайды можно было по-быстрому накидать диаграммы и блок схемы, а отдельные элементы диаграммы сделать ссылками на другие слайды, где этот элемент описан подробнее. Такой древовидный набор слайдов с гиперссылками между ними.

При чем мне даже кажется, что я давно под винду видел что-то такое. А вот под линь – вроде не сталкивался.

Или это всегда так было?

1. Открываем LO Writer.
2. Идём на панель рисования, создаём на странице что угодно, например, прямоугольник.

В этот момент последовательно и с ощутимой ясно видимой задержкой происходят следующие вещи:

• Тулбар форматирования текста исчезает.
• Это приводит к тому, что страница прыгает вверх на высоту данной панели.
• На тулбаре «Стандарт» происходит отключение части кнопок, в процессе этого они одна за другой перемигиваются огоньками, то есть панель обновляется не атомарно.
• С еще более долгой задержкой обновляется внешний вид линеек.

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

• Тулбар форматирования текста появляется.
• Это приводит к тому, что страница прыгает вниз на высоту данной панели.
• На тулбаре «Стандарт» происходит включение части кнопок, в процессе этого они одна за другой перемигиваются огоньками, то есть панель обновляется не атомарно.
• В последнюю очередь обновляется внешний вид линеек.

Мне это так понравилось, что я на минуту залип, тыкая туда-сюда, любуясь этим представлением с припадошной страницей.

Вот как раз такое я имею в виду, когда говорю, что UI у опенсорса обычно сделан из говна и палок. Лучший офисный пакет, согласно коллективному мнению ЛОРа.

UPD: https://drive.google.com/file/d/1tUBerVKMF7FD1CLnMh3GQYociDC0uKeK/view?usp=sharing

Вот пример проблем, которые мешают создавать продвинутые способы интеракции приложений:

1. Не существует способа узнать положение клавиатурного курсора в окне стороннего приложения. Это необходимо, чтобы открывать произвольные меню и панели «по месту» ввода.
2. Не существует способа узнать выделенный текст в окне стороннего приложения. Буфер PRIMARY предназначен не для этого, соответственно его содержимое не сбрасывается после сброса выделения.
3. Не существует надежного способа вставить текст в окно стороннего приложения. Используемые сейчас варианты - это костыли с эмуляцией нажатия клавиш, которые в зависимости от приложения, могут либо не работать, либо давать непредсказуемые эффекты.

Ровно этот же список я мог бы назвать 15 лет назад, с тех пор ничего не изменилось.

Как видно, речь идёт о том, чтобы операции вида «сделать что-то с выделенным текстом» или «вставить результат работы стороннего приложения» могли быть бесшовно интегрированы между приложениями без необходимости хардкодить это в тулките или грузить so-шки с хаками в адресное пространство приложения.

Банальные примеры подобных интеракций:

• Вставить текущую дату в выбранном пользователем формате.
• Выполнить выделенный текст как команду оболочки и вставить результат.

Вместо решения задач подобного рода, «разработка GUI стека» сосредоточена на борьбе с возможностью приложениям управлять позицией своих окон и в очередной раз сломанным переключателем раскладок. Простите, но я отказываюсь считать это за «прогресс».

qulinxao3 писал:

однако жаль малоиспользуется sam|acme

и в целом логика исполнения текущей строки редактируемого файла(текстового буфера) тем или иным исполнителем и помещение возвращённого результата (побочный итак в глобальности) в тот или иной текстовый контейнер

ззы: ща на ctrl-\ в сode висит Terminal: Run Selected Text ln Active Terminal который при пустом выделении отрабатывает текущую строку - получается нечто парное vim'овскому :r!вотэтовотвыделение

забавно как пламбер оказался не ко времени всё ещё

Я ему ответил:

Я как-то себе делал приблуду, которая по хоткею берёт выделенный текст как имя файла и открывает его. Если путь к файлу указан не от корня, то она пытается вычленить путь к текущему каталогу из заголовка активного окна. Поскольку обычно у меня активное окно это либо терминал, либо текстовый редактор, и они настроены давать там эту информацию, то всё работает «магически».

Этот обмен репликами заставил меня вернуться к мыслям об организации хоткеев в SDE. И вот хочу показать вам фрагмент черновика на эту тему.

Также дополнительно к сказанному в черновике хочу сказать следующее:

Я многократно говорил, что задача DE – интеграция программ. Мне на это отвечают, что «интеграция программ» создаёт монстров, примеры которых мы можем наблюдать в KDE и вообще везде.

Мой ответ на это: правильная интеграция монстров не создаёт. Программы вообще не должны знать о существовании друг друга. Им не нужно линковаться друг к другу и не обязательно иметь so-шки на пару тысяч символов. Всё, что им нужно – предоставлять о себе немного информации.

Всё, описанное ниже, доступно к реализации даже при помощи несложного bash-скрипта для любой DE или вообще без DE. Но конечно грамотная реализация на Си – предпочтительнее.

Итак, сам текст:

Хоткеи запуска приложений:

Super + Q - Запустить предпочитаемый эмулятор терминала
Super + W - Запустить предпочитаемый текстовый редактор
Super + E - Запустить предпочитаемый файловый менеджер
Super + R - Показать лаунчер для быстрого запуска команд
Super + T - Запустить предпочитаемый web-браузер
Super + Y - Запустить предпочитаемый калькулятор

Как видно, горячие клавиши выбраны так, чтобы располагаться подряд в 1-й буквенной строке клавиатуры (QWERTY) и не имеют мненомического значения. Порядок клавиш выбран в соответствии с тем, какие приложения обычно наиболее часто востребованы при работе с типичной UNIX-like системой: в первую очередь вам потребуется терминал, во вторую текстовый редактор и так далее.

Хоткеи, использующие выделенный текст как путь к документу:

Super + Shift + Q - Запустить предпочитаемый эмулятор терминала в указанном каталоге
Super + Shift + W - Открыть указанный файл в предпочитаемом текстовом редакторе
Super + Shift + E - Показать указанный файл в предпочитаемом файловом менеджере
Super + Alt   + E - Показать контекстное меню для указанного файла
Super + Shift + R - Показать лаунчер для быстрого запуска команд и выполнить команду для указанного пути
Super + Shift + T - Открыть указанный URL в предпочитаемом web-браузере

Каким образом DE понимает, что является «указанным файлом/каталогом»:

Первый вариант — если выделен некоторый текст.

1. Если выделенный текст выглядит как URL, то он и считается указанным.
2. Если выделенный текст выглядит как полный путь (начинается с символа /), то он и считается указанным.
3. В ином случае выделенный текст считается файловым путём относительно текущего каталога. Следовательно, необходимо найти текущий каталог.
   • Для этого DE извлекает путь к документу из текущего окна.
   • Если путь является существующим каталогом, то он и считается текущим каталогом.
   • Если путь является существующим файлом, то берётся путь к его каталогу.
   • Если путь извлечь или проверить не удалось, то домашний каталог пользователя считается текущим.

Второй вариант — если текст не выделен.

В этом случае DE извлекает путь к документу из текущего окна.

• Если запускаемое приложение требует только путь к каталогу (как в случае с Super + Shift + Q), то путь урезается до пути к каталогу.
• В ином случае используется полный путь.

Частные примеры действий, которые становятся вам доступны c использованием данных возможностей:

• Показать в файловом менеджере каталог, с которым вы работаете в терминале.
• Открыть терминал в каталоге, который вы просматриваете в файловом менеджере.
• Открыть терминал в том каталоге, где лежит документ, с которым вы сейчас работаете.
• Выделить имя файла в окне терминала и открыть его в редакторе или в любой программе по вашему выбору.
• Выделить имя файла в текстовом редакторе и открыть этот файл.
• Выделить имя файла и показать контекстное файловое меню.

Таким образом ваша работа с документами перестаёт быть приложение-центричной и становится документо-центричной. В фокусе вашего внимания то, С ЧЕМ вы работаете, а не то, КАКИМИ ПРИЛОЖЕНИЯМИ вы работаете. Вы легко можете «перекинуть» один и тот же файл/объект/документ в другое приложение просто нажав хоткей. DE видит и понимает контекст вашей работы.

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

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

Сабж: https://www.youtube.com/watch?v=ahbhydZSF2c

CPU LS3A6000, 4 ядра, 8 потоков, 2.0-2.5 ГГц, L3 16 МБ

TLDR:

1. Автор видео сравнивал производительность с 12600K. Если для 12600K выставить аналогичные число ядер и максимальную частоту, то он всё равно оказывается быстрее, чем 3A6000.
2. Сетевая карта аппаратно отвалилась прямо во время тестов.
3. Дискретная видеокарта не запускается.
4. Если использовать больше двух устройств USB, у автора начинала глючить мышь.

Хочу рассказать о своём видении некоторой «ментальной модели» – того, как пользователь настоящего и будущего выстраивает и будет выстраивать взаимодействие с программной средой.

Сейчас тенденция такая, что в распоряжении человека становится всё больше различных вычислительных систем.

У пользователя запросто может быть во владении пара смартфонов, планшет, пара ноутбуков, один жирный десктоп, пара крупных мониторов, да еще умный телевизор в полстены.

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

Весь этот зоопарк устройств обусловлен спектром ФИЗИЧЕСКИХ различий. Что-то экономичное и компактное, что-то большое и мощное, а что-то привязано к конкретному рабочем месту – под физически разные контексты необходимы физически разные устройства, что обусловлено объективными ограничениями нашего материального мира и доступных нам технологий.

А вот голова у пользователя – одна. И в этой голове совсем нет необходимости, и одни только проблемы от того, что у вас есть, скажем, восемь разных «мест», в которых лежат разные данные, установлены разные программы, выполнен вход в разные сервисы, применены различные персональные настройки и так далее.

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

Вот этот «перенос данных в облака» — он как раз про это — про то, чтобы отвязать ваше личное информационное пространство от физической коробки.

Но я хочу поговорить не про корпоративные попытки сделать вас рабом системы, которая хранит все ваши данные на своих серверах. А про что-то противоположное.

Итак, у моих данных есть некоторый «дом по умолчанию». В моём случае это ноутбук. Это решение сегодняшнего дня, но оно меня устраивает не всецело. В идеале, таким решением должен быть смартфон как более компактный и лёгкий девайс.

А если говорить точнее, то между моим ноутбуком и смартфоном не должно быть никакой разницы.

Ведь эти устройства оба полностью в моём распоряжении, это не чужие устройства, за которыми я работаю временно, а именно что мои.

Если я работаю за ноутом, и если я работаю со смартфона — я должен видеть только физическую разницу устройств, но не то, что это две отдельные системы хранения и обработки данных. Переход с устройства и на устройство должен быть прозрачным.

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

После этого разница для меня как пользователя только в том, что десктоп мощный и стационарный, а лаптоп – переносимый, но не такой мощный.

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

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

А как было сказано выше — между моим ноутбуком и смартфоном не должно быть никакой разницы. Следовательно, я работаю с чужой машины точно так же, как если бы я сидел дома за своим ноутбуком.

Всё вышеописанное вполне естественным образом ведёт нас к peer-2-peer структуре. Не той, которая «противостоит цензуре и за свободу информации», а сугубо практической её стороне — упрощение управления зоопарком машин, снижение затрат на их администрирование, на управление личными данными.

В такой модели «владение данными» и «обработка данных» отвязаны от «владения железом» и от административных издержек, с ним связанных.

Также такой подход можно назвать термином Zero Effort, который я придумал только что. Суть этого подхода состоит в том, что мы решительно устраняем любые издержки на какой-либо процесс… концептуально меняя парадигму софта и работы с ним. То самое: «Идеальный прибор — когда прибора нет, а функции его выполняются.»

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

• ZeroInstall — децентрализованная кросс-платформенная система инсталляции софта, отвязанная от операционной системы (но способная использовать общесистемный кэш артефактов при соответствующей настройке). Флатпак здорового человека, если бы его делали не архитектурные астронавты.
• ZeroNet — децентрализованная система доставки и исполнения веб-сайтов и веб-приложений.
• IPFS — децентрализованная система доставки файлов по хэш-суммам.
• syncthing — децентрализованное средство прозрачной синхронизации файлов между машинами.

Каждое из этих решений вполне подходит под концепцию Zero Effort:

• ZeroInstall устраняют издержки на обслуживание пакетной базы операционной системы, устраняя идею общесистемной пакетной базы.
• ZeroNet и IPFS устраняют издержки на обслуживание хостинга путём уничтожения понятия хостинга как самостоятельной единицы, необходимой для функционирования веб-сайта.
• syncthing устраняет издержки на обслуживание физически разных носителей, делая их физически разнесёнными зеркалами одного виртуального носителя.

P.S.

4 указанных примера на мой взгляд являются реальными инновациями и движением вперёд согласно духу времени и потребностям людей. А вот изобретение очередной оконной системы, звукового сервера и переписывание очередной библиотеки на Раст — никак таковыми не являются.

syncthing был реализован на Go, и это никак ему не помешало.

Ситуация:

Была запущена opera, которая жрёт 6 гигов, + была запущена игруля. В результате система вытеснила Оперу и всё ненужное в своп. Теперь закрываем игрулю, а затем закрываем Оперу.

Остаётся вот такая картина:

vadim@aquila:~$ free -m
               total        used        free      shared  buff/cache   available
Mem:           15906        1647       13367         711        1915       14259
Swap:           8191        4887        3304

Как видно, занято 4887 метров в свопе. Я уже знаю, что это течёт моя программа, но суть тут в том, что смотрим как работает учёт потребления памяти. Вырубаем своп:

vadim@aquila:~$ sudo swapoff -a
[sudo] пароль для vadim: 
vadim@aquila:~$ free -m
               total        used        free      shared  buff/cache   available
Mem:           15906        6511        8494        5139        6351        9395
Swap:              0           0           0

Теперь вся утёкшая память загружена из свопа обратно в ОЗУ. И она, внезапно, в секции shared. И при этом она же — в секции «buff/cache»! А вот это неожиданно.

Смотрим разницу показателей, цифры бьются логично:

buff/cache 6351 - 1915 =  4436
shared     5139 - 711  =  4428
used       6511 - 1647 =  4864
swap used  0    - 4887 = -4887

Теперь смотрим htop:

https://ibb.co/QYqJGbG

И как видно, в htop нет большого объёма «buff/cache». Он понимает, что «buff/cache» и shared дублируют друг друга.

И также видно, что утёкшая память не отображается ни в RESIDENT, ни в SHARED, ни даже в VIRTUAL ни одного процесса. Она есть, она учитывается системой как занятая, но её нет в счётчиках показателей потребления памяти процессов.

Теперь убиваем виновника:

vadim@aquila:~$ killall stuurman-desktop
vadim@aquila:~$ free -m
               total        used        free      shared  buff/cache   available
Mem:           15906        1782       13214         442        1663       14124
Swap:              0           0           0

Смотрим разницу показателей, вот столько памяти у нас освободилось:

buff/cache 6351 - 1663 = 4688
shared     5139 - 442  = 4697
used       6511 - 1782 = 4729

Итак, пока только один вывод:

• Реальное потребление памяти процессом может быть никак не связано с числами, которые htop показывает для процесса.

И остались открытые вопросы:

1. Что именно показывает free и что именно показывает htop для общесистемных показателей. Придётся заглянуть в код, чтобы узнать точно.
2. Как при таких условиях искать источник большого потребления ОЗУ в случае, если у нас нет возможности убивать все подозреваемые процессы подряд.
3. А, ну и чуть не забыл. Надо всё-таки найти и исправить утечку в моём коде… когда-нибудь уже.

Разработчики GNOME подвели итоги работы, проведённой в проекте за последнюю неделю. Мэйнтейнер файлового менеджера Nautilus (GNOME Files) опубликовал планы по созданию реализации интерфейса выбора файлов (Nautilus.org.freedesktop.impl.portal.FileChooser), который может применяться в приложениях вместо диалогов открытия файлов, предоставляемых GTK (GtkFileChooserDialog). По сравнению с реализацией из GTK в новом интерфейсе будет обеспечено более близкое к GNOME поведение и визуальное оформление, а также будут задействованы элементы и расширенные возможности платформы GNOME, такие как libadwaita и пометка избранных файлов звёздочкой.

(Источник: https://www.opennet.ru/opennews/art.shtml?num=60939)

Картинко: https://thisweek.gnome.org/posts/2024/04/twig-142/0986a0a3dabcb41da5823158529d99e3bc6044811776317521763237888.png

1. Хорошая новость: Гном наконец-то понял, что диалог открытия файлов должен делаться на основе файлового менеджера. На это ушло всего… 27 лет.
2. Плохая новость: теперь диалог открытия файлов будет тормозить так же как весь Наутилус.

• Видео: https://www.youtube.com/watch?v=L1oECH6rPvs
• Мануал: https://docs.google.com/document/d/1-nDv_8WEG1FrlO3kEK0icoYo-Z-jlhpCMiCstxGOCjQ/edit
• Схемотехника и софт: https://github.com/slu4coder/Minimal-64x4-Home-Computer

Автор пишет, что компьютер по производительности в 4 раза превосходит Commodore C64 и Apple II.

Сабж: https://www.youtube.com/watch?v=E-VDF85F-XY

TLDR:

• Реальные приложения либо не запускаются, либо не работают, либо роняют систему.
• Система в любой момент готова свалиться с ошибками даже в виртуалке.
• На реальном железе у автора видео не запустился даже установщик.

Собственно, за 2 или 3 года с тех пор, как я писал о том, что ReactOS некому разрабатывать, ничего не изменилось.

Ядро и критичные системные компоненты нуждаются в существенных доработках и исправлении багов. Заниматься этим некому. Та малая часть коммитов, которая по коммит логу идёт в ntoskrnl и другие критичные вещи — это капля в море.

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