Текстовый редактор Micro 2.0.14

Нет, там нормальные кнопкосочетания. :)

Так, там режимы, как в vim:

The key is bound in normal mode by default, unless one or more of the following flags are used:

-c
    Add binding for command mode 
-n
    Add binding for normal mode 
-s
    Add binding for search mode 

режимы в текстовом редакторе не нужны. Например, в сабжевом micro их нет.

Проверил, версия 2.0.13 стартует и работает

Больше редакторов богу редакторов!

Лишь бы (neo)vim не юзать.

Так, там режимы, как в vim

Да нет же! Уже давно бы установил вместо чтения. :)

Лишь бы (neo)vim не юзать.

У сабжа есть одна киллер-фича: Ctrl+C и Ctrl+V из коробки.

киллер-фича: Ctrl+C и Ctrl+V из коробки.

• mcedit
• far2ledit

Первое это типа комментрование выделенных строчек правильным способом для данного языка? Ну так не проблема же плагином добавить, он маленький. А Ctrl+V что делает?

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

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

Докер и Кибенетис

спробуй фар2л, он как минимум умеет работать с несколькими текстовыми файлами

mcedit, если он запущен не самостоятельно, а из mc, тоже умеет, «Alt+Grave» и выбрать экран для открытия файла. Так же и переключаться между открытыми файлами.

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

Есть подозрение, что по причине пиратства. В том смысле что двухпанельник от дяди Нортона был сильно платным, а пиратить софт было принято в основном в бСССР. Так и стал популярным этот подход.

Я его недавно на Hex Editor сменил, вон он как раз из коробки больше возможность содержит

vim -e хватит всем!

для тех кто не осилил :q! ?

Ctrl+C и Ctrl+V из коробки.

mcedit

В aix не работает.

https://openbsdmailbox.blogspot.com/2024/04/editormicro-stopped-working.html
https://github.com/golang/go/issues/63900

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

Жуть какая. Как они добились такого размера. До микро далеко.

Жуть какая. Как они добились такого размера

Это статически собранный вариант, наверное со всеми зависимостями:

$ ldd /opt/micro/micro
not a dynamic executable

Я его не устанавливал пакетным менеджером, просто скачал tar-архив и распаковал.

Круто, что нет зависимостей

С каких это пор это стало крутым? Может быть для каких-то совсем мелких утилит типа cat это нормально, но для чего-либо более сложного это конечно минус.

Если кому-то по какой-то причине нужен статический бинарник, можно собрать отдельный вариант, а в общем случае это неправильно.

Почему неправильно?

1. Обновления (безопасности и не только) - при обнаружение дыры в разделяемой библиотеке, разрабам дистрибутива достаточно исправить только версию используемой библиотеки, а пользователям обновить один пакет. В случае статической линковки, разрабам придётся пересобирать весь дистрибутив (например в случае какой-нибудь libc), а пользователям переустанавливать все пакеты, которые линкуют эту библиотеку. И это ещё не всё: пакеты со статической линковкой могут тянуть за собой копию библиотеки и собирать её самостоятельно, тогда обновление безопасности вообще превращается в квест.

2. Банальная экономия ОЗУ, места на диске и сетевого трафика.

3. Вопросы совместимости: удобно когда все (или большинство) приложений в дистрибутиве используют одну и ту же версию библиотеки. Со статической линковкой это тоже возможно, но всё же динамическая линковка это поощряет.

4. Вопрос подмены: некоторые приложения типа socks используют подмену библиотек для реализации функциональности.

Преимущества у статической линковки тоже есть, но их всё же меньше. Кроме того, вполне можно предоставить статический вариант приложения для тех, кому это действительно нужно.

Да, звучит убедительно. Но:

1. Разработчики должны отслеживать уязвимости в библиотеках, которые они используют. Если кто-то написал программу, а она ломает всё и вся, то никто не будет этой программой пользоваться. Это вопрос жизни этой программы. Нельзя полагаться на то, что кто-то где-то будет обновлять библиотеки. Ментейнеры дистрибутива вообще могут, в теории, забить на это или не знать.

