Начнем с 1,2,3.
Окрываем эмулятор терминала и запускаем:

$xrandr --output LVDS1 --scale 1.25x1.25
(Вместо LVDS1 возможно придется указать другое значение, не знаю как его узнать кошерно, я подсмотрел в диалоге MATE: Система->Параметры->Оборудование->Экраны. У меня там картинка экрана: Ноутбук: LVDS1)

ВСЁ! Это работает на уровне системы, решение подсказали на LOR, когда я расхваливал Xfce с таким же решением в пункте меню.

Далее идем в Система->Параметры->Персональные->Запускаемые приложения и добавляем скажем: screenresize с параметрами: $xrandr --output LVDS1 --scale 1.25x1.25

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

Я являюсь владельцем древнего 10" нетбука который тут все рекомендуют выкинуть... Но впрочем он вполне работает, и с собой брать не так тяжело как толстую машинку....
Но всегда мучала проблема... Открываешь в Линуксовом десктопе какое нибудь модальное окно и оно больше чем 1024x600, кнопочки: «Применить», «Сохранить», «Идинафик» - находятся где то за нижней границей экрана.
Играясь с Manjaro Linux (Я его назвал Мажориком, хотя тут ходит Ник: Бомжара) я столкнулся с оконным менеджером Xfce, у которого прямо в меню настроек можно выставить масштаб 1.2 и всё стало вмещаться на УРА!
Расписал это здесь на форуме, и анонимус подсказал мне решение, ссылкой на: https://wiki.archlinux.org/title/HiDPI.

Теперь я знаю об этом рабочем решении и хочу поделиться им с другими!

Есть идея перекинуть 1с ерп с вин 2019 на дебиан (бд уже постгря под вин)
С реализацией в режиме клиент-сервер в целом все понятно, нюанс в том что в вин по традиции у нас используется терминальный сервер и у клиентов стоят простенькие моноблоки, задача которых исключительно запустить рдп клиент.

Вопрос - стоит ли городить терминальный сервер под лин вообще, и если да то на чем оно работает более внятно - vnc или xrdp?

Клиентов пытались перенести на линух много лет назад но тогда все уперлось в весьма унылую работу рдп с виндовым сервером - имеются некоторые фантомные боли после этого и очень хотелось бы услышать историю успеха из современного мира ^_^

В продолжение предыдущей темы: Acer Extensa 4220. Еще в строю. Железо то же, ОС та же. На этот раз ОС поставлена на родной 80-гиговый HDD. Который работает на удивление тихо, кстати. Не слышно гула и щелчков, в отличие от более нового 1-терабайтного HDD в ноуте, что стоит рядом на столе.

Я решил выяснить, насколько сложно будет собрать GTK2-версию XFCE на свежем Арче. В AUR нашлась бОльшая часть пакетов. Но некоторых зависимостей не хватало. Я добавил нужное и внёс некоторые правки в имеющееся. Залил сюда: https://github.com/sde-gui/PKGBUILDs-xfce4-gtk2

Кому надо, пользуйтесь, репортите баги и отправляйте пул-реквесты. В AUR запиливать откровенно лень. Это всё еще не максимальный комплект того, что входит в XFCE со всеми допами. Если что-то нужно добавить в сборку, пишите.

На скриншоте видно потребление памяти. XFCE ест больше, чем LXDE/SDE. Для сравнения потребление под SDE: https://ibb.co/HYmnm9r

Еще раз проговорю некоторые моменты относительно потребления памяти и использования Арча на старых машинах:

• Я не проводил никаких оптимизаций и специальных настроек системы. Это Арч как есть + куча разного софта, установленного за годы на исходной машине, откуда он был скопирован (что-то я почистил, но далеко не всё). Задача данной серии экспериментов - посмотреть, насколько пригоден ванильный Арч без тюнинга для работы на Core 2 Duo. Получается, что абсолютно пригоден.
• Это 64-битная ОС. На системах с < 4 ГБ ОЗУ имеет смысл поставить Arch Linux 32, так что потребление памяти еще снизится.
• ОС запущена в контейнере Bedrock-а, и там работают демоны Bedrock-а. Это тоже дополнительные расходы.

