ip vs ifconfig команды за и против
Весь стек ввода X11 в беспорядке. Во-первых, вам не нужна какая-либо специальная среда для методов ввода, если вы просто набираете латинские символы или составные последовательности из нескольких символов, как определено вашей раскладкой клавиатуры XKB. Строго говоря, любые последовательности с несколькими клавишами, такие как мертвые клавиши, требуют очень простого метода ввода. Но они предоставляются libx11 / XKB и работают без какой-либо дополнительной инфраструктуры обмена мгновенными сообщениями. Так что вполне нормально удалить все ibus, uim, fcitx или любой другой метод ввода, который у вас есть, если вам не нужно вводить языки, такие как китайский или японский.
Как вы уже сказали, Gnome сделал ibus методом ввода по умолчанию, и это решение не всех устраивало. Многие люди предпочитают fcitx (который, по-видимому, используется по умолчанию для большинства дистрибутивов KDE) над ibus по нескольким причинам: будь то правильная языковая поддержка (в основном японский, упрощенный и традиционный китайский) или проблемы с производительностью. Поскольку я не говорю на восточных языках, для которых нужна особая структура обмена мгновенными сообщениями, я не могу ничего добавить к этой дискуссии. Но если вас интересует более подробная информация о fcitx и ibus, вы можете прочитать эту слегка устаревшую (2012 г.), но, вероятно, все еще точную статью LWN .
Однако тот факт, что ibus является IM по умолчанию для Gnome, не делает его обязательным. Вы можете использовать любой другой метод ввода, который вам нравится, или вообще не использовать. Конфигурация IM выполняется с помощью переменных среды. Но за исключением случаев, когда вы используете только приложения GTK + (в чем я сомневаюсь), вам следует установить больше, чем просто GTK_IM_MODULE . Правильный способ установки метода ввода:
export GTK_IM_MODULE="fcitx"
export QT_IM_MODULE="fcitx"
export XMODIFIERS="@im=fcitx"
в случае fcitx или
export GTK_IM_MODULE="ibus"
export QT_IM_MODULE="ibus"
export XMODIFIERS="@im=ibus"
в случае ibus. uim работает точно так же. Если вы хотите явно отключить какой-либо метод ввода, используйте следующие настройки:
export GTK_IM_MODULE="gtk-im-context-simple"
export QT_IM_MODULE="simple"
Пустая строка также работает.
Вы можете установить эти переменные либо для всей системы в / etc / profile (или в специальный файл внутри /etc/profile.d , соответственно), либо внутри вашего локального ] ~ / .xprofile . Установка его в ~ / .bashrc или ~ /.профиль не гарантирует, что строки будут выполняться при входе в вашу систему с использованием графического менеджера входа в систему, такого как GDM, SDDM, KDM или LightDM. Если вы начинаете сеанс X с помощью XDM, Slim или startx , вам необходимо поместить эти строки в ~ / .xinitrc .
Если вы настроили метод ввода, отличный от ibus, после этого перейдите в настройки Gnome и убедитесь, что все настройки, связанные с ibus, отключены, особенно любые сочетания клавиш. В качестве альтернативы, скажите Gnome, чтобы он не касался настроек вашей клавиатуры, используя:
gsettings set org.gnome.settings-daemon.plugins.keyboard active false
, или полностью удалите ibus.
А что насчет XIM? XIM - довольно устаревший протокол метода ввода, который и ibus, и fcitx реализуют только по причинам устаревшей поддержки. Нет реальной причины, по которой вы хотели бы использовать XIM в настоящее время вместо любого из этих двух. Единственная причина, по которой вы хотели бы установить GTK_IM_MODULE = "xim" , - это переопределить жестко запрограммированные настройки ComposeKey GTK .
Отвечая на ваш другой вопрос: я не думаю, что действительно есть способ определить, какой метод ввода активен в данный момент, кроме как смотреть на переменные среды или знать, какие IM установлены в вашей системе. Если GTK_IM_MODULE не установлен, GTK выбирает встроенный IM на основе конфигураций в /etc/gtk-2.0/gtk.immodules . GTK 3.0 ищет в /usr/lib/gtk-3.0/3.0.0/immodules.cache , который создается gtk-query-immodules-3.0 .
Причина, по которой GTK_IM_MODULE установлен на xim , вероятно, является определением какой-то случайной переменной где-то в / etc / profile , / etc / profile. d / * или любой другой из ваших локальных или глобальных файлов RC оболочки. Не стесняйтесь отключать или отменять эту переменную, если чувствуете в этом необходимость.
Однаков соответствии с этим комментарием к отчету об ошибке Gnome Я предполагаю, что значение, настроенное с помощью gsettings , переопределяет значение, установленное в GTK_IM_MODULE для приложений, активированных DBus. Так что, по крайней мере, ваши приложения Gnome, вероятно, в настоящий момент используют gtk-im-context-simple , что фактически означает стандартное поведение (т.е. отсутствие ibus или любого другого выделенного IM).
Команда ifconfigв таких операционных системах, как FreeBSD и OpenBSD, была обновлена в соответствии с остальной частью операционной системы. В настоящее время он может настраивать все виды параметров сетевого интерфейса в этих операционных системах и обрабатывать ряд сетевых протоколов. BSD обеспечивают ioctl()поддержку этих вещей.
Этого не произошло в мире Linux. На сегодняшний день существует три ifconfigкоманды:
ifconfigиз GNU inetutilsjdebp % inetutils-ifconfig -l enp14s0 enp15s0 lo jdebp % inetutils-ifconfig lo lo Link encap:Local Loopback inet addr:127.0.0.1 Bcast:0.0.0.0 Mask:255.0.0.0 UP LOOPBACK RUNNING MTU:65536 Metric:1 RX packets:9087 errors:0 dropped:0 overruns:0 frame:0 TX packets:9087 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:51214341 TX bytes:51214341 jdebp %ifconfigиз СЕТКА -3 сетки -инструментыjdebp % ifconfig -l ifconfig: option
-l' not recognised. ifconfig:--help' gives usage information. jdebp % ifconfig lo lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536 inet 127.0.0.1 netmask 255.0.0.0 inet6 ::1 prefixlen 128 scopeid 0x10<host> inet6 ::2 prefixlen 128 scopeid 0x80<compat,global> inet6 fe80:: prefixlen 10 scopeid 0x20<link> loop txqueuelen 1000 (Local Loopback) RX packets 9087 bytes 51214341 (48.8 MiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 9087 bytes 51214341 (48.8 MiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 jdebp %ifconfigиз (версия 1.40)набор инструментов Noshjdebp % ifconfig -l enp14s0 enp15s0 lo jdebp % ifconfig lo lo link up loopback running link address 00:00:00:00:00:00 bdaddr 00:00:00:00:00:00 inet4 address 127.0.0.1 prefixlen 8 bdaddr 127.0.0.1 inet4 address 127.53.0.1 prefixlen 8 bdaddr 127.255.255.255 inet6 address ::2 scope 0 prefixlen 128 inet6 address fe80:: scope 1 prefixlen 10 inet6 address ::1 scope 0 prefixlen 128 jdebp % sudo ifconfig lo inet4 127.1.0.2 alias jdebp % sudo ifconfig lo inet6 ::3/128 alias jdebp % ifconfig lo lo link up loopback running link address 00:00:00:00:00:00 bdaddr 00:00:00:00:00:00 inet4 address 127.0.0.1 prefixlen 8 bdaddr 127.0.0.1 inet4 address 127.1.0.2 prefixlen 32 bdaddr 127.1.0.2 inet4 address 127.53.0.1 prefixlen 8 bdaddr 127.255.255.255 inet6 address ::3 scope 0 prefixlen 128 inet6 address ::2 scope 0 prefixlen 128 inet6 address fe80:: scope 1 prefixlen 10 inet6 address ::1 scope 0 prefixlen 128 jdebp %
Как видите, инструменты GNU inetutils и NET -3 net -ifconfigимеют некоторые заметные недостатки в отношении IPv6, в отношении интерфейсов с несколькими адресами и в отношении функциональности. вроде -l.
Проблема IPv6 частично связана с отсутствием кода в самих инструментах. Но в основном это вызвано тем, что Linux не (, как другие операционные системы ), обеспечивает функциональность IPv6 через ioctl()интерфейс. Он позволяет программам видеть и управлять IPv4-адресами только через сеть ioctl()s.
Вместо этого Linux предоставляет эту функциональность через другой интерфейс, send()и recv()в специальном и несколько странном адресном семействе сокетов, AF_NETLINK.
GNU и NET -3 ifconfigs могли быть скорректированы для использования этого нового API. Аргумент против этого заключался в том, что его нельзя было перенести на другие операционные системы.но на практике эти программы были уже не переносимыми в любом случае , так что это не было большим аргументом.
Но они не были исправлены и остаются такими, как показано выше, по сей день. (Некоторые люди работали над ними в разное время на протяжении многих лет, но усовершенствования, к сожалению, так и не попали в программы. Например,:Bernd Eckenfels так и не принял патч , добавляющий некоторые возможности netlink API в инструменты NET -3 net -ifconfig, спустя 4 года после того, как патч был написан.)
Вместо этого некоторые люди полностью заново изобрели набор инструментов в виде команды ip, которая использовала новый Linux API, имела другой синтаксис и объединила несколько других функций за модным интерфейсом в стиле command subcommand-.
Мне нужна была ifconfigсинтаксис строки команды -и стиль вывода FreeBSD ifconfig(, которого нет ни в GNU, ни в NET -3 ifconfigи который ipнаверняка не имеет ). Поэтому я написал один. В качестве доказательства того, что можно написать ifconfig, который использует API-интерфейс netlink в Linux, он это делает.
Таким образом, общепринятая мудрость о ifconfig, такая как то, что вы цитируете, на самом деле больше не соответствует действительности. Теперь неверно утверждать, что «ifconfigне использует netlink». Одеяло, покрывающее двоих, не покроет троих.
Всегда было неверным утверждение, что «netlink более эффективен». Для задач, которые выполняются с ifconfig, на самом деле не так много, когда речь идет об эффективности между API netlink и API ioctl(). Каждый делает примерно одинаковое количество вызовов API для любой заданной задачи.
Действительно, каждый вызов API представляет собой два системных вызова в случае netlink, а не один в системе ioctl().И, возможно, API-интерфейс netlink имеет тот недостаток, что в интенсивно -используемой системе он явно включает возможность того, что инструмент никогда не получит подтверждающее сообщение, информирующее его о результате вызова API.
Кроме того, неверно говорить, что ip«более универсален», чем GNU и NET -3 ifconfigs , потому что он использует netlink . Он более универсален, потому что выполняет больше задач, выполняя действия в одной большой программе, которые можно было бы выполнять с помощью отдельных программ , отличных отifconfig. Он не более универсален просто благодаря API, который он использует внутри для выполнения этих дополнительных задач. В этом нет ничего присущего API. Например, можно написать все -в -одном инструменте, который использует FreeBSD ioctl()API, и с таким же успехом заявить, что он «более универсален», чем отдельные ifconfig, route, arp. ] и ndp.
Можно было написать команды route, arpи ndpдля Linux, которые также использовали API netlink.
Дополнительная литература
- Джонатан де Бойн Поллард (2019 ).
ifconfig. Направляющая ноша . Программное обеспечение. - Эдуардо Ферро (2009 -04 -16 ).ifconfig :сообщает о неправильном IP-адресе/начальном патче. Ошибка Debian #359676.