2. А разве библиотеки которые в зависимостях не занимают место на диске или в ОЗУ?

3. В куче зависимостей гораздо проще что-то подменить (спрятать), чем один бинарь контрольную сумму которого можно отслеживать или использовать инструмент вроде afick.

Мне кажется, на каждый аргумент можно найти контраргумент в данном случае. Всё же отслеживание зависимостей, контроль их версий, контроль их совместимости и прочие накладные расходы перевешивают в сторону приложений без зависимостей. Видно же, что набирают популярность snap, appimage, flatpack. Да, это совсем другой подход и не нужно их сравнивать с приложениями со статической линковкой. Но тенденция очевидна.

Разработчики должны отслеживать уязвимости в библиотеках, которые они используют. Если кто-то написал программу, а она ломает всё и вся, то никто не будет этой программой пользоваться. Это вопрос жизни этой программы. Нельзя полагаться на то, что кто-то где-то будет обновлять библиотеки. Ментейнеры дистрибутива вообще могут, в теории, забить на это или не знать.

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

2. А разве библиотеки которые в зависимостях не занимают место на диске или в ОЗУ?

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

3. В куче зависимостей гораздо проще что-то подменить (спрятать), чем один бинарь контрольную сумму которого можно отслеживать или использовать инструмент вроде afick.

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

Если речь про micro, то там один бинарь:

 $ dir /opt/micro

    Directory: /opt/micro

UnixMode     Num   UID   GID      LastWriteTime    Size Name
--------     ---   ---   ---      -------------    ---- ----
-rw-r--r--   644     0     0   27.08.2024 21:09    1,1K LICENSE
-rw-r--r--   644     0     0   27.08.2024 21:09   62,7K LICENSE-THIRD-PARTY
-rwxr-xr-x   755     0     0   27.08.2024 21:10   11,1M micro
-rw-r--r--   644     0     0   27.08.2024 21:09      3K micro.1
-rw-r--r--   644     0     0   27.08.2024 21:09     537 micro.desktop
-rw-r--r--   644     0     0   27.08.2024 21:09    6,2K micro.svg
-rw-r--r--   644     0     0   27.08.2024 21:09   13,7K README.md

С недавнего времени собираются ночные билды (раз в сутки), наверное разработчики следят за новостями безопасности.

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

Как он это делает разрабов не волнует, руками качает или пишет скрипты.

Пользователь ставит с помощью apt install micro или там yum install micro, как и другой софт.

Пользователь ставит с помощью apt install micro или там yum install micro, как и другой софт.

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

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

киллер-фича: Ctrl+C и Ctrl+V из коробки.
mcedit

Что mcedit? У него что, внезапно появился копипаст по Ctrl+C и Ctrl+V?

двухпанельники везде, кроме бывшего СССР - дикая маргинальщина

Кстати: https://github.com/FarGroup/FarManager/issues/3 – «Support multiple platforms».

A good enough and distant enough goal for the 1st issue here.

2017-й год, 👍 23, 😊 4.

можно самому скачать какой-нибудь пре-релиз и не ждать выхода следующей стабильной версии

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

У меня не работает.

Больше редакторов, хороших и разных! Если бы не было vim, попробовал бы, но, может, при случае и возникнет шанс.

не имеющий зависимостей

Зачет.

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

Что значит расскидывать? Взял в руку горсть бинарников и швырнул куда попало, вы так себе это представляете?

Что значит расскидывать? Взял в руку горсть бинарников и швырнул куда попало, вы так себе это представляете?

Да, примерно так. Как вещи по комнате. Неаккуратненько :)

Исправление фатальной ошибки, допущенной при разработке указанного ПО.

Вот бы под винду кто-нибудь посоветовал простой консольный редактор…

micro — кроссплатформенный текстовый редактор. Т. е. доступен и под винду.