И немного личных выводов:

Половину дня провёл за этим ноутом, слушал музыку с ютуба, открывал кучу вкладок с разных сайтов. Правил файлы, работал с git и компилировал пакеты. Производительности машины в целом хватает, но запас по ОЗУ не очень большой. Компиляция кода на Си упирается не столько в CPU, сколько в IO на HDD. Вот если SSD поставлю, там уже в CPU упрусь. GUI не тормозит, работает отзывчиво. Памяти на какой-то из линковок потребовалось много, и около гига улетело в своп. В общем, 3 гига пока всё еще нормально для задач печатной машинки и веб-терминала. Думаю, на 2-х было бы уже сложновато.

P.S. Hobbit, верни тег gtk2 в БД!!!

Приветствую. Казалось бы, тривиальная в 2023 году вещь - распарсить строку по делимитеру и загнать это в массив. Но нет, просто не будет.

Впрочем вопрос не в этом. Есть код. Описания переменных и прочая, я опущу, перейду сразу к сути.

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

printf("\n============ Parsing: ");printf(gtk_path);printf(" ========\n");
fg_color = "#888888";
bg_color = "#AAAAAA";

filePointer = fopen(gtk_path, "r");

while(fgets(buffer, bufferLength, filePointer)) {

 if (strstr(buffer, " fg_color ") != NULL)  {
  printf("\nFound fg_color entry: ");
  char **arr = split(buffer, ' ');
  fg_color = trim(arr[2]);
  printf(fg_color); // <<<<
 }

 if (strstr(buffer, " bg_color ") != NULL)  {
  printf("\nFound bg_color entry: ");
  char **arr = split(buffer, ' ');
  bg_color = trim(arr[2]);
  printf(bg_color); // <<<<
 }

}

fclose(filePointer);
printf("\n *** \n");printf("Main color: ");printf(fg_color);printf("BG color: ");printf(bg_color);printf("\n");


// Для информации приведу функции split и trim, хотя дело вряд ли в них.

char **split(char *str, char delim) {
  char **arr = malloc(sizeof(char *) * (strlen(str) + 1));
  int i = 0;
  for (char *p = strtok(str, &delim); p; p = strtok(NULL, &delim)) {
    arr[i++] = p;
  }
  return arr;
}

char *trim(char *s) {
    char *ptr;
    if (!s)
        return NULL;   // handle NULL string
    if (!*s)
        return s;      // handle empty string
    for (ptr = s + strlen(s) - 1; (ptr >= s) && isspace(*ptr); --ptr);
    ptr[1] = '\0';
    return s;
}

Задача блока - прочитать CSS-файл, и выдрать с него полторы строчки в массив.

Сначала присваиваем двум переменным какое-то значение, например #888888 и #AAAAAA;

Читаем построчно файл, ищем в каждой строке нахождение подстроки, если подстрока найдена, тогда парсим ее в массив, и присваиваем нашей главной переменной значение массива с определенным индексом, и ГЛАВНОЕ - тут же выводим эту переменную на экран.

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

А вот что оно выводит:

============ Parsing: /usr/share/themes/Relax-Light-GTK/gtk-3.0/gtk.css ========

 *** 
Main color: #888888BG color: #AAAAAA

============ Parsing: /usr/share/themes/White - OE2-GTK/gtk-3.0/gtk.css ========

Found fg_color entry: #5C616C;
Found bg_color entry: #FAFAFA;
 *** 
Main color:  #000000;
BG color:  #000000;

Вопрос: откуда нах взялся этот #000000 ?

Когда подстрока не встречается в строке (т.е. файл не содержит ни fg_color ни bg_color) - возвращаются правильные значения того что я установил. Этот кусок работает правильно.

Да, возможно парсер работает криво, но ведь каждое присваивание fg_color = сопровождается printf'ом, и в пределах if'а с парсером видно, что парсер отрабатывает на отлично. #000000 - явно взято откуда-то из файла, но как оно могло пробраться в переменную, и не засветиться в выводе этой переменной ? ЧЯДНТ ?

Привет, ЛОР.

В посте полугодичной давности я рассказал о том, как я возился с монохромным монитором от МежДелМаша, подключая его к IBM PS/2. Теперь же я хочу поделиться с вами совсем-таки недавним моим успехом уже софтверного характера, впрочем всё так же занимающим своё заслуженное место в одном из разделов Специальной олимпиады, а именно, — я модифицировал древний MINIX 1.7.5 под нужды своего компьютера, дабы использовать все основные возможности железа. Но начну я своё изложение всё-таки с описания характеристик, ибо именно оно является основным лимитирующим фактором.

Итак, на фото один IBM 8530 (PS/2 Model 30 286) со следующими параметрами

• Процессор от SIEMENS, клон Intel 80286, 16-bit
• Память 1 Мб (разбита на 640k+384k)
• VGA на материнке
• PS/2 клавиатура и мышь
• Три ISA слота (мне повезло не возиться с MCA)
• Compact Flash XT Lite adapter rev 4.1
• Ethernet от SMC (WD8390 совместимая карта с RJ-45 и BMC)
• EGA видеокарта от ATI с поддержкой MDA и CGA режимов

Делловский монитор подключён к VGA из материнки, а вот с монохромным монитором пришлось повозиться, сделав переходник с MDA DB-9 на DB-15, плюс выцыганить питание с разъёма для флоппи, ибо IBM решили убрать молексы из дизайна, и запитывать диски с материнки.

Ситуация с подключением двух мониторов довольна нестандартна для конца 80х, однако именно для этой цели адресное пространство у монохромного адаптера и у цветного графического (от которого наследуется текстовый режим VGA) разные, а значит в теории можно использовать VGA+MDA. Однако обычно программы для MS-DOS на это не затачивались, и профита от такой схемы для меня не должно было быть, если бы не…

Если бы не старый MINIX. Версии вплоть до 2.0.4 позволяли в теории запустить полноценный UNIX даже на IBM PC XT с 640k RAM. Однако же найти подходящую именно для меня конфигурацию MINIX оказалось задачей трудной. Я перебрал сначала версию MINIX для MS-DOS, но 1 MB памяти для неё было явно мало (что и не удивительно, ведь MINIX для DOS создаёт виртуальный диск в RAM). В итоге я смог установить в QEMU MINIX 1.7.5 на один из разделов Compact Flash, и потом даже запустить уже на самом PS/2.

Правда, путь к первой введённой в терминале команде был тернист. Во-первых, MINIX подвешивал клавиатуру при загрузке. Причину удалось установить, загрузившись в режиме совместимости с i8086, откуда подозрения сразу пали на злосчастную линию A20, которая управляется контроллером клавиатуры в AT-клонах для совместимости с i8086. В исходном коде kernel/klib88.s A20-линия выставлялась в соответствии с мануалами, вот только оказалось, что для IBM PS/2 появился специальный контроллер для управления A20, а посему код для ядра пришлось сразу же патчить. По итогам доступная память с 640k в режиме совместимости увеличилась до установленной памяти в 1 MB, плюс защищённый режим с его плюсами (ну и минусами тоже, об этом чуть позже).

Следующим шагом было реализации возможности работать одновременно в двух виртуальных tty, используя два монитора. В коде kernel/console.c такой абстракции как монитор или экран не было, поэтому пришлось долго провозиться с возникающими гонками за внутренние переменные, однако усилия были вознаграждены, и теперь я мог например вывести на один экран какой-нибудь man, и параллельно редактировать файл на другом, переключаять по Alt-<- Alt–>.

Ещё одна из проблем оригинального MINIX — он отказывался работать с CF-XT адаптером. Одно время я был удовлетворён работой драйвера, который вызывает функции BIOS int 13h через аппаратный сброс, пока я не захотел наконец-то разобраться с сетевым драйвером (благо он как раз для WD8390 совместимых карт уже был в исходниках). При включении Ethernet в параметрах ядра загрузка зависала на моменте инициализации драйвера диска (забавно, не правда ли?) Вместо того, чтобы пофиксить баг, я решили подойти к вопросу радикально и переписать стандартный драйвер IDE контроллера, чтобы он стал поддерживать CF-XT-lite. И это было увлекательно. Главной подсказской для меня стала принципиальная схема адаптера, потому что сходу отображение адресов CF на шину не гуглилось, и оказалось, что не на все вопросы необходимо искать ответ в Интернете, тем более когда достаточно просто взглянуть глазами на схему платы. Конечно, документация к CF и исходники XTIDE BIOS мне тоже помогли. В процессе переписывания драйвера в момент, когда я наконец-то разобрался с адресами, и драйвер стал идентифицировать устройство, я умудрился несколько раз испортить корневой раздел, но спасали бэкапы и Linux, который до сих пор поддерживает старую добрую MINIX FS.

Как итог: старый MINIX прекрасно себя чувствует на старой же машине с 16-bit разрядностью и 1 MB памяти, при этом позволяет выходить во внешний мир с помощью telnet и ftp и поддерживает мультизадачность. Сейчас я ковыряюсь с httpd сервером, который уже скомпилировался и запускается, но пока возвращает только 403 и 404 (причём делает это он секунд за пять, если не медленнее). Остались ещё мелкие недочёты по типу не работающего SIGTERM по Ctrl-C и мигающего сразу в двух экранах курсора (это сбивает с толку, потому что не знаешь, на какой экран сейчас перенаправлен ввод). Из глобального хочется сделать frame buffer хотя бы для VGA, а то и для обоих мониторов (попробовать видеокарту ATI в режиме Hercules). Другая возможная ветка развития — создание дистрибутива для старых компов и эмуляторов типа даже pcjs.org, чтобы у энтузиастов была возможность попробовать настоящий UNIX на своём ретро железе.

P.S. Да, чуть не забыл. На фото на левом мониторе telnet на какую-то из BBSок, на правом — стандартные UNIX команды и вывод кусочка ядра на экран.

Как на Википедии.
А если ещё и результат опросов выводить в таком виде, то вообще 🔥.

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

на экране, в окошке xterm'а, мы наблюдаем знаменитый ютавский чайничек [1] в его первозданном виде, сгенерённый моей маленькой приблудой из оригинальных файлов мистера ньюэлла. [2]

но это ещё не всё. давным давно, лет тридцать назад, а может больше, существовали такие векторные терминалы, как tektronix 4014 [3]. терминалы эти, как и vt100, давным давно уже канули в лету, но бравый xterm их всё ещё эмулирует. так вот, именно таким хитрым способом графика на экран и выводится.

ну и что бы завершить сеанс некрофилии, добавлю, что код сей писался на openbsd-машинке в nvi (ну, не сдружился я ни с vim'ом, ни с emacs'ом).

ругайте!

PS: коли кому цвета терминала понравятся, прошу любить и жаловать:
amberXTerm*foreground: #ff7f00
amberXTerm*background: #1f0000
greenXTerm*foreground: #00df1f
greenXTerm*background: #001f00

[1] http://letmegooglethatforyou.com/?q=utah+teapot
[2] http://www.sjbaker.org/teapot/teaset.tgz
[3] http://letmegooglethatforyou.com/?q=tektronix+4014

или продолжение прошлогоднего безобразия с небольшим резонансом.

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

На этот раз я решил немного заняться анимацией. Предметом издевательств был избран The Riddle от Gigi D' Agostino. В сети нашёлся и уже готовый файл с векторными данными в формате ILDA для лазерных проекторов (зеркало). Осталось дело за малым — скрестить одно с другим, что и можно наблюдать на скриншоте.

Кому интерессно — исходники лежат тут плюс вышеуказанный архив с данными. Запускаем всё это дело в xterm и наслаждаемся движущимися картинками (музыка прилагается).

И да, поклонники альтернативных терминалов в пролёте — этот финт ушами, насколько мне известно, работает только в xterm.

UPD: добавил нормализацию, что бы картинка на весь экран была и синхронизировал на 25fps.

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

(sleep 0.5 && ffplay music.mp3) & ./tekilda theriddle.ild

PS: тытрубки не будет т.к. у меня там нет ни аккаунта, ни желания его заводить

Есть сервер который что то долго и много считает и генерит кучу данных. Я могу войти туда по ssh. Хочется из этих данных строить картинки (графики y(x), как правило гнуплотом), при этом сами данные к себе не выкачивать. И хочется эти картинки сразу видеть, без всяких scp/sshfs, прямо вот в терминале. Без какого то интерактива вроде выделения фрагментов, смены масштаба и пр - просто увидеть картинку глазами, эдакий предпросмотр данных.

Вход по ssh -X или vgl работает но лагает жутко, канал все таки хиленький. У gnuplot-а есть терминал dumb:

gnuplot> set term dumb
gnuplot> plot x**2

                                                                               
  100 +--------------------------------------------------------------------+   
      |*               +                 +                +               *|   
   90 |-+..............:.................:................:..............+-|   
      |  *             :                 :                :             *  |   
   80 |-+..............:.................:................:..............+-|   
      |    *           :                 :                :           *    |   
   70 |-+..............:.................:................:..............+-|   
      |      *         :                 :                :         *      |   
   60 |-+..............:.................:................:..............+-|   
   50 |-+..............:.................:................:..............+-|   
      |         **     :                 :                :     **         |   
   40 |-+..............:.................:................:..............+-|   
      |            **  :                 :                :  **            |   
   30 |-+..............:.................:................:..............+-|   
      |               *:                 :                :*               |   
   20 |-+..............:.................:................:..............+-|   
      |                :  ***            :           ***  :                |   
   10 |-+..............:.................:................:..............+-|   
      |                +       *****     +    *****       +                |   
    0 +--------------------------------------------------------------------+   
     -10              -5                 0                5                10  

вот что то такого плана, только конечно качеством повыше.

У кого какие идеи?

Можно конечно свою обертку поверх ssh написать что бы она умела и картинки отрисовывать, но неужто никто ничего такого не сделал?

Решается применением терминала sixelgd в гнуплоте. Его не всякий терминал поддерживает, я в итоге остановился на mlterm (konsole и xterm не взлетели).

https://www.arewesixelyet.com/#xterm

Допустим мне не нужно массовое производство процессоров, а хочется запилить несколько штук в гараже с командами RISC-V для управления шаговым двигателем или отоплением в доме. Что-нибудь простенькое уровня Пентиум из 90-х без MMX расширений и прочих конвейров.

Литография это химия и опасные кислоты, по закупке которых на твой адрес подъедет ФСБ. Я уже не говорю о чистых комнатах и химзащите.

Таким образом вопрос к знатокам, а какие есть альтернативные способы доступные гражданскому, когда не нужно массовое производство? Я смотрю в сторону лазеров, как минимум с помощью них можно выжигать материал разрешением в 1 мкм получая техпроцесс 90-х. Выжечь несколько слоев, наложить друг на друга и получить транзисторы и контакты. А чтобы не ждать месяцы для выжигания одного процессора с миллионом транзисторов задействовать одновременно множество лазеров. Но это всё не точно.

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

На HDD там установлена старая версия Void Linux, которую вряд ли получится без бубна обновить до актуального состояния. Ядро, вроде как, 4.19, и в видеодрайвере там есть баг — при переключении видеорежимов система фризится секунд на 30-40.

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

Внезапно. Всё работает. Firefox воспроизводит музло с ютуба, LO Writer открывает документы. И даже ушла бага с фризом на переключении видеорежимов.

О системе:

Ядро 6.3.2 в пачсетом zen. Настроен swap в ZRAM. В качестве DE - стек программ на gtk2: LXDE + моя SDE. Терминал — Lilyterm. Параллельно в Бедроке установлен Debian Bookworm с XFCE. Просто чтобы был. Всё это стоит на флешке SanDisk Ultra Flair, которую я таскаю с собой в качестве переносной офисной системы.

О железке:

Экран: 14.1', 1280x800
Чипсет: GL960, Socket P
Процессор:
    Заводской: Intel Celeron 550 @ 2.00GHz; 1 core; Mark 514/626
    Текущий:   Intel Core 2 Duo T6570 @ 2.10GHz; 2 cores; Mark 1254/820
Память:
    Тип: 2 x DDR2 533/667/800* MHz; 3GB Max (2GB в верхний слот + 1GB в нижний слот)
    Заводская: 512MB 667 MHz
    Текущая:   2GB + 1GB 800 MHz (работает на 667 MHz; почему?)

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

CPU по нынешним меркам дрова полнейшие, так же как и пропуская способность ОЗУ. Честно сказать, я ожидал слайдшоу везде и невозможность пользоваться интернетом в актуальной версии браузера. Но ноутбук 2008-го года выпуска всё еще пригоден для современной ОС и современного веба.

Обвес машинки такой, что на боковых стенках почти нет пустого места: https://www.notebook-center.ru/catalog_acer_1684.html. Теперь так не делают. (На самом деле делают, но где-то 1 модель из сотни.)

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

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

Операционная система установлена на флешке Sandisk Ultra Flair объёмом 32 ГБ. В таком виде живёт уже около трёх лет, полёт нормальный. Используется эпизодически на самых разных железках.

В данный момент ОС запущена на Samsung NP300E5Z с процессором Intel Celeron B800 (2 ядра, 1.5 ГГц) и 8 ГБ DDR3 1333 МГц.

В качестве основной ОС использована Arch Linux. Сначала стояла только она одна, потом при помощи Bedrock Linux была преобразована в микс из трёх ОС. Bedrock Linux - это прослойка, позволяющая почти прозрачно миксовать софт из разных дистрибутивов Линукса, установленных в разные префиксы. Например, вы можете использовать для загрузки ядро от одного дистрибутива, инит и системные службы от второго, а прикладные программы - от третьего. Разумеется, не всякое сочетание компонент работает безглючно или вообще работает. Но гибкость достаточно большая.

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

В дополнение к Арчу сюда были добавлены Debian 12 и Alpine. Чисто из любопытства, чтобы посмотреть, как это работает, ну и чтобы был Debian под рукой, если что-то пойдёт не так. В Debian установлен самый минимум консольного софта + XFCE.

Весь основной софт стоит под Арчем. Софт преимущественно на gtk2 и gtk3. Из софта на Qt - только qBitTorrent. Из относительно крупных программ сюда поместились Libre Office, Firefox, SeaMonkey. Остальное мелкое, но его много.

Арч обновляю нерегулярно, иногда по 3-4 месяца без обновлений. Как и со всеми прочими моими установками Арча, никаких проблем с обновлениями, о которых рассказывают древние городские легенды родом из 00-х, тут нет.

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

Занимает всё вот столько, нужно еще вычесть отсюда 4 ГБ, которые занимает хомяк:

df -h /
Файловая система Размер Использовано  Дост Использовано% Cмонтировано в
/dev/sdb3           28G          19G  8,3G           69% /

Подробнее про конфигурацию.

Чтобы система могла запуститься на разном железе без пересборки initramfs, нужно внести правки в файл /etc/mkinitcpio.conf. Из переменной HOOKS нужно убрать autodetect и добавить нужное по необходимости:

HOOKS="base udev modconf block lvm2 filesystems keyboard"

Теперь хуки для mkinitcpio будут собирать универсальную initramfs, схожую с той, что используется в iso-образе с установщиком системы. А не урезаную версию, которая может загрузиться только на данном конкретном железе.

Честно говоря, я вообще не понимаю, зачем нужен этот автодетект. Типа это уменьшает размеры образа initramfs, но это экономия на спичках в ущерб универсальности.

Вот размеры универсального образа:

$ du -h /boot/initramfs*
38M	/boot/initramfs-linux-fallback.img
38M	/boot/initramfs-linux.img
36M	/boot/initramfs-linux-lts-fallback.img
36M	/boot/initramfs-linux-lts.img
39M	/boot/initramfs-linux-zen-fallback.img
39M	/boot/initramfs-linux-zen.img

Проблема, связанная с легендарным 12309. Нужно ограничить размер окна отложеной записи в страничном кэше. Это необходимо, чтобы ОС не вставала колом при интенсивных операциях ввода-вывода на медленных накопителях, таких как флешки. Делается вот так:

$ cat /etc/sysctl.d/99-my-sysctl.conf 
vm.dirty_bytes = 4000000
vm.dirty_background_bytes = 2000000

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

Так как система предназначена для запуска «где придётся», в том числе на системах с ограниченным объёмом ОЗУ, то настраиваем своп в ZRAM. Это позволит более-менее нормально пользоваться браузером на системах с 2-3 гигабайтами ОЗУ.

Проще всего это сделать установкой пакета systemd-swap из AUR. Вопреки названию, он не имеет никакого отношений к разработчикам systemd, да и к самому systemd практически никакого отношения не имеет. Это довольно простой скрипт на питоне, который настраивает устройства подкачки по конфигу.

В конфиге /etc/systemd/swap.conf настраиваем ZRAM. В моём случае под сжатый своп может использоваться до половины ОЗУ:

$ grep '^[^#]' /etc/systemd/swap.conf
zram_enabled=1
zram_size=$(( RAM_SIZE / 2 ))
zram_count=${NCPU}
zram_streams=${NCPU}
zram_alg=zstd
zram_prio=32767

Также из AUR я поставил пакет preload.

preload is an adaptive readahead daemon. It monitors applications that users run, and by analyzing this data, predicts what applications users might run, and fetches those binaries and their dependencies into memory for faster startup times.

Ну типа вы поняли, мне лень переводить.

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

Установлено несколько DKMS-модулей с дополнительными драйверами, которых нет в базовой поставке. В моём случае это драйвера на WiFi от Broadcom и на RTL8188eus. Есть в AUR.

В качестве оболочки у меня используется мой форк LXDE.

Внизу - панель waterline. На основной машине у меня она сконфигурирована в довольно уникальном варианте, не имитирующем никакой другой ОС. А тут я решил оставить её в стиле Windows-like.

Цветовое кодирование кнопок на панели в тон иконке приложения - обожаю эту фичу.

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

Н/Д рядом с часами - это индикатор заряда батерии, а батареи в ноутбуке не установлено. Подумал вот сейчас, надо бы как-то чуть более очевидно это подписывать.

Иконка дома открывает рекурсивное меню с содержимым хомяка, откуда можно открывать файлы.

WM - openbox с околодефолтным конфигом.

В общем, всё довольно стандартно.

Потребление ОЗУ системой после логина на рабочий стол - около 400 МБ.

Собственно, сабж. Статья про то самое, что мы с Eddy_Em не могли осилить в прежние времена. В этом году я это, внезапно, осилил. Ну и написал статью.

https://saahriktu.ru/pdf/kak_jit_esli_u_vas_yunikod.pdf

Раньше не сталкивался, мало ими пользуюусь.

Определение без ошибок, данные на месте, защита отключена:

... [sdb] Write Protect is off

Монтирование r/w или запись dd тоже без ошибок, но содержимое не меняется. Как-будто контроллер в режиме симуляции.

Они всегда так вежливо ломаются? «Выбросить нельзя починить» — куда запятую?

А кто знает как в Astre, во fly-term шрифты поменять.

В смысле, не ограничиваться 14 размером, как в выпадающем меню, а поставить, например, 16-й. Весь мануал перерыл. Блин.

Подскажите, плиз.

Перемещено hobbit из general

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

Есть некая картинка jpg, которая претерпела 4 переноса с носителя на носитель

1. С Андроида (увы методом перемещения а не копирования, т.к. если бы оригинал остался на Андроиде было бы проще судить о природе события) переместилась на usb flash (новый, почти не пользованный)

2. С usb flash на usb hdd.

3. C usb hdd на другой usb hdd.

4. И наконец с usb-hdd на внутренний ssd (тоже весьма новый, с почти неиспользованным ресурсом).

Смотрю на скопированные фотки и вижу что одна фотка стала битой.

У меня была резервная копия с внутреннего hdd...

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

Бинарное сравнение файлов показало что есть различия непрерывно идущие с 163840 байта по 163968, всего различие растянулось на 128 байт (а не один бит как я думал).

Неправильные байты целиком нулевые. Т.е. выглядит это даже не как искажение информации в физической единице хранения - «перевернутые биты» (т.е. те самые проблемы с RAM, могут проявлять себя на noECC модулях https://blog.robertelder.org/importance-of-ecc-memory/)), а как потеря последовательности бит.

Я производил тщательные проверки накопителей (всех кроме Андроидского, т.к. не знаю как это делать в смартфоне безрутовом) - с ними всё впорядке, внешние hdd, внутренний ssd согласно smart не имеют событий переназначений, как комплектные утилиты (речь о Винде, поэтому chkdsk /f/r), так и сторонние HD Sentinel, HDDScan, не обнаруживают проблем с устройствами, ровно как и с флешкой, в ней хоть и нет smart но все тесты проходит на отлично.

Итого с одной стороны то что все нули - очень хочется описать событие как то что на одном из устройств случился плохой сектор и был заменен на резервный (а он типа с завода не содержит записей, поэтому нули), но на всех перечисленных устройствах размер сектора минимум 512 (на внешних дисках возможно даже 4096), а в нулях только 128 байтов, да и в smart нет событий не только переназначений, но даже таких как #196, #197, #199, т.е даже намека на плохие сектора и плохой линк интерфейса нет.

Тогда остаётся думать что проблема могла быть или на nand Андроида или в момент передчи файлов с Андроида в комп. К слову кабель был весьма повидавший виды, местами у него не только слез экранирующий слой, но даже некоторые проводочки (именно проводочки а не экранирование) местами прям голые без изоляции.

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

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

получается самым вероятным является то что проблема в накопителе Андроида?

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

В общем если заняться не чем, как и мне на момент написание этой портянки, то веллкам.

На всякий случай срезюмирую вопросы:

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

2. Может быть похоже на проблему с usb-кабелем? Но имеет ли возможность операционка (не важно какая) программно понять что сейчас какие-то аномалии и следует как минимум сообщить об этом (а лучше произвести новые попытки, ну типа как в сетевом протоколе TCP)

3. Есть ли возможность на нерутированном устройстве Андроид проверять жизнеспособность секторов nand накопителя, к которым, по крайней мере через слой файловой системы у пользователя доступ есть. Ну конечно речь про какой-то более адекватный способ (с множественным чтением каждого сектора, и замером времени отклика, как это делает hddsentinel и прочие проверялки) чем заполнить все пустое пространство одним огромным файлом (параллельно такой же файл сгенерировать в компе) и потом скопировать с телефона в комп и сравнить побайтово (ну или не копировать а по хешсумам сравнить)

https://i.imgur.com/8619HII.jpg

Если я хочу выделить память для структуры с какими-то значениями без указателей, то могу просто сделать malloc(sizeof).

Но если у меня в структуре char *, т.е. какая-то строка размер которой я пока что не знаю, как выделять память с malloc?

Значит ситуация следующая, после внепланового неконтролируемого отключения электричества перестал работать wi-fi на недотопе. NetworkManager говорит: - «Wi-Fi выключен».

Собственно:

Simply Linux 10.1  (Captain Finn)
Linux client 5.10.123-std-def-alt1 #1 SMP Mon Jun 20 16:33:14 UTC 2022 x86_64 GNU/Linux

[   30.514627] r8712u: module is from the staging directory, the quality is unknown, you have been warned.
[   30.519189] r8712u: register rtl8712_netdev_ops to netdev_ops
[   30.519201] usb 5-1: r8712u: USB_SPEED_HIGH with 4 endpoints
[   30.519730] usb 5-1: r8712u: Boot from EFUSE: Autoload OK
[   31.053981] usb 5-1: r8712u: CustomerID = 0x0000
[   31.053989] usb 5-1: r8712u: MAC Address from efuse = 74:2f:68:7a:0e:aa
[   31.053994] usb 5-1: r8712u: Loading firmware from "rtlwifi/rtl8712u.bin"
[   31.054334] usbcore: registered new interface driver r8712u
[   31.307601] r8712u 5-1:1.0 wlp0s29f7u1: renamed from wlan0

# iw wlp0s29f7u1 info
command failed: No such device (-19)

# lsmod | grep 87
r8712u                204800  0
cfg80211              966656  1 r8712u

Коллеги, есть ли сейчас вменяемый работающий способ подать из скрипта в эмуляторе терминала звуковой сигнал (об окончании, например)? Я посмотрел поиск, но что-то у меня ничего не отработало.

Допустим, gzip заменить на pigz и аналогичные мультипоточные архиваторы? А то при открытии больших архивов mc думает